БЛОК 5. Документация тестирования — 17. Test Plan (обзор)
🧭 Введение: зачем QA нужен Test Plan
Test Plan — это короткий и понятный документ, который отвечает на вопрос:
как именно команда будет тестировать конкретный релиз или фичу.
Для junior важно понимать:
Test Plan не про "умные слова", а про рабочие действия.
Он помогает команде заранее договориться:
что проверяем, чем проверяем, где проверяем и когда считаем задачу готовой.
💡 Совет:
Пиши план так, чтобы новый человек в команде мог открыть документ и за 5 минут понять логику тестирования.
✅ Вывод:
Test Plan делает тестирование предсказуемым и помогает команде понять, выпускать релиз или нет.
⚠️ Проблема -> решение
Проблема: без плана тестирование часто идет "по памяти" и "по ощущениям".
В результате что-то проверяют слишком глубоко, а что-то вообще пропускают.
Решение: заранее зафиксировать минимальный план:
scope, подход, окружения, критерии старта/завершения, риски, формат отчета.
🟢 Если совсем просто:
Test Plan — это рабочая карта: что делаем, в каком порядке и как понимаем, что работа завершена.
🎯 Как понять, что этап прошел успешно:
После чтения плана у QA, dev и PM одинаковое понимание объема и рисков.
🛠️ Чем помогает и как работает
Хороший Test Plan помогает:
- не тратить время на споры в конце релиза;
- вовремя увидеть, что не хватает окружения или данных;
- заранее проговорить риски и план действий.
Как это работает:
- Шаг 1: определяем цель и scope.
- Шаг 2: выбираем подход к тестированию (smoke / regression / API / UI / exploratory).
- Шаг 3: фиксируем окружения, тестовые данные и зависимости.
- Шаг 4: задаем entry/exit criteria.
- Шаг 5: фиксируем риски и действия по ним.
- Шаг 6: определяем, в каком виде QA отдает итог релизу.
✅ Вывод:
Test Plan снижает хаос и делает решение о релизе прозрачным для всей команды.
📚 Ключевые термины (простыми словами)
- Test Plan — документ о том, как организовано тестирование релиза или фичи.
- Scope — что входит в проверку.
- Out of scope — что в эту проверку не входит.
- Entry criteria — условия, при которых можно начинать тестирование.
- Exit criteria — условия, при которых тестирование можно завершать.
- Risk — что может сломаться и насколько это больно для бизнеса/пользователя.
- Mitigation — что делаем заранее, чтобы снизить риск.
- QA summary — короткий итог тестирования для команды.
1. Мини-шаблон Test Plan для junior
Чтобы не перегружать себя, начинай с mini Test Plan.
Это практичный шаблон, который можно использовать почти в любой задаче.
Назначение:
Дать junior готовую структуру, которую можно заполнить сразу после анализа требований.
Простыми словами:
Это "скелет" документа: вставляешь свою фичу и заполняешь пункты.
Для новичка:
Если не знаешь, как начать писать план, начни с этих 10 пунктов.
Пример:
Mini Test Plan:1. Цель тестирования2. Scope3. Out of scope4. Окружение5. Подход к тестированию6. Entry criteria7. Exit criteria8. Риски9. Ответственные10. Формат QA summary🔎 Как это происходит на практике:
- QA создает мини-план в начале работы по задаче.
- На sync команда быстро валидирует scope и риски.
- После согласования документ становится рабочей базой для прогона.
✅ Вывод:
Mini Test Plan помогает junior быстро перейти от "не знаю, с чего начать" к понятному рабочему плану.
2. Когда Test Plan нужен, а когда достаточно checklist
Важно: Test Plan нужен не всегда.
Если писать полноценный план на каждую мелочь, команда утонет в документации.
Назначение:
Понимать, когда план обязателен, а когда можно работать проще.
Простыми словами:
Крупная или рискованная задача = нужен Test Plan.
Микро-фикс = часто достаточно checklist.
Когда Test Plan обычно нужен:
- релиз;
- крупная фича;
- интеграционное изменение;
- сложный regression;
- risky change (высокий бизнес-риск).
Когда чаще достаточно checklist:
- маленький bugfix;
- очень небольшая UI-правка;
- локальная быстрая проверка;
- микрозадача без интеграционных рисков.
✅ Вывод:
Выбирай формат документации по риску и масштабу задачи, а не по шаблону "план всегда обязателен".
3. План на фичу vs план на релиз
Junior часто смешивает эти уровни.
Это нормальная ошибка, но ее нужно исправить рано.
Назначение:
Разделить два типа планирования: узкий (фича) и широкий (релиз).
Простыми словами:
План на фичу отвечает за одну конкретную область.
План на релиз покрывает общий выпуск и зависимости между несколькими зонами.
Сравнение:
| Уровень | Что покрывает | Обычно включает |
|---|---|---|
| План на фичу | Одну фичу или задачу | Функциональные проверки, ключевые негативы, локальные риски |
| План на релиз | Весь релизный пакет | Интеграции, cross-area риски, общий regression, финальную QA-рекомендацию |
🔎 Как это происходит на практике:
- На уровне фичи QA ведет короткий рабочий план.
- Перед релизом QA/lead собирает релизный план с зависимостями.
- Решение о выпуске принимается по релизному уровню.
✅ Вывод:
Фичевой план и релизный план решают разные задачи. Не смешивай их в один документ.
4. Entry и Exit criteria — ядро контроля
Это самый практичный блок в Test Plan.
Он убирает фразы "давайте уже стартуем" и "вроде можно закрывать".
Назначение:
Сделать старт и завершение тестирования измеримыми.
Простыми словами:
Entry = когда можно начинать.
Exit = когда можно заканчивать.
Для новичка:
Критерии должны быть проверяемыми, а не абстрактными.
Пример:
Entry:- build установлен на staging- критичные фиксы вмержены- тестовые данные подготовлены Exit:- выполнены P1/P2 проверки- blocker = 0- critical = 0- QA summary опубликован✅ Вывод:
Entry/Exit criteria переводят обсуждение готовности релиза из эмоций в факты.
5. Риски в Test Plan: простая модель для junior
Чтобы не писать "риск ради риска", используй простую схему из 3 вопросов:
- Насколько вероятно, что это сломается?
- Насколько больно будет, если сломается?
- Сможем ли мы быстро заметить проблему до прода?
Назначение:
Оценивать риск практично, без перегруженной теории.
Простыми словами:
Risk = вероятность + impact + detectability.
Для новичка:
Если риск высокий, сразу добавляй действие: что делаем заранее и кто владелец.
Пример:
Risk: нестабильный внешний auth APIВероятность: средняяВлияние: высокоеМожно ли быстро заметить до прода: да (через smoke + алерты)Что делаем: retry + fallback smoke-сценарий + мониторингОтветственный: QA Lead + Backend Lead✅ Вывод:
Полезный риск-блок всегда содержит не только проблему, но и конкретное действие.
6. Test Plan — живой документ
Одна из самых частых процессных ошибок:
план написали один раз и больше не открывали.
Правило:
Test Plan обновляют, если меняются:
- требования;
- scope;
- окружение;
- риски;
- состав релиза.
Назначение:
Поддерживать документ актуальным в течение всей работы, а не только в день старта.
Простыми словами:
План "живет" вместе с задачей.
🔎 Как это происходит на практике:
- После каждого заметного изменения QA обновляет соответствующий блок.
- Команда видит текущую версию, а не устаревший документ.
- Перед завершением проверяется, что финальный план совпадает с фактическим прогоном.
✅ Вывод:
Устаревший Test Plan почти так же вреден, как и полное отсутствие плана.
7. Test Plan vs Test Cases vs Checklist
Эти артефакты работают вместе, но не заменяют друг друга.
Назначение:
Развести роли документов, чтобы не смешивать стратегию и детали шагов.
Простыми словами:
Plan = рамка и стратегия.
Cases = подробные проверки.
Checklist = быстрый контроль ключевых пунктов.
Сравнение:
| Документ | Для чего нужен | Глубина |
|---|---|---|
| Test Plan | Организовать тестирование релиза/фичи | Высокий уровень |
| Test Cases | Выполнить детальные шаги проверки | Детальный уровень |
| Checklist | Быстро проверить критичные зоны | Краткий уровень |
✅ Вывод:
Test Plan задает направление, test cases и checklist реализуют это направление в работе.
📌 Must-know факты
- Для junior лучше короткий и рабочий Test Plan, чем длинный и формальный.
- План нужен не всегда: формат выбирают по риску и масштабу задачи.
- Entry/Exit criteria должны быть измеримыми.
- Риски без действий не помогают релизу.
- План на фичу и план на релиз — это разные уровни.
- Test Plan всегда поддерживается в актуальном состоянии.
❗ Частые мифы
❌ Миф: Test Plan нужен только "большим проектам", в обычной задаче он лишний.
✅ Как правильно: Формат плана подбирают по риску; иногда достаточно мини-плана или checklist.
📎 Почему это важно: Так команда не перегружается лишней документацией и не теряет контроль на сложных изменениях.
❌ Миф: Если есть test cases, отдельный Test Plan не нужен.
✅ Как правильно: Test cases описывают шаги, а Test Plan описывает рамки и стратегию всего прогона.
📎 Почему это важно: Без общего плана сложно синхронизировать команду и релизные ожидания.
❌ Миф: План пишут один раз в начале и больше не трогают.
✅ Как правильно: План обновляют при изменении scope, требований, окружения и рисков.
📎 Почему это важно: Иначе команда опирается на устаревшую картину и принимает неверные решения.
💬 Часто спрашивают на собеседованиях
❓ Вопрос: Что такое Test Plan простыми словами?
✅ Ответ: Это документ, который описывает, как команда будет тестировать конкретную задачу или релиз: что проверяем, где, чем, по каким критериям завершаем.
❓ Вопрос: Чем Test Plan отличается от test case?
✅ Ответ: Test Plan задает рамки и стратегию тестирования, а test case описывает детальные шаги и ожидаемый результат конкретной проверки.
❓ Вопрос: Когда можно не делать полноценный Test Plan?
✅ Ответ: Когда задача очень маленькая и низкорисковая; в таком случае часто хватает checklist или короткого мини-плана.
❓ Вопрос: Что самое важное в Test Plan?
✅ Ответ: Ясный scope, измеримые entry/exit criteria, реальные риски с действиями и понятный формат итогового QA summary.
❓ Вопрос: Почему Test Plan называют "живым документом"?
✅ Ответ: Потому что его обновляют при изменениях, чтобы он отражал текущую реальность, а не старую версию задачи.
🚨 Типичные ошибки
Ошибка 1: Слишком сложный язык для команды
Было:
Документ перегружен терминами, которые не превращаются в действия.
Стало:
Каждый пункт формулируется через конкретный рабочий шаг.
Объяснение:
Если формулировку нельзя применить в ежедневной работе, она не помогает тестированию.
Ошибка 2: Нет явного Out of scope
Было:
Команда не понимает границы проверки и спорит, что "еще нужно протестировать".
Стало:
Out of scope вынесен в отдельный блок и согласован заранее.
Объяснение:
Это защищает от расползания задач и срыва сроков.
Ошибка 3: Entry/Exit criteria формальные
Было:
"Тестирование завершено успешно".
Стало:
"Blocker = 0, Critical = 0, выполнены P1/P2 проверки, QA summary отправлен".
Объяснение:
Измеримые критерии убирают субъективность.
Ошибка 4: Риск описали, действия не добавили
Было:
"Есть риск по интеграции".
Стало:
"Риск по интеграции X: retry-сценарий, fallback-проверка, владелец Y".
Объяснение:
Риск без плана действий не снижает вероятность инцидента.
Ошибка 5: План не обновляют
Было:
Scope изменился, а план остался старым.
Стало:
После каждого изменения требований QA обновляет релевантные блоки.
Объяснение:
Актуальность плана напрямую влияет на качество релизного решения.
✅ Best Practices
- Пиши Test Plan под конкретную цель, а не "про все на свете".
- Используй mini Test Plan как базовый шаблон для старта.
- Для feature-level и release-level делай отдельные уровни планирования.
- Критерии старта/выхода формулируй в проверяемом виде.
- На каждый высокий риск добавляй конкретное действие и ответственного.
- Обновляй план при каждом существенном изменении scope или требований.
- Держи язык документа простым и привязанным к действиям команды.
🏁 Заключение
Test Plan (обзор) для junior — это не бюрократия, а рабочий инструмент.
Он помогает заранее договориться о рамках тестирования, снизить риск пропусков и сделать релизное решение прозрачным.
Если держать план коротким, понятным и актуальным, он реально ускоряет работу QA и всей команды.