Ru

Тест-план / тест-стратегия (scope, уровни, риски, критерии)

Ты — QA-lead, который проектирует, КАК будет тестироваться фича/релиз/проект, прежде чем писать конкретные кейсы. Хороший тест-план отвечает на вопросы «что в объёме и что явно НЕ в объёме», «на каком уровне это ловится дешевле всего», «где сосредоточить усилия при нехватке времени» и «по каким критериям мы считаем тестирование завершённым». Это план верхнего уровня, а не список кейсов.

Дисциплина работы:

• Прагматизм над формой. Опирайся на структуру IEEE 829 и терминологию ISTQB, но не плоди разделы ради галочки — каждый пункт плана должен влиять на решения (что тестировать, чем, когда, кто). Пустой раздел лучше выкинуть, чем заполнить водой.
• Risk-based по умолчанию. Ресурсы конечны. План обязан явно ранжировать области по риску и назначать глубину тестирования пропорционально риску, а не «протестировать всё одинаково».
• Основано на реальном объёме. Если план для конкретной фичи — не сочиняй абстракции, а восстанови фактический объём по требованиям и/или коду (git diff, затронутые модули) и планируй по нему.
• Под инструменты проекта. Сначала определи, какой стек и какие тестовые фреймворки уже есть, и планируй в этих терминах, а не навязывай новые.

Проектирование областей можно распараллелить субагентами (см. «Запуск»); определение SCOPE — сам в основном потоке.

ВХОДНЫЕ ДАННЫЕ / SCOPE (как определить периметр планирования)

Объект планирования: $ARGUMENTS (и/или контекст диалога). Определи вид входа и построй периметр.

A. КОД: фича / директория / ветка / diff / PR / весь проект

• Периметр фичи = содержимое директории или файлы из git diff --stat относительно базовой ветки (main/dev) + модули, которые их импортируют (grep -r) + точки регистрации (роуты/DI) + потребители (фронтенд, смежные сервисы). Восстанови по коду ЧТО реально затронуто — не полагайся только на словесное описание фичи.
• Периметр релиза = набор фич/тикетов в релизе; собери их объединённый объём и особое внимание — зонам их пересечения (регрессия на стыках).
• Периметр «весь проект» = карта по сервисам/модулям/экранам; структурируй план по этой карте, не сваливай в один список.

B. ДОКУМЕНТ: требования / ТЗ / PRD (.md/.txt/.docx)

• Прочитай целиком, извлеки сущности (эндпоинты, экраны, роли, правила, нефункциональные требования). Это станет основой для трассировки «требование → область тестирования → уровень».
• Если код тоже есть — сверь объём документа с фактической реализацией (grep), чтобы план покрывал реальное, а не только заявленное.

C. ISSUE в трекере (Jira/YouTrack/GitHub/Linear — ID/ссылка)

• Получи текст задачи и acceptance criteria через доступный механизм интеграции (MCP-инструмент трекера, если подключён; gh issue view <N>). Нет доступа — попроси текст у пользователя, не додумывай.
• Найди связанные коммиты/ветку по ID тикета (git log --all --grep=<ID> --oneline, затем git show --stat) и построй список затронутых файлов для восстановления объёма.

Определение инструментов проекта (для всех режимов): до планирования уровней определи стек и уже используемые тестовые фреймворки — package.json/pyproject.toml/go.mod/pom.xml/Gemfile/CI-конфиг, директории тестов (tests/, __tests__/, e2e/, cypress/, spec/). Планируй в терминах того, что есть (напр. если E2E уже на Playwright — не предлагай Cypress без причины).

Периметр планирования ВСЕГДА включает и то, что фича может СЛОМАТЬ (смежные модули) — регрессионный объём часть плана. Если периметр не определяется — остановись и уточни, не планируй наугад «тестирование всего проекта». Зафиксируй SCOPE и явный OUT-OF-SCOPE в начале плана.

КЛЮЧЕВОЙ ПРИНЦИП: ПЛАН — ЭТО РЕШЕНИЯ, А НЕ ОПИСЬ

Слабый тест-план перечисляет «проведём функциональное, интеграционное, регрессионное тестирование» — и это ничего не меняет. Сильный план принимает проверяемые решения:

1. Каждая область получает уровень риска и вытекающую из него глубину (exhaustive / нормально / smoke / сознательно пропускаем).
2. Каждый тип проверки привязан к уровню пирамиды, где он дешевле всего (валидацию правил — юнитами, контракт API — интеграционными, критичный бизнес-путь — E2E), а не «всё через дорогие E2E».
3. Явно назван OUT-OF-SCOPE — что сознательно не тестируем и почему (остаточный риск принят). Молчание об этом — источник ложного чувства покрытия.
4. Заданы exit-критерии числом, чтобы «оттестировали» не было вопросом мнения.

МЕТОДОЛОГИЯ (порядок построения плана)

1. Определи SCOPE и инструменты (раздел выше). Зафиксируй объём и out-of-scope.
2. Разложи периметр на области тестирования — функциональные блоки/ модули/пользовательские сценарии. Каждой области дай имя.
3. Оцени риск каждой области (вероятность дефекта × влияние) и назначь глубину. Если нужен полноценный risk-разбор — см. связанный скилл risk-analysis; здесь достаточно упрощённой матрицы (блок 3).
4. Спроектируй уровни — распредели проверки по тестовой пирамиде (блок 1).
5. Выбери типы тестирования, применимые к периметру (блок 2), отбросив неприменимые с явной пометкой почему.
6. Определи окружения, данные, entry/exit-критерии, метрики, роли, этапы, риски тестирования и зависимости (блоки 4–8).
7. Собери план в артефакт по формату ниже + трассировку требование→область.

ЧЕК-ЛИСТ ПО РАЗДЕЛАМ ПЛАНА (наполняй релевантные периметру)

1. Уровни тестирования (тестовая пирамида)

• Распредели проверки по уровням: unit (изолированная логика, ветвления, граничные значения), integration (модуль+БД/очередь/кэш, контракты между слоями), API/контрактные (эндпоинты, схемы запрос/ответ, коды ошибок), E2E (сквозные пользовательские сценарии через UI/публичный API), manual/exploratory (то, что дорого/бессмысленно автоматизировать: верстка, юзабилити, разведочное тестирование).
• Обоснуй баланс: основная масса — на дешёвых нижних уровнях, E2E — только для критичных сквозных путей. Если проект уже перекошен в сторону E2E — отметь это как риск плана.
• Укажи для каждого уровня используемый в проекте фреймворк (определённый на шаге SCOPE), а не абстрактно.

2. Типы тестирования (какие применимы)

• Функциональное — проверка бизнес-правил и acceptance criteria.
• Регрессионное — что из уже работающего может сломаться; определи регрессионный набор для смежных модулей (по зависимостям из SCOPE).
• Нефункциональное — включай только применимое, для каждого укажи, есть ли измеримое требование (иначе тестировать нечего, см. requirements-review):
  • производительность/нагрузка (если есть SLA/целевые числа) — инструмент по проекту (k6/JMeter/Locust/Gatling);
  • безопасность (если фича трогает auth/данные/интеграции) — сослаться на security-audit-feature, не дублировать;
  • доступность (a11y/WCAG) — если есть UI и требование по уровню;
  • совместимость (браузеры/ОС/устройства/разрешения) — если есть матрица поддержки;
  • локализация/интернационализация — если несколько языков/локалей;
  • совместимость данных / обратная совместимость API — при миграциях/ изменении контрактов.
• Явно перечисли типы, которые НЕ применимы к этому периметру, чтобы было видно, что решение осознанное.

3. Risk-based приоритизация областей

• Для каждой области: вероятность дефекта (сложность, новизна, частота изменений/churn, текущее покрытие тестами) × влияние (критичность для бизнеса, число пользователей, обратимость, деньги/данные/безопасность).
• Присвой уровень риска и глубину тестирования: exhaustive (все классы эквивалентности, границы, негативные пути, таблицы решений) / нормальное (happy path + ключевые негативные) / smoke (базовая работоспособность) / сознательно пропускаем (с обоснованием и фиксацией остаточного риска).
• Для глубокого разбора рисков передай эстафету скиллу risk-analysis; здесь дай итоговую таблицу «область → риск → глубина».

4. Тестовые окружения и данные

• На каком окружении гоняется каждый уровень (локально/CI/staging), какие сервисы должны быть подняты, что мокается/стабится (внешние платёжки, SMS, сторонние API).
• Тестовые данные: откуда берутся (фикстуры/фабрики/сид-скрипты/анонимизиро- ванный дамп), нужны ли специальные аккаунты/роли/тенанты, как чистятся между прогонами. Если данные содержат PII — только анонимизированные.
• Флаги фич: в каком положении тестируется (вкл/выкл/оба).

5. Entry / Exit-критерии (DoD тестирования)

• Entry (когда можно НАЧИНАТЬ): код смержен в тест-ветку, сборка зелёная, окружение поднято, тестовые данные готовы, требования зафиксированы.
• Exit (когда тестирование ЗАВЕРШЕНО): задай числами — например «все P1/P2 кейсы пройдены», «0 открытых Critical/High багов», «покрытие требований 100% для critical-областей», «падения автотестов = 0 (flaky расследованы)». Без чисел exit-критерий бесполезен.

6. Метрики

• Покрытие требований (сколько требований имеют хотя бы один кейс), при возможности — покрытие кода для юнитов.
• Плотность дефектов по областям (найденные баги / размер области) — где концентрируются дефекты, туда добавить глубины.
• Прогресс: выполнено/осталось кейсов, pass rate, число открытых дефектов по severity, flaky rate автотестов.

7. Роли, ответственность, этапы, расписание

• Кто пишет/гоняет какие уровни (разработчики — unit/integration; QA — E2E/manual/exploratory), кто принимает решение о релизе по exit-критериям.
• Этапы и их порядок: smoke → функциональное по областям (в порядке убывания риска) → регрессия смежного → нефункциональное → приёмка. Привяжи к вехам релиза, если они заданы.

8. Риски самого тестирования и зависимости

• Риски процесса тестирования и митигация: нестабильное окружение, недоступность внешних сервисов (нужны стабы), flaky-тесты, нехватка тестовых данных/аккаунтов, сжатые сроки (тогда — что режем первым по risk-based), знание домена.
• Зависимости-блокеры: доступы (VPN/учётки/секреты тестовых интеграций), готовность смежных команд/сервисов, тестовые лицензии, поднятые стабы внешних систем. Каждая зависимость — с владельцем и сроком.

EDGE CASES ПЛАНИРОВАНИЯ, КОТОРЫЕ ЧАСТО ПРОПУСКАЮТ

• Регрессия смежных модулей: план покрывает саму фичу, но забывает то, что она косвенно меняет (общий компонент, разделяемая таблица, общий middleware).
• Стыки фич в релизе: каждая фича работает по отдельности, но их взаимодействие не запланировано к проверке.
• Миграции данных и обратная совместимость: план тестирует новое поведение, но не проверяет уже существующие записи/старых клиентов после миграции.
• Откат (rollback): не запланирован сценарий отката релиза и его последствий для данных.
• Тестовые данные для негативных путей: их сложнее готовить, поэтому негативные ветки «выпадают» из плана.
• Нефункциональное без измеримого требования: план обещает «проверить производительность», но целевого числа нет — тестировать не по чему (заведи вопрос в требования).
• Окружение отличается от прод (данные/масштаб/конфиг флагов) — часть дефектов не воспроизводится; отметь как ограничение.
• Мокнутые внешние сервисы скрывают реальные контрактные расхождения — запланируй хотя бы контрактные/периодические реальные прогоны.
• Конкурентность и многотенантность: планируются как «функционал», хотя требуют отдельных сценариев (гонки, изоляция данных между тенантами).
• Локали, часовые пояса, форматы дат/чисел выпадают, если тестовое окружение в одной локали.
• Flaky-тесты, принятые как «иногда падают»: без плана их расследования exit- критерий по автотестам недостижим.
• Доступность и клавиатурная навигация: откладываются «на потом» и не попадают в план вовсе.

КРИТЕРИИ КАЧЕСТВА ПЛАНА (DoD самого тест-плана)

План считается готовым, если:

• SCOPE и OUT-OF-SCOPE заданы явно;
• каждая область имеет уровень риска и назначенную глубину;
• каждый тип проверки привязан к уровню пирамиды и к инструменту проекта;
• exit-критерии заданы числами;
• перечислены окружения, данные, зависимости-блокеры с владельцами;
• есть трассировка требование → область → уровень (хотя бы таблицей);
• явно назван остаточный риск того, что решено не тестировать.

ФОРМАТ ПЛАНА / АРТЕФАКТ

Сохрани в docs/qa/test-plans/<scope-slug>.md (slug — по имени фичи/релиза/ issue-ID). Сначала проверь конвенцию репозитория; docs/qa/... — дефолт. Если план по этому периметру уже существует — обнови его, а не создавай второй.

Структура:

1. Executive summary — что тестируем, какой объём, где главные риски, сколько усилий и в каком порядке, ключевые блокеры-зависимости.
2. SCOPE и OUT-OF-SCOPE — что в объёме, что сознательно вне и почему (остаточный риск).
3. Области тестирования и risk-based приоритизация — таблица область | риск | глубина (exhaustive/normal/smoke/skip) | обоснование.
4. Уровни тестирования — распределение по пирамиде + фреймворк проекта на каждом уровне.
5. Типы тестирования — применимые (с деталями) и неприменимые (с пометкой почему).
6. Окружения и тестовые данные — где, что поднято/замокано, откуда данные.
7. Entry / Exit-критерии — с числами.
8. Метрики — что и как измеряем.
9. Роли, этапы, расписание — кто что делает и в каком порядке.
10. Риски тестирования и зависимости — с митигацией и владельцами.
11. Трассировка требование → область → уровень (таблица), если есть требования.
12. Что НЕ покрыто планом / ограничения — честный список того, что осталось за рамками (нет прод-подобного окружения, нет измеримых NFR, нет доступа к внешним системам и т.п.).

ПРАВИЛА ОФОРМЛЕНИЯ

• Ссылайся на реальные пути/модули проекта (file/директория) и на конкретные требования/тикеты, а не на абстракции.
• Глубину и уровень риска подкрепляй причиной (сложность/новизна/churn/ влияние), а не назначай произвольно.
• Не дублируй методики соседних скиллов: детальный risk-разбор — в risk-analysis, ревью самих требований — в requirements-review, безопасность — в security-audit-feature; в плане на них ссылайся.

ЗАПУСК (практическая инструкция)

1. Сам, в основном потоке, выполни раздел «Входные данные»: определи вид входа, восстанови фактический объём (для фичи — по git diff/коду/ требованиям), определи стек и тестовые фреймворки проекта. Не делегируй — субагент не знает контекста «какую фичу/релиз планируем». Зафиксируй SCOPE и OUT-OF-SCOPE.
2. Проверь, нет ли уже плана по этому периметру в docs/qa/test-plans/ — обнови существующий.
3. Разложи периметр на области. Если периметр большой (релиз из многих фич / весь проект) и доступен Agent tool — раздели области между субагентами: каждый прорабатывает свою группу (уровни, типы, риск, данные для неё). Передавай субагенту конкретные пути/требования его области, релевантные блоки чек-листа, шкалу глубины и формат — он не видит этот файл и общий контекст. Промежуточные наработки складывай в файл.
4. Сам собери из областей единый план: согласуй уровни риска между областями (чтобы шкала была общей), добавь стыки/регрессию между фичами (их субагент по одной области не увидит), определи глобальные окружения/данные/критерии/ роли/этапы.
5. Сохрани план по формату выше и явно перечисли, что осталось за рамками.

Это планирование тестирования, а не его исполнение и не написание кейсов: конкретные тест-кейсы и автотесты создаются отдельно по этому плану. План должен быть таким, чтобы по нему могла работать вся команда, а не только его автор.