Test Plan — это документ, который объясняет, что, зачем, как, кем и в каких условиях будет тестироваться. Его ценность не в объёме текста, а в том, что он создаёт общее понимание подхода и границ проверки.
Когда test plan действительно нужен
- →Функциональность большая, рискованная или затрагивает несколько команд.
- →Нужно явно зафиксировать scope, приоритеты, окружения, роли и критерии готовности.
- →Есть внешние ожидания: аудит, compliance, регуляторика, формальная отчётность.
- →Без согласованного плана команда начнёт по-разному понимать глубину и границы тестирования.
Что обычно включает хороший plan
- →Цели тестирования и ключевые риски.
- →Scope и out of scope.
- →Типы и уровни тестирования, которые будут применяться.
- →Окружения, тестовые данные и зависимости.
- →Роли, ответственность, тайминг и критерии завершения.
Каким он не должен быть
- →Слишком общим и шаблонным, без связи с конкретным продуктом.
- →Перегруженным информацией, которую никто не использует.
- →Мёртвым документом, который пишется один раз и потом не обновляется.
- →Подменой реального мышления о рисках и стратегии.
Практическая best practice
Хороший test plan отвечает на реальные вопросы команды: что критично, где риски, что мы не проверяем, чего нам не хватает для качества и на основании чего будет приниматься релизное решение. Если документ не помогает принять решения, он слишком тяжёлый или слишком абстрактный.
Заполненный пример: небольшой релиз формы оплаты
Все сведения ниже — вымышленные учебные условия, а не отчёт о банке, клиенте или выпущенном релизе. Приложение принимает синтетические платёжные токены и обращается к локальному stub с исходами approved, declined или timeout. Реальных карт, аккаунтов и денег нет. Сумма задана целым числом центов в одной явно настроенной учебной валюте.
План: PAY-DEMO-1; версия 1; роль владельца: QA-инженер
Цель: проверить форму оплаты и не допустить повторной успешной оплаты.
Объект: фиксированная учебная сборка; перед запуском записать реальный commit и конфигурацию.
В scope: отправка, валидация, исходы провайдера, повторы запроса/callback, обновление результата, клавиатура и ширина 375 px.
Вне scope: live-провайдер, реальные расчёты, возвраты, подписки, 3-D Secure, другие валюты, нагрузочная/безопасностная сертификация.
Среда: изолированное локальное приложение + stub провайдера + тестовая БД.
Данные: новый синтетический клиент/заказ на кейс; сброс журнала stub перед каждым кейсом.
Наблюдение: ID запросов, журнал оплат stub, чтение записей заказов.
Роли: один QA; разработчик помогает исправлять; владелец продукта принимает остаточный риск.
Оценка, не обязательство: два дня по 6 QA-часов; 2 часа помощи разработчика; 1 час проверки владельцем.
Результаты: связь требований и кейсов, лог выполнения, очищенные доказательства, дефекты, рекомендация по релизу.Проверки по рискам с наблюдаемым результатом
C01–C08, C11 и C12 в примере имеют высокий риск: дубли оплат, неверная сумма, ложный успех и ошибки повторов нарушают финансовое состояние. C09–C10 проверяют удобство и тоже входят в объём. Ожидания ниже — требования демо, а не универсальные правила платёжного API.
ID Сценарий Ожидание
C01 Токен approved Один подтверждённый заказ на 1999 центов; одна принятая оплата
C02 Токен declined Сообщение об отказе; нет оплаченного заказа и успешной оплаты
C03 Токен timeout Показано ожидание/неизвестный итог; нет автоматической второй оплаты
C04 Два запроса с теми же ключом и payload Один сохранённый результат; одна оплата и один заказ
C05 Тот же ключ, изменённая сумма Сообщение о конфликте; нет новых оплаты и заказа
C06 Нет платёжного токена Ошибка поля; платёжный запрос не отправлен
C07 API получает нулевую сумму Отказ API; нет оплаты и заказа
C08 Повтор успешного callback Один переход в paid; в платёжном журнале один успех
C09 Только клавиатура Все элементы доступны; отправка и ошибки доступны без мыши
C10 Ширина 375 px Нет горизонтального скролла; видны сумма и кнопка отправки
C11 Обновить страницу результата Показан существующий заказ; оплата не отправлена повторно
C12 Проверить операцию на 1999 центов Сумма и валюта совпадают в UI, запросе и заказеКритерии входа, приостановки и выхода
Вход: согласованы все 12 ожидаемых исходов; записана сборка; проверены режимы stub approved/declined/timeout; создан тестовый клиент; журнал оплат доступен; smoke среды пройден. Если пункт не выполнен, зафиксируйте блокер вместо отметки о полном тестировании.
Приостановить проверки, если журнал недоступен, данные не сбрасываются или обнаруженные дубли оплат делают следующие кейсы недостоверными. Сохранить доказательства. Возобновить после исправления причины, успешного smoke, сброса и повторного запуска затронутых кейсов.
Выход для рекомендации: все 12 кейсов выполнены с доказательствами; 10 высокорисковых пройдены; C09 и C10 пройдены либо есть документированное исключение с ответственным; нет открытых дефектов с дублем успеха, неверной суммой или ложным статусом; исправленные высокорисковые дефекты перепроверены, затронутый регресс пройден. Явно перечислить непроверенные функции. Само наступление дедлайна критериям не соответствует.
Пример расписания: день 1 — требования 1ч, среда/данные 1ч, подготовка кейсов 2ч, выполнение 2ч. День 2 — остальное выполнение 2ч, исправления и retest 2ч, затронутый регресс 1ч, отчёт 1ч. При изменении контракта провайдера или замене сборки пересмотрите оценку и затронутые результаты; не сохраняйте старое «пройдено» без проверки.
Шаблон для копирования
План / версия / ответственный:
Изменение и бизнес-цель:
Объект / сборка / конфигурация:
Требования и ключевые риски:
В scope / вне scope:
Среда / синтетические данные / сброс:
Способы наблюдения и доказательства:
ID кейсов, связь с риском и ожидаемыми исходами:
Роли / доступное время / оценка / зависимости:
Критерии входа:
Приостановка / возобновление:
Критерии выхода и ответственный за решение:
Остаточный риск / исключения / дата пересмотра:
Ссылка на отчёт выполнения:План определяет будущую работу и не утверждает, что двенадцать кейсов пройдены в реальном платёжном приложении. При выполнении добавляйте факт, статус, доказательства и дефекты. Передавайте принимающему решение покрытие и оставшийся риск, а не только процент успешных тестов.
Продолжить изучение
Связь плана релиза со стратегией
Организация релизного тестирования