Тест-план: документ на одну страницу, который реально читают

Тест-план нужен не для галочки, а чтобы команда и заказчик одинаково понимали, что проверяется, на чём, когда и по каким критериям релиз считается готовым. Если документ не помещается на страницу, его не прочитают — и это хуже, чем если бы его не было.

Семь разделов, которых достаточно

• Объём: какие фичи, экраны и сценарии входят в проверку и, что важнее, какие не входят. Границы спасают от споров после релиза.
• Окружения и устройства: стенды, сборки, список устройств и браузеров с указанием, что проверяется на реальных устройствах, а что в эмуляторе.
• Виды тестирования: функциональное, регрессионное, нагрузочное, LQA — с ответом «зачем именно здесь».
• Критерии входа и выхода: когда можно начинать (сборка стабильна, тестовые данные готовы) и когда можно заканчивать (все блокеры закрыты, доля пройденных кейсов, открытые дефекты согласованы).
• Риски и допущения: что может сорвать сроки — поздняя сборка, недоступный платёжный стенд, отсутствие тестовых аккаунтов — и что делаем в этом случае.
• Расписание и роли: кто и в какие дни прогоняет, кто принимает решение о релизе.
• Артефакты: что заказчик получит на выходе — тест-кейсы, отчёт, реестр дефектов, протоколы.

Чего в тест-плане быть не должно

Переписанных требований — на них достаточно ссылки. Списка всех тест-кейсов — для этого есть трекер. Общих фраз про «обеспечение качества» и «методологии». Истории версий документа на три страницы. Всё это раздувает план до размера, при котором его открывают один раз — чтобы подписать.

Критерии выхода — самая важная часть

Именно критерии выхода превращают тест-план из описания в договор. Без них «мы протестировали» означает что угодно. Рабочая формулировка выглядит так: регрессионный набор пройден полностью на основных окружениях; блокеров и критичных дефектов нет; список открытых дефектов ниже critical согласован владельцем продукта; отчёт и реестр дефектов переданы. Любое отклонение от критериев — осознанное решение бизнеса, зафиксированное письменно, а не «ну, вроде работает».

Как план живёт после написания

1. Согласуется с владельцем продукта и командой разработки до начала работ — замечания правятся сразу.
2. Становится приложением к договору или задаче: объём и критерии фиксированы.
3. Обновляется при изменении объёма — новая фича, новое окружение, перенос срока — отдельной строкой в разделе изменений.
4. Сверяется при приёмке: отчёт о тестировании ссылается на критерии выхода из плана.

Пример объёма для небольшого релиза

Релиз мобильного приложения с новой механикой промокодов. Входит: применение промокода во всех точках входа, расчёт скидки, ограничения, уведомления, регрессия корзины и оплаты на iOS и Android, LQA на двух языках. Не входит: личный кабинет, кроме истории заказов; веб-версия. Окружения: предпродакшен с боевыми настройками шлюза в тестовом режиме. Устройства: две модели iOS, три Android, включая бюджетную. Критерии выхода: регрессия пройдена, блокеров нет, открытые дефекты согласованы. Срок: три дня тестирования плюс день на повторную проверку исправлений.