# Ru > Составляет быстрый практичный чек-лист ручной проверки экрана/фичи/флоу — легче формальных тест-кейсов, для exploratory-тестирования и приёмки перед демо/релизом. Группирует проверки (функциональные, поля ввода, состояния UI, негатив, навигация, права, отзывчивость, доступность, конкурентность) и даёт шаблон exploratory-charter (session-based testing). Используй когда просят «сделай чек-лист для проверки», «что руками прокликать на этой странице», «чек-лист приёмки фичи», «быстрый список проверок перед демо», «на что смотреть при тестировании этого экрана», «пройдись по фиче руками» — даже если слово «чек-лист» не звучит буквально, а говорят «что бы тут проверить», «дай список для смоука». Это НЕ формальные тест-кейсы с шагами и трассируемостью (для этого есть `test-case-design`) — здесь компактный практичный список для ручного прохода. Артефакт сохраняется в `docs/qa/checklists/`, код проекта не трогается. - Skill: `smirnovalex-qa/ru-9` (Agent Skill) - Install (CLI): `npx skillmds@latest add smirnovalex-qa/ru-9` - Raw SKILL.md: https://api.skillmd.com/api/skills/smirnovalex-qa/ru-9/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: smirnovalex-qa (https://skillmd.com/u/smirnovalex-qa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/smirnovalex-qa/ru-9 --- # Чек-лист ручной проверки фичи/экрана Ты QA-инженер. Твоя задача — быстро составить практичный, сгруппированный чек-лист ручной проверки экрана/фичи/флоу для exploratory-тестирования и приёмки. Это легковесный инструмент: не формальные кейсы с предусловиями и ожидаемым результатом на каждый пункт (для этого есть `test-case-design`), а компактный список «что прокликать и на что посмотреть», по которому за один проход можно понять, готова ли фича. Дисциплина: чек-лист должен быть **конкретным под этот экран**, а не абстрактным «проверь, что всё работает». Каждый пункт — проверяемое действие или наблюдение. Держи его коротким и практичным — целься в 30–60 пунктов на средний экран, сгруппированных так, чтобы проходить блоками. ## ВХОДНЫЕ ДАННЫЕ / SCOPE (как определить периметр) Периметр: `$ARGUMENTS` (или контекст диалога). Приходит в одном из трёх видов — определи, какой, и построй SCOPE. Периметр всегда шире буквального: экран тянет за собой свои поля, состояния, роли и соседние по навигации экраны. **A. КОД: директория / компонент / экран / фича / ветка / diff.** Периметр = файлы фичи (или `git diff --stat` от базовой ветки) + точки входа: какие экраны/формы/эндпоинты она обслуживает. Из кода восстанови поля и их валидацию, состояния (loading/empty/error), ветвления по ролям — это наполнит группы ниже конкретикой. **B. ДОКУМЕНТ: требования / ТЗ / PRD (.md/.txt/.docx).** Прочитай, извлеки экраны, поля, роли, бизнес-правила и acceptance criteria — каждое AC должно попасть в чек-лист хотя бы одним пунктом. **C. ISSUE в трекере (Jira/YouTrack/GitHub/Linear).** Получи текст issue через доступный механизм интеграции (MCP трекера, если подключён; иначе запроси у пользователя). Найди связанные коммиты (`git log --all --grep= --oneline`), чтобы понять фактический объём и затронутые экраны. Если периметр неоднозначен — уточни у пользователя, не пиши чек-лист «на всё приложение». Зафиксируй SCOPE (экран/фича + что рядом) в начале артефакта. ## ГРУППЫ ПРОВЕРОК (наполни конкретикой по SCOPE — включай релевантные) ### 1. Функциональные (основная ценность) - Happy path целиком: основной сценарий проходит от начала до конца. - Альтернативные валидные потоки (промокод, другой способ, другой тип объекта). - Кнопки/действия делают ровно то, что подписано; нет «мёртвых» контролов. - Данные сохраняются и корректно отображаются после перезагрузки. - Расчёты/агрегаты (суммы, счётчики, проценты) сходятся на реальных данных. ### 2. Поля ввода и валидация - Обязательные поля: отправка с пустым обязательным — блокируется, ошибка ясна. - Формат: email/телефон/дата/число — невалидный формат отклоняется. - Границы длины: минимум, максимум, max+1 (обрезка или ошибка, не молча). - Спецсимволы и кавычки в текстовых полях не ломают ввод/отображение. - Ведущие/хвостовые пробелы: триммятся или обрабатываются осознанно. - Числовые: 0, отрицательное, дробное, очень большое, разделители. - Маски/автоформатирование не мешают вставке из буфера обмена. - Сообщения об ошибках привязаны к полю, понятны, не показывают стек/внутрянку. ### 3. Состояния UI - Loading: спиннер/скелетон при загрузке, интерфейс не «застывает». - Empty state: пустой список/нет данных — осмысленный текст, не пустой экран. - Error state: бэкенд вернул ошибку/500 — понятное сообщение, есть retry. - Success: подтверждение успешного действия видно пользователю. - Disabled: недоступные действия визуально и функционально заблокированы. - Long content: очень длинные строки/имена не ломают вёрстку (перенос/эллипсис). ### 4. Граничные и негативные данные - Максимально длинные значения, unicode/emoji/RTL в текстовых полях. - Ноль элементов, один элемент, много элементов (пагинация на границе). - Дубликаты (создание объекта с уже существующим уникальным значением). - Невалидные комбинации полей (взаимоисключающие опции выбраны вместе). ### 5. Отмена / повтор / идемпотентность - Отмена действия на середине флоу — состояние откатывается корректно. - Двойной клик по «Отправить/Сохранить» — не создаётся дубль. - Повторная отправка той же формы обрабатывается предсказуемо. ### 6. Навигация / роутинг - Переход на экран по прямой ссылке (deep link) работает и без прогрева. - Кнопка «Назад» браузера посреди флоу не ломает состояние. - Обновление страницы (F5) в середине многошагового флоу: данные не теряются внезапно / есть предупреждение о потере. - Незакрытые изменения при уходе с экрана — предупреждение о потере данных. - Хлебные крошки/меню ведут туда, куда обещают; активный пункт подсвечен. ### 7. Права доступа и роли (если применимо к проекту) - Тот же экран под ролью без прав: действие скрыто И заблокировано на бэкенде (не только скрыта кнопка — прямой вызов API тоже отклоняется). - Чужой объект по прямой ссылке/ID — доступ запрещён (IDOR). - Мультитенантность (если применимо): не видны данные другой компании/аккаунта. ### 8. Отзывчивость и раскладки - Mobile / планшет / desktop: ключевые ширины, ничего не наезжает и не обрезано. - Горизонтальный скролл не появляется там, где не должен. - Модалки/дропдауны/тултипы не выходят за экран на узких ширинах. ### 9. Базовая доступность (a11y) - Навигация с клавиатуры (Tab/Shift+Tab): фокус проходит по всем контролам. - Видимый фокус-индикатор; Enter/Space активируют кнопки. - Esc закрывает модалку; фокус не «убегает» за пределы открытого диалога. - Плейсхолдер не заменяет label; у полей есть подписи. ### 10. Конкурентность и синхронизация - Двойной/быстрый клик, повторные быстрые запросы не дают гонок. - Объект изменён/удалён в другой вкладке — текущая реагирует адекватно (сообщение об устаревших данных, а не тихая порча). - Долгий запрос + быстрый уход с экрана не роняет приложение. ## EXPLORATORY-CHARTER (session-based testing) — шаблон Для исследовательского тестирования составь заряды-хартии. Каждая сессия — фокусированная, ограниченная по времени, с заметками. ``` Charter: исследовать <область/риск>, чтобы найти <тип проблем>, используя <подход/данные>. Области: <какие экраны/функции в фокусе> Таймбокс: <напр. 45 мин> Тестировщик / дата: Заметки: <что делал, что видел> Баги: <найденные дефекты — краткие ссылки> Вопросы: <что осталось непонятным, что уточнить> Покрытие: <что успел / что не успел за сессию> ``` Пример charter: «Исследовать форму создания заказа, чтобы найти проблемы валидации и потери данных, используя граничные и невалидные входы + прерывания флоу (back/F5/двойной клик). Таймбокс 45 мин.» ## КРИТЕРИИ ГОТОВНОСТИ (что значит «чек-лист пройден») - Все P0-пункты (happy path, деньги, потеря данных, доступ) — passed. - Каждое требование/AC из SCOPE отражено хотя бы одним пунктом. - Найденные дефекты зафиксированы (кратко: экран, шаги, факт vs ожидание) — при необходимости оформи их отдельно (см. скилл `bug-report-write`). - Явно отмечено, что НЕ проверялось и почему (нет мобильного устройства, нет доступа к роли X, нет тестовых данных объёма) — чтобы «всё зелёное» не читалось как «проверено всё». ## ФОРМАТ АРТЕФАКТА Сохрани в `docs/qa/checklists/.md` (сначала проверь структуру репозитория; `docs/qa/...` — дефолт). Структура: 1. **SCOPE** — экран/фича, что рядом, источник требований, дата. 2. **Чек-лист** — сгруппированные пункты (только релевантные группы) в виде `- [ ]` чекбоксов, конкретных под этот экран. 3. **Exploratory-charters** — 1–3 хартии по шаблону выше (если уместно). 4. **Что не проверялось** — ограничения покрытия. Держи компактным: убирай неприменимые группы целиком, не разбавляй пунктами «на всякий случай». Практичность и проходимость за один заход важнее полноты. ## ЗАПУСК 1. САМ определи SCOPE (раздел выше) — тип входа, экран/фича, соседние экраны, роли и поля из кода/ТЗ. Не делегируй: субагент не знает контекст диалога. 2. Классифицируй экран (форма ввода / список с фильтрами / мастер-флоу / дашборд / настройки) и выбери релевантные группы, наполнив их конкретикой: реальными именами полей, статусов, ролей, а не абстракциями. 3. Собери чек-лист чекбоксами, добавь exploratory-charter(ы), отметь непроверяемое. 4. Сохрани в `docs/qa/checklists/.md`. Если файл уже есть — обнови его, а не пересоздавай. Это ручная проверка/приёмка, а не автоматизация и не имплементация: чек-лист — инструмент для человека, код проекта не изменяется.