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

Updated Jul 2026

Документы, которые направляют тестирование, а не пылятся

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

Документ тест-плана

Стандарт IEEE 829

IEEE 829 определяет комплексную структуру тест-плана, разработанную для водопадных проектов с длительными жизненными циклами и строгими требованиями к документации.

Компоненты тест-плана IEEE 829:

Когда использовать IEEE 829: Регулируемые отрасли (медицинские устройства, аэрокосмос, финансы), государственные контракты, крупные корпоративные проекты с формальным управлением и любой проект, где аудитор может спросить «где ваш тест-план?»

Облегчённые agile тест-планы

Большинству современных команд разработки не нужен формальный документ из 20 разделов. Им нужен лаконичный план, отвечающий на пять вопросов:

1. Что мы тестируем? (Область)
2. Что мы не тестируем? (Вне области и почему)
3. Как мы тестируем? (Подход, инструменты, техники)
4. Что может пойти не так? (Риски)
5. Как мы узнаем, что закончили? (Критерии выхода)

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

Эти термины часто путают. Они служат разным целям и работают на разных уровнях.

Когда нужны оба: Крупные организации с несколькими командами нуждаются в стратегии (общее направление) и отдельных тест-планах (выполнение на уровне команды). Небольшие команды часто могут объединить их в один облегчённый документ.

Когда достаточно только плана: Одна команда, работающая над одним продуктом короткими спринтами. Стратегия неявно заложена в том, как вы работаете.

Написание тест-планов, которые люди действительно читают

Почему тест-планы остаются непрочитанными

Одностраничный тест-план

Для большинства тестирования на уровне спринта одностраничного плана достаточно, и он гораздо более вероятно будет прочитан.

Шаблон:

# Test Plan: [Feature Name] -- Sprint [N]

## Scope
What is being tested. What user stories are covered.

## Out of Scope
What is explicitly not being tested and why.

## Approach
- Manual testing: [what and why]
- Automated testing: [what and why]
- Exploratory testing: [focus areas]

## Test Environments
| Environment | URL | Purpose |
|---|---|---|
| Staging | staging.example.com | Integration and regression |
| QA | qa.example.com | Feature testing |

## Test Data
What test data is needed and how to obtain it.

## Risks
| Risk | Impact | Mitigation |
|---|---|---|
| Payment API sandbox may be unavailable | Cannot test checkout | Use mock service |
| New design system may break existing flows | Visual regressions | Run visual regression suite |

## Entry Criteria
- [ ] Feature code deployed to staging
- [ ] Test data loaded
- [ ] Test environments accessible

## Exit Criteria
- [ ] All critical test cases passed
- [ ] No open Sev-1 or Sev-2 bugs
- [ ] Automation suite green
- [ ] Exploratory testing completed

## Schedule
| Activity | Start | End | Owner |
|---|---|---|---|
| Test case design | Mon | Tue | QA team |
| Manual execution | Wed | Thu | QA team |
| Automation updates | Wed | Fri | SDET |
| Exploratory testing | Thu | Fri | Senior QA |

Шаблоны для различных контекстов

Тест-план спринта (1 страница)

Используется для каждого спринта. Фокус на том, что нового и что рискованно.

• Область: новые функции и исправления багов в этом спринте
• Подход: какие тесты запускать, что автоматизировать
• Риски: что может заблокировать тестирование
• Критерии выхода: определение «тестирование завершено»

Тест-план релиза (2-3 страницы)

Используется для крупных релизов, охватывающих несколько спринтов. Включает стратегию регрессии и риски, специфичные для релиза.

• Всё из тест-плана спринта, плюс:
• Область регрессии: какую существующую функциональность перепроверить
• Тестирование производительности: подход к нагрузочному тестированию для релиза
• Совместимость: покрытие браузеров/устройств/ОС
• Верификация развёртывания: smoke-тесты для продакшена
• Критерии отката: когда откатывать

Тест-план проекта (5-10 страниц)

Используется для крупных, многомесячных проектов. Включает комплексный анализ рисков и планирование ресурсов.

• Всё из тест-плана релиза, плюс:
• План ресурсов: кто что делает, пробелы в навыках, обучение
• Расписание с вехами и зависимостями
• Настройка инструментов и инфраструктуры
• Подход к интеграционному тестированию для многокомандных проектов
• Координация приёмочного тестирования со стейкхолдерами

Получение подписания и управление изменениями

Получение подписания

Цель подписания — не бюрократия, а согласование. Когда продакт-менеджер, техлид и QA-лид подписывают тест-план, они соглашаются с тем, что означает «протестировано» для этого релиза.

Кто подписывает:

• QA Lead: владеет планом
• Tech Lead / Engineering Manager: подтверждает реализуемость и полноту
• Product Manager: подтверждает соответствие области и приоритетов бизнес-потребностям

Как получить подписание без потери времени:

1. Поделитесь черновиком заранее (не готовый документ)
2. Обсудите его на короткой встрече (15-30 минут), а не просите людей проверить асинхронно
3. Сфокусируйте обсуждение на области, рисках и критериях выхода — решениях, которые имеют значение
4. Задокументируйте согласия и несогласия. Если PM хочет пропустить регрессию модуля X, зафиксируйте это явно.

Управление изменениями

Тест-планы меняются. Требования меняются, сроки сдвигаются, баги раскрывают новые риски. План должен быть живым документом.

Процесс управления изменениями:

1. Когда происходит значительное изменение (добавлена область, материализовался риск, сжаты сроки), обновите план
2. Чётко выделите изменение (жирный текст, заметки о ревизии или раздел журнала изменений)
3. Уведомите стейкхолдеров об изменении и его влиянии на тестирование
4. Если изменение влияет на критерии выхода или область, получите повторное подтверждение

Живые тест-планы: поддержание документации в актуальном состоянии

Тест-план, который точен в первый день и устарел к десятому, не имеет ценности. Вот стратегии для поддержания планов в актуальном состоянии.

Размещение рядом с работой

Храните тест-план там, где работает команда. Если команда использует Jira, привяжите план к эпику или спринту. Если команда использует GitHub, поместите его в репозиторий. Если план находится в вики, которую никто не посещает, он сгниёт.

Обновления как часть рабочего процесса

• Обновляйте план при изменении области спринта
• Обновляйте раздел рисков при материализации риска или выявлении нового
• Обновляйте критерии выхода, когда команда соглашается на изменение области
• Кратко обсуждайте план на ретроспективе спринта: «Был ли план точным? Что нам следует изменить для следующего спринта?»

Автоматизированные проверки актуальности

Для команд с множеством тест-планов используйте автоматические напоминания:

• Установите дату ревизии для каждого документа
• Используйте бот или напоминание в календаре, чтобы пингануть владельца, когда план не обновлялся 30 дней
• Архивируйте планы для завершённых проектов, чтобы они не захламляли активное рабочее пространство

Практическое упражнение

1. Возьмите самый последний тест-план вашей команды. Оцените его по таблице «почему тест-планы остаются непрочитанными». Что можно улучшить?
2. Напишите одностраничный тест-план спринта для вашего текущего спринта, используя шаблон выше.
3. Сравните текущий формат вашего тест-плана со структурой IEEE 829. Каких разделов вам не хватает, которые могли бы добавить ценность? Какие разделы IEEE 829 были бы избыточными?
4. Создайте документ тестовой стратегии для вашего продукта на ближайшие 6 месяцев. Фокус на 5 ключевых вопросах: что, что не, как, риски и критерии завершённости.
5. Установите процесс ревизии плана: кто проверяет, когда и каков механизм подписания?