Урок 11. Тест-план: как организовать тестирование

Что такое тест-план

Тест-план — это договорённость команды: что тестируем, как, когда и кто за это отвечает на конкретном проекте.

Отвечает на вопросы:

• Что входит в область тестирования (scope)?
• Какие подходы и типы тестирования применяем?
• Кто тестирует, когда и в каком окружении?
• Когда считаем тестирование начатым и завершённым?

---

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

	Тест-стратегия	Тест-план
Уровень	Компания / продукт	Проект / спринт / фича
Горизонт	На год, на продукт	На конкретную задачу
Что описывает	Подходы, инструменты, приоритеты в целом	Что, кем и когда проверяется
Пример	«Мы используем автотесты для регрессии»	«Для фичи корзины: smoke + регресс до пятницы, ответственный — Иван»

Запомни: тест-стратегия — уровень компании, тест-план — уровень проекта.

---

8 разделов тест-плана

1. Scope — что тестируем. Обязательно включает out of scope — что явно не тестируем.
2. Подходы и типы тестирования — функциональное, регрессия, smoke, exploratory, нагрузочное и т.д.
3. Ресурсы — кто участвует: QA-инженеры, разработчики для поддержки, DevOps.
4. Расписание — когда стартует тестирование, дедлайны, точки синхронизации.
5. Окружение — тестовый стенд, конфигурации, устройства, браузеры.
6. Критерии входа — когда можно начинать тестирование.
7. Критерии выхода — когда тестирование считается завершённым.
8. Риски — что может пойти не так и что делаем в этом случае.

---

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

Entry criteria — когда можно начинать

• Сборка передана тестировщику и проходит smoke
• Требования утверждены и доступны команде
• Тестовое окружение поднято и стабильно
• Тестовые данные подготовлены

Exit criteria — когда тестирование завершено

• Все критические и высокоприоритетные баги закрыты
• Покрытие основных сценариев достигнуто (указываем конкретный % или перечень)
• Команда подтвердила готовность к релизу
• Отчёт о тестировании подготовлен

---

Риски в тест-плане

Риск = «что может пойти не так» + «что мы с этим делаем» (митигация).

Типичные риски:

• Нестабильное тестовое окружение → митигация: резервный стенд, уведомление за 48ч
• Нет доступа к тестовым данным → митигация: заранее договориться с командой данных
• Поздняя передача сборки → митигация: smoke-тест сразу при получении сборки
• Узкое место — один QA знает весь контекст → митигация: тест-план как база знаний

Формат: Риск: [описание] → Митигация: [что делаем]

---

Shift Left: тест-план появляется до кода

Традиционно QA получает задачу уже разработанной. Shift Left — QA включается раньше:

1. Идея одобрена → QA создаёт тест-план в шаблоне
2. На каждой встрече по проекту заполняется один-два вопроса шаблона
3. К началу разработки документ уже частично готов
4. Риски подсвечиваются до написания кода — дёшево исправить

---

Практика «Три кота» (3 Amigos)

3 Amigos — 30-минутная встреча: разработчик + PM + QA для проработки требований перед спринтом.

Механика:

• QA задаёт вопросы по шаблону тест-плана
• Ответы сразу фиксируются в документе
• Без выделения отдельного времени на документацию — она пишется в процессе встреч

Результат: к старту разработки тест-план готов на 70-80% без дополнительных усилий.

---

Шаблон с вкладками (реальный кейс Яндекс.Лавки)

Эволюция: Telegram-заметки → Word → Wiki → шаблон с вкладками в Confluence.

Вкладка	Содержимое
1. Инфо	Название проекта, даты, участники, ссылки
2. Конфигурация	Платформы, окружения, устройства
3. Три кота	Сценарии с acceptance criteria и их доказательства
4. Тест-кейсы	Happy path / критичные / минорные, маркер автоматизации
5. Аналитика	Баги (iframe из трекера), метрики, опциональные блоки

---

Оценка трудозатрат QA

Как аргументировать сроки на планировании:

1. Разбей на зоны — хедер, основной флоу, крайние сценарии — каждая зона уже оценка
2. Вилка оптимист/пессимист + буфер 20% на неизвестность
3. По аналогии — «как похожая задача» — быстрый способ без долгих расчётов

---

База знаний и бас-фактор

Бас-фактор — сколько человек должно попасть под автобус, чтобы проект встал. Если 1 — проблема.

Тест-план как решение:

• Каждый закрытый план — история проекта, доступная через год
• Новый QA восстанавливает контекст за 10 минут вместо нескольких дней
• Версионирование: новая функциональность → новый план + ссылка на предыдущий

---

Ключевые выводы урока

1. Тест-план — не бюрократия, а инструмент синхронизации команды
2. Структура минимум: scope, подходы, ресурсы, расписание, критерии входа/выхода, риски
3. Shift Left: тест-план создаётся до кода, а не после, и заполняется постепенно на встречах
4. Тест-план vs тест-стратегия: разные уровни — не путать на собеседовании
5. Out of scope так же важен, как scope — явно зафиксировать, что не тестируем

---

Домашнее задание

Составить мини-тест-план для «Пиццаеда» — учебного магазина доставки пиццы.

Обязательные разделы:

• Scope (и out of scope)
• 2–3 типа тестирования
• Критерии входа и выхода
• 2 риска с митигацией

Шаблон: t.me/qabigtech/33
Сдавать: чат марафона