Стратегия vs План: Почему Различие Важно
Одна из самых частых путаниц в QA — разница между тестовой стратегией и тест-планом. Многие команды используют термины взаимозаменяемо, но они служат разным целям.
Тестовая Стратегия
Тестовая стратегия — документ организационного уровня, определяющий общий подход к тестированию для всех проектов и команд. Она долгосрочна, многоразова и редко меняется.
Что Содержит
- Подход к тестированию: Типы тестирования организации
- Уровни тестирования: Unit, интеграционное, системное, приёмочное — какие обязательны
- Политика автоматизации: Что автоматизировать, утверждённые инструменты, цели покрытия
- Стандарты инструментов: Утверждённые инструменты управления, автоматизации, мониторинга
- Стратегия окружений: Как разворачиваются и управляются тестовые окружения
- Процесс управления дефектами: Классификация серьёзности, процесс triage, SLA
- Метрики и отчётность: Что отслеживается, как генерируются отчёты
- Роли и обязанности: Стандартные QA-роли и их scope
- Управление рисками: Как выявляются и снижаются риски тестирования
- Требования compliance: Отраслевые стандарты (HIPAA, PCI-DSS, SOX)
Стратегия по Размеру Компании
Стартап (5-20 человек): Неформальная, 1-2 страницы. Фокус: что автоматизировать первым, минимальные стандарты качества.
Средняя компания (50-200): Структурированная, 5-10 страниц. Стандартизация между командами, общие инструменты.
Предприятие (500+): Комплексная, 15-30+ страниц. Управление, compliance, координация, лицензирование.
Тест-План
Тест-план — документ для конкретного проекта, описывающий scope, подход, ресурсы и график тестирования.
Структура IEEE 829
- Идентификатор плана
- Ссылки: Связанные документы
- Введение: Назначение и scope
- Объекты тестирования: Какое ПО/функции будут тестироваться
- Программные риски
- Функции для тестирования
- Функции вне scope (и почему)
- Подход: Методы и техники
- Критерии прохождения/непрохождения
- Критерии приостановки и возобновления
- Артефакты тестирования
- Оставшиеся задачи
- Требования к окружению
- Потребности в персонале и обучении
- Обязанности
- Расписание
- Риски плана и контингенции
- Согласования
Сравнение
| Аспект | Тестовая Стратегия | Тест-План |
|---|---|---|
| Уровень | Организация | Проект |
| Длительность | Годы | Недели/месяцы |
| Автор | Руководство QA | QA-лид проекта |
| Изменения | Редко | По проекту |
| Конкретность | Общий подход | Конкретный scope, график, ресурсы |
| Согласование | Менеджмент QA | Стейкхолдеры проекта |
Как Они Работают Вместе
Организационная] --> TP1[Тест-План
Проект A] TS --> TP2[Тест-План
Проект B] TS --> TP3[Тест-План
Проект C] style TS fill:#2196F3,color:#fff style TP1 fill:#4CAF50,color:#fff style TP2 fill:#4CAF50,color:#fff style TP3 fill:#4CAF50,color:#fff
Стратегия задаёт рамки. План применяет рамки к конкретному проекту.
Когда Нужен Какой Документ
| Ситуация | Что Нужно |
|---|---|
| Формирование новой QA-команды | Сначала стратегия |
| Старт нового проекта | Тест-план (по существующей стратегии) |
| Аудит или проверка compliance | Оба |
| Внедрение нового инструмента | Обновить стратегию |
| Планирование спринта | Лёгкий план или секция тестирования |
| Мажорный релиз | Детальный тест-план |
Упражнение: Написать Схему Тестовой Стратегии
Вас наняли QA-лидом в fintech-стартап на 30 сотрудников. Компания делает мобильное приложение для платежей. Сейчас:
- 3 QA-инженера (все ручные тестировщики)
- Нет формального процесса и документации
- Разработчики пишут unit-тесты непоследовательно
- Тестирование ad-hoc перед каждым релизом
- Приложение обрабатывает финансовые транзакции (требуется PCI-DSS)
Ваша задача:
Напишите схему стратегии:
- Подход и уровни тестирования
- Политика автоматизации (что первым, инструменты, график)
- Стандарты инструментов
- Процесс управления дефектами
- Требования PCI-DSS
- Метрики
- Roadmap на 6 месяцев
Подсказка
PCI-DSS требует тестирования безопасности, контроля доступа и аудит-логирования. Начните автоматизацию с тестов максимального ROI (API, smoke). С 3 QA стратегия должна быть практичной.
Пример решения
Тестовая Стратегия для FinPay
1. Уровни тестирования:
| Уровень | Ответственный | Минимум |
|---|---|---|
| Unit-тесты | Разработчики | 70% покрытие для нового кода, обязательно для логики платежей |
| Интеграционные | Dev + QA | Contract-тесты API для всех сервисов |
| Системное | QA | Функциональное, безопасности, производительности за релиз |
| Приёмочное | QA + Продукт | UAT для мажорных фич |
2. Автоматизация:
- API-тесты платёжных потоков (Месяц 1-2)
- Smoke-тесты мобильного приложения (Месяц 2-3)
- Регрессионный набор (Месяц 3-4)
- Тесты производительности (Месяц 4-5)
Цель: 60% автоматизированного покрытия к месяцу 6.
3. Инструменты: TestRail (управление), Playwright + Appium (автоматизация), k6 (производительность), OWASP ZAP (безопасность), GitHub Actions (CI/CD), Jira (баги).
4. Управление дефектами:
- Критический: Сбои платежей, потеря данных — Исправление за 4 часа
- Высокий: Основная функция сломана — Исправление за 24 часа
- Средний: Неосновная функция — Исправление в текущем спринте
- Низкий: Косметический — При наличии ёмкости
5. PCI-DSS:
- Ежеквартальные автоматизированные сканирования безопасности
- Ежегодное тестирование на проникновение (внешний подрядчик)
- Шифрование данных платежей в транзите и хранении
- Без реальных данных карт в тестовых окружениях
6. Метрики:
- Сбежавшие дефекты: < 5 критических/квартал в продакшене
- Покрытие автоматизацией: 60% к месяцу 6
- Время регрессии: < 30 минут
- PCI-DSS compliance: 100%
7. Roadmap:
| Месяц | Фокус | Артефакты |
|---|---|---|
| 1 | Фундамент | Стратегия утверждена, TestRail настроен, процесс дефектов |
| 2 | API-автоматизация | API платежей автоматизирован, интеграция CI/CD |
| 3 | Мобильная автоматизация | Smoke-тесты iOS/Android, старт регрессии |
| 4 | Производительность | Тесты k6, baseline, первый скан PCI-DSS |
| 5 | Зрелость | Полная автоматизированная регрессия, дашборд метрик |
| 6 | Оптимизация | 60% автоматизации, первый квартальный аудит |
Профессиональные Советы
Начните со стратегии. Если в организации её нет, создайте до написания проектных планов.
Держите планы живыми документами. План, написанный в начале и никогда не обновлявшийся — к середине проекта это художественная литература.
Включите то, что вы НЕ тестируете. Раздел «вне scope» так же важен, как «в scope».
Получите buy-in стейкхолдеров по критериям. Если PM согласен, что «ноль критических багов» — критерий выхода, он не сможет давить на релиз с открытыми критическими багами.
Используйте шаблоны, но адаптируйте. IEEE 829 — хорошая отправная точка, но подстраивайте под размер команды и нужды проекта.