Тест-план и стратегия

Тест-план отвечает на четыре вопроса: что проверяем, что не проверяем, когда начинаем и когда имеем право сказать «хватит».

Тест-план — документ, который фиксирует объём, подход, сроки и ресурсы тестирования, а также критерии его начала и завершения. Тестовая стратегия — уровнем выше: как в этой компании принято тестировать вообще, независимо от конкретного проекта.

Слово «план» пугает новичка: представляется тридцатистраничный документ по ГОСТу, который никто не читает. Такие правда бывают — в госконтрактах и медицинском софте, где его требует регулятор. Но суть тест-плана не в объёме. Суть в том, что до начала работы команда договорилась о границах и о финише. Без этого тестирование не заканчивается — оно прекращается, когда кончилось время, и никто не может ответить, всё ли проверено.

Что тестируем и что НЕ тестируем

Первая половина плана — про объём (scope). И вторая колонка тут важнее первой: список «вне объёма» экономит недели.

В объёме (In scope)	Вне объёма (Out of scope)
Оформление заказа: корзина, промокоды, доставка, оплата картой	Оплата через СБП — фича выйдет в релизе 2.16, тестируем тогда
Браузеры: Chrome, Safari, Яндекс.Браузер — последние две версии	Internet Explorer, Opera Mini — по аналитике меньше 0,3% пользователей
Мобильная вёрстка: iPhone 13/15, Samsung A54	Планшеты — макетов нет, дизайн не рисовался
Функциональное и регрессионное тестирование	Нагрузочное — заказчик отказался, проводится отдельным подрядчиком
Проверка API заказов (контракты, коды ответов)	Пентест и безопасность — делает внешняя команда в августе
Русская локализация	Английская локализация — тексты ещё не переведены

Строчка «Планшеты — вне объёма, макетов нет» стоит две минуты работы, а спасает от разговора после релиза: «А почему на iPad всё разъехалось? Вы же тестировали!» Тестировали. И письменно предупредили, что планшеты не смотрим — вот дата, вот согласование. Тест-план в этом смысле ещё и способ распределить ответственность честно, а не задним числом.

Критерии входа и выхода

Дальше — два списка, которые превращают тестирование из «работаем, пока не надоест» в процесс с началом и концом.

Критерии входа (Entry criteria) — при каких условиях мы вообще беремся за тестирование сборки. Смысл в том, чтобы не тратить дни на заведомо сломанную версию.

Сборка развёрнута на стенде stage и открывается.
Smoke-набор из 15 проверок пройден разработчиком.
Требования по фиче согласованы, макеты в Figma финальные.
Тестовые данные подготовлены: аккаунты, товары, промокоды.
Известные блокирующие баги предыдущей сборки закрыты.

Критерии выхода (Exit criteria) — при каких условиях мы имеем право сказать: тестирование завершено, релиз можно выпускать. Формулируются числами, иначе ими нельзя пользоваться.

Пройдено 100% кейсов приоритета High и не менее 90% Medium.
Открытых багов severity Blocker и Critical — ноль.
Major — не более трёх, и по каждому есть согласие владельца продукта выпустить как есть.
Все Critical-баги, найденные в этой итерации, перепроверены на финальной сборке.
Отчёт о тестировании отправлен и принят.

Есть и третий, реже упоминаемый список — критерии приостановки. Если в первый же час smoke падает на трети проверок, тестирование останавливают и возвращают сборку разработке. Иначе тестировщик неделю мужественно заводит багов на заведомо сырую версию, а потом всё придётся перепроверять.

Риски

Риск — то, что может пойти не так и повлиять на сроки или качество. Их выписывают заранее с оценкой вероятности, влияния и планом действий.

Риск	Вероятность	Влияние	Что делаем
Платёжный шлюз не даст тестовый доступ вовремя	Средняя	Высокое: оплату не проверить	Заказать доступ за 2 недели; на подстраховку — мок сервиса
Единственный тестировщик уходит в отпуск в неделю релиза	Высокая	Высокое	Кейсы по оплате описать подробно, чтобы прогнал разработчик
Требования по промокодам меняются на ходу	Высокая	Среднее: кейсы придётся переписывать	Не писать подробных кейсов до заморозки требований, обойтись чек-листом
Stage-стенд не совпадает с продом по версии базы	Низкая	Высокое: часть багов не воспроизведётся	Сверить версии до начала тестирования

Отсюда растёт risk-based testing — подход, при котором глубина проверки зависит от риска. Оплата: сотня кейсов, негативные сценарии, проверка на реальных суммах. Страница «О компании»: открылась, тексты на месте, идём дальше. Тестировать всё одинаково тщательно невозможно — времени не хватит никогда, — поэтому вопрос не «проверили ли мы всё», а «где мы можем позволить себе не проверять».

Тест-план на одну страницу

Так это выглядит в обычной продуктовой команде, где никакого ГОСТа нет. Достаточно, чтобы поместиться в описание эпика в Jira.

ТЕСТ-ПЛАН: Оформление заказа, релиз 2.15
Дата: 14.07.2026   Автор: Анна К.   Версия: 1.0

1. ОБЪЁМ
   В объёме:   корзина, промокоды, доставка, оплата картой, письмо-подтверждение
   Вне объёма: СБП (релиз 2.16), планшеты (нет макетов), нагрузка (подрядчик)

2. ПОДХОД
   Функциональное + регрессия (набор Regression-Checkout, 214 кейсов)
   Уровни: API (Postman) и UI (руками)
   Автотесты: smoke на 15 проверок, гоняется на каждом деплое

3. ОКРУЖЕНИЯ
   stage.shop.test, сборка 2.15.x
   Chrome 126, Safari 17, Яндекс.Браузер; iPhone 13/15, Samsung A54

4. КРИТЕРИИ ВХОДА
   Сборка развёрнута; smoke пройден; макеты финальные; тестовые данные готовы

5. КРИТЕРИИ ВЫХОДА
   100% High + 90% Medium пройдено; 0 Blocker/Critical; не более 3 Major
   с письменным согласием PO; отчёт отправлен

6. КРИТЕРИИ ПРИОСТАНОВКИ
   Более 30% smoke упало → сборка возвращается разработке

7. РИСКИ
   Доступ к платёжному шлюзу (митигация: мок)
   Отпуск тестировщика на неделе релиза (митигация: кейсы + подмена)

8. РЕСУРСЫ И СРОКИ
   1 тестировщик, 6 рабочих дней: 3 — новая функциональность, 2 — регрессия,
   1 — перепроверка починенного

9. ОТЧЁТНОСТЬ
   Статус в канале #qa-checkout ежедневно; итоговый отчёт — за день до релиза

Стратегия и план — не одно и то же

Тестовая стратегия	Тест-план
Одна на компанию или продукт, живёт годами	Свой на релиз, фичу или спринт
«Мы держим пирамиду тестов, автотесты обязательны для платежей, регрессию гоняем еженедельно, баги severity Critical чиним в тот же день»	«В релизе 2.15 проверяем корзину и оплату, не проверяем СБП, финиш — ноль критикалов»
Отвечает на «как мы тестируем вообще»	Отвечает на «что делаем в этот раз»
Пишет ведущий QA или QA-лид	Пишет тестировщик, ведущий фичу

Как это работает

«Мы работаем по Agile, у нас нет документов» — самая частая отговорка. Только в Agile план не исчезает, он сжимается и переезжает в другое место.

В описание задачи. Секция «Как тестируем»: три строки о том, что проверяем и что нет. Пишется вместе с аналитиком до начала разработки — и уже на этом этапе половина вопросов к требованиям всплывает наружу.
В Definition of Done. «Задача готова, когда: код в мастере, автотесты зелёные, чек-лист пройден, багов severity выше Minor нет». Это критерии выхода, просто в командной формулировке.
В release checklist. Перед каждым релизом — короткий список: регрессия прогнана, критикалов нет, откат проверен.

Так что вопрос не в том, есть ли у команды тест-план как файл. Вопрос в том, может ли команда за пять секунд ответить, что считается «протестировано». Если ответа нет — плана нет, независимо от того, сколько документов лежит в Confluence.

Частые ошибки

План ради плана. Тридцать страниц, из которых двадцать — копипаста прошлого проекта с чужими фамилиями. Такой документ не читают, и он вредит: создаёт иллюзию, что договорённости есть.
Нет раздела «вне объёма». Самая дорогая ошибка. Всё, что не выписано явно как непроверяемое, по умолчанию считается проверенным — и спрос будет с тебя.
Критерии выхода без чисел. «Качество приемлемое, критичных багов нет» — «приемлемое» по чьему мнению? Формулируй так, чтобы два человека независимо пришли к одному вердикту.
План написан и забыт. Скоуп сдвинулся, сроки съехали, а в документе всё по-старому. План — живой: меняются условия, меняется и он, с новой версией и датой.
Риски написаны, но без плана действий. «Риск: может не хватить времени». Спасибо. Без митигации это не риск, а прогноз погоды.
Сроки посчитаны только на первый прогон. Забыли про перепроверку починенных багов и повторную регрессию — а это обычно ещё треть времени сверху.

Итоги

Тест-план фиксирует объём, подход, сроки, риски и критерии начала и завершения тестирования.
Раздел «вне объёма» ценнее раздела «в объёме»: он защищает и команду, и тебя лично.
Критерии входа не дают тестировать заведомо сломанную сборку; критерии выхода дают право сказать «готово» — и формулируются числами.
Риски пишутся с митигацией, иначе это просто список опасений. Отсюда же risk-based testing: глубина проверки пропорциональна цене ошибки.
Стратегия — как тестируем вообще, план — что делаем в этом релизе.
В Agile план не исчезает, а переезжает в описание задачи, Definition of Done и release checklist. Проверка простая: команда должна уметь ответить, что для неё значит «протестировано».