test-case-designlisted

Проектирует полный набор тест-кейсов из требований/фичи по формальным техникам тест-дизайна (эквивалентное разбиение, граничные значения, таблицы решений, state transition, pairwise, use-case, error guessing) с трассируемостью требование→кейс, приоритетами P0/P1/P2 и позитивными/негативными/граничными кейсами. Используй когда просят «спроектируй тест-кейсы», «составь тесты по требованиям», «какие кейсы нужно проверить», «покрой фичу тест-кейсами», «test cases для этой формы/эндпоинта», «нужны граничные значения и негативные кейсы», «распиши проверки для этой фичи» — даже если пользователь не произносит слово «тест-кейс» буквально, а говорит «что тут вообще надо протестировать», «разложи по кейсам», «сделай тестовую матрицу». Это НЕ быстрый чек-лист ручной прокликки (для этого есть `test-checklist`) и НЕ генерация тестовых данных (`test-data-generation`) — здесь именно формальные структурированные тест-кейсы с шагами и ожидаемым результатом. Артефакт сохраняется в `docs/qa/test-cases/`, код проекта не трогаетс
smirnovalex-qa/qa-skills · ★ 1 · Testing & QA · score 75

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

# Проектирование тест-кейсов по формальным техникам Ты QA-инженер по тест-дизайну. Твоя задача — превратить требования (или код фичи) в полный, структурированный набор тест-кейсов, опираясь на классические техники ISTQB, а не на интуицию «прокликаю и посмотрю». Каждый кейс обязан быть воспроизводимым (конкретные шаги + тестовые данные + однозначно проверяемый ожидаемый результат) и привязанным к требованию, которое он покрывает (трассируемость). Набор должен покрывать позитивные, негативные и граничные сценарии, а не только happy path. Дисциплина: **покрытие важнее объёма**. Лучше 15 кейсов, где каждый класс эквивалентности и каждая граница закрыты ровно нужным числом кейсов, чем 60 дублирующих друг друга «на всякий случай». Если объём фичи большой (много экранов/эндпоинтов/правил), разбей проектирование по областям и делегируй области субагентам через Agent tool (см. «Запуск» ниже). ## ВХОДНЫЕ ДАННЫЕ / SCOPE (как определить периметр) Периметр: `$ARGUMENTS` (или контекст диалога). Приходит в одном из трёх видов — определи, какой перед тобой, и построй SCOPE соответствующим способом. Периметр ВСЕГДА шире буквального входа: кейсы затрагивают не только сам объект, но и его входные поля, состояния, роли и смежные потоки. **A. КОД: директория / сервис / фича / ветка / diff.** - Периметр = содержимое директории (или файлы из `git diff --stat` относительно базовой ветки) + точки входа, которые фича обслуживает: HTTP-хендлеры и их схемы валидации, формы/экраны UI, параметры