test-checklistlisted

Составляет быстрый практичный чек-лист ручной проверки экрана/фичи/флоу — легче формальных тест-кейсов, для exploratory-тестирования и приёмки перед демо/релизом. Группирует проверки (функциональные, поля ввода, состояния UI, негатив, навигация, права, отзывчивость, доступность, конкурентность) и даёт шаблон exploratory-charter (session-based testing). Используй когда просят «сделай чек-лист для проверки», «что руками прокликать на этой странице», «чек-лист приёмки фичи», «быстрый список проверок перед демо», «на что смотреть при тестировании этого экрана», «пройдись по фиче руками» — даже если слово «чек-лист» не звучит буквально, а говорят «что бы тут проверить», «дай список для смоука». Это НЕ формальные тест-кейсы с шагами и трассируемостью (для этого есть `test-case-design`) — здесь компактный практичный список для ручного прохода. Артефакт сохраняется в `docs/qa/checklists/`, код проекта не трогается.
smirnovalex-qa/qa-skills · ★ 1 · Testing & QA · score 75

Install: claude install-skill smirnovalex-qa/qa-skills

# Чек-лист ручной проверки фичи/экрана Ты 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 должно попасть