processcareer

Test Plan vs Test Strategy: разница, которую важно понимать

Test Plan и Test Strategy — два документа, которые часто путают, объединяют, или один называют другим. На собеседованиях на сеньора это типичный вопрос. Разбираемся.

Test Strategy

Что это: общий подход к тестированию на уровне организации или продукта.

Жизненный цикл: долгосрочный — год+. Не меняется на каждый спринт.

Содержит:

  • Какие типы тестирования применяем (manual, automation, performance, security).
  • Какие тулы используем (Playwright, JMeter, Jira).
  • Принципы автоматизации (что автоматизируем, что нет, target coverage).
  • Окружения (dev, staging, prod, отдельный QA-стенд).
  • Метрики качества (DOP, escape rate, MTTR).
  • Кто отвечает за что (QA, devs, SRE).

Кто пишет: QA-лид, head of QA, иногда тимлиды.

Аудитория: вся команда + менеджмент.

Test Plan

Что это: детальный план тестирования для конкретного релиза или фичи.

Жизненный цикл: краткосрочный — недели/месяцы. Создаётся на каждый крупный релиз или проект.

Содержит:

  • Scope: что тестируем, что нет.
  • Test cases (или ссылки на них).
  • Расписание: когда что прогоняем.
  • Команда: кто что делает.
  • Окружения: на чём тестируем.
  • Risks: что может пойти не так.
  • Acceptance criteria: что значит «релиз можно выпускать».

Кто пишет: QA-инженер, иногда лид.

Аудитория: команда фичи + менеджер.

Аналогия

— Strategy — это «как мы вообще тестируем в этой компании». — Plan — это «как мы будем тестировать конкретно эту фичу».

Стратегия отвечает на «что и почему». План — на «как, когда, кто».

Когда не нужны

В мелких командах (до 5 человек) формальная Test Strategy — избыточна. Достаточно одностраничного «у нас Playwright для E2E, pytest для API, smoke раз в день» в Notion.

Test Plan тоже не всегда нужен — для багфикса в 50 строк кода писать план на 5 страниц глупо. Но для нового модуля или большой фичи — обязательно.

Что писать в первую очередь

Если в команде нет ни того ни другого — начинай с Test Strategy. Это даёт фундамент:

  • Команда знает на чём остановились в тулах.
  • Новый QA через 2 года читает и понимает контекст.
  • Менеджмент видит что «у нас системный подход».

Test Plans будут появляться органически — для конкретных релизов.

Шаблоны

Strategy (минимум):

1. Цель тестирования
2. Scope продукта (что покрываем)
3. Виды тестирования
4. Тулы
5. Окружения
6. Команда
7. Метрики
8. Риски

Plan (минимум):

1. Релиз/фича + scope
2. Что тестируем (test cases)
3. Что не тестируем (out of scope)
4. Расписание
5. Команда
6. Окружения
7. Acceptance criteria
8. Известные риски

Что делать сейчас

✅ Глянь — есть ли в команде Test Strategy. Если нет — предложи написать.

✅ Для следующего крупного релиза — попробуй Test Plan. Даже простой 1-страничный.

✅ Если эти документы есть, но устарели — переписать. Документ который устарел хуже отсутствующего.

Подробнее: ISTQB Glossary — Test Plan, Ministry of Testing — Strategy.