Что такое тест-стратегия?
Тест-стратегия — это документ высокого уровня, определяющий общий подход к тестированию проекта или организации. Она отвечает на фундаментальные вопросы: Что мы будем тестировать? Как будем тестировать? Какие инструменты и окружения нам нужны? Каковы наши критерии качества?
В отличие от тест-плана, который специфичен для конкретного релиза или спринта, тест-стратегия задаёт общий фреймворк, направляющий всю деятельность по тестированию. Думайте о ней как о конституции вашего QA-процесса — она устанавливает принципы, а тест-планы работают с деталями.
Зачем нужна тест-стратегия
Команды, пропускающие тест-стратегию, сталкиваются с проблемами:
- Непоследовательное тестирование — разные тестировщики используют разные подходы для похожих фич
- Пробелы в покрытии — критические области остаются без тестов, потому что никто не определил, что значит «полностью»
- Хаос инструментов — команды внедряют случайные инструменты без оценки альтернатив
- Неясные quality gates — нет согласия, что значит «достаточно хорошо» для релиза
- Впустую потраченные усилия — тестировщики дублируют работу или чрезмерно тестируют области с низким риском
Тест-стратегия устраняет неоднозначность. Когда новый участник присоединяется к команде, он читает стратегию и сразу понимает, как ваша команда подходит к качеству.
Ключевые разделы тест-стратегии
1. Область и цели
Определите, что входит в область тестирования и что явно исключено. Чётко сформулируйте цели качества.
Пример — входит в область:
- Все функции веб-приложения, доступные пользователям
- API-эндпоинты, используемые мобильным приложением
- Интеграция со сторонним платёжным провайдером
- Производительность при ожидаемой пиковой нагрузке (10,000 одновременных пользователей)
Пример — не входит в область:
- Внутренний код сторонних библиотек
- Устаревшая админ-панель (запланирована к замене в Q3)
- Тестирование на уровне аппаратного обеспечения
2. Уровни и типы тестирования
Укажите, какие уровни (модульное, интеграционное, системное, приёмочное) и типы (функциональное, производительности, безопасности, юзабилити) применимы к проекту.
| Уровень | Ответственный | Цель покрытия | Инструменты |
|---|---|---|---|
| Модульное | Разработчики | 80% покрытия строк | Jest, pytest |
| Интеграционное | Dev + QA | Все контракты API | Postman, Pact |
| Системное | QA | Все user stories | Playwright |
| Приёмочное | QA + PO | Все критерии приёмки | Ручное + Playwright |
3. Подход к тестированию
Опишите методологию: будете ли использовать тестирование на основе рисков? Будете ли сочетать исследовательское тестирование со скриптовыми тестами?
Пример подхода на основе рисков:
- Критический риск: Платёжный поток, аутентификация — 100% покрытие, автоматизированная регрессия, сканирование безопасности на каждом билде
- Высокий риск: Поиск, профиль пользователя, уведомления — 80% покрытие, автоматизированные happy path
- Средний риск: Настройки, страницы помощи — Ручное исследовательское тестирование каждый спринт
- Низкий риск: Статический контент, страница «О нас» — Только smoke-тест
4. Окружение и данные для тестирования
Определите необходимые окружения и стратегию тестовых данных.
| Окружение | Назначение | Данные | Обновление |
|---|---|---|---|
| DEV | Тестирование разработчиками | Синтетические | По запросу |
| QA | Полная регрессия | Обезличенная копия production | Еженедельно |
| Staging | Предрелизная валидация | Зеркало production | По релизу |
| Performance | Нагрузочное тестирование | Масштабированные данные production | Ежемесячно |
5. Инструменты и инфраструктура
Перечислите инструменты для каждого вида тестирования с обоснованием выбора.
6. Управление дефектами
Определите, как баги репортятся, классифицируются (severity/priority), сортируются и отслеживаются. Укажите SLA на исправление по серьёзности.
7. Анализ рисков
Определите риски проекта, влияющие на тестирование, и стратегии их снижения.
| Риск | Влияние | Вероятность | Снижение |
|---|---|---|---|
| Нестабильное тестовое окружение | Высокое | Средняя | Контейнеризированное окружение, автоматический provisioning |
| Поздние изменения требований | Высокое | Высокая | Agile-подход, буфер на исследовательское тестирование |
| Уход ключевого тестировщика | Среднее | Низкая | Cross-training, документированные процедуры |
8. Критерии входа и выхода
Критерии входа — условия до начала тестирования:
- Билд развёрнут в QA-окружении
- Все unit-тесты проходят
- Тестовые данные загружены
- Тестовое окружение проверено
Критерии выхода — условия для завершения тестирования:
- Все критические и высокоприоритетные тест-кейсы выполнены
- Ноль открытых критических багов, менее 3 багов высокой серьёзности
- 95% проходимость всех тест-кейсов
- Бенчмарки производительности выполнены
Тест-стратегия vs. Тест-план
| Аспект | Тест-стратегия | Тест-план |
|---|---|---|
| Область | Проект или организация | Конкретный релиз или спринт |
| Автор | QA Lead или Manager | QA Lead или Senior QA |
| Обновления | Редко (раз в квартал) | По релизу или спринту |
| Уровень детализации | Подход высокого уровня | Детальное расписание и назначения |
| Содержание | Принципы и методология | Конкретные тест-кейсы и сроки |
Упражнение: Создайте тест-стратегию
Вы — QA Lead нового SaaS-продукта для управления проектами. Продукт включает: управление задачами, командную коллаборацию (чат), обмен файлами, трекинг времени, дашборд отчётов и интеграции со Slack и GitHub.
Создайте документ тест-стратегии, покрывающий все восемь разделов, описанных выше.
Подсказка
Начните с области — какие фичи наиболее рискованные? Обработка платежей и обмен файлами связаны с конфиденциальными данными. Чат требует тестирования в реальном времени. Интеграции со Slack и GitHub имеют внешние зависимости, которые вы не можете полностью контролировать.Решение
1. Область и цели
- В области: Все основные фичи (задачи, чат, файлы, время, отчёты, интеграции)
- Вне области: Внутреннее поведение Slack/GitHub, расширения браузера
- Цель: 99.9% uptime, время отклика менее 2 сек, нулевая потеря данных
2. Уровни тестирования
- Unit: 80% покрытие (разработчики, Jest/pytest)
- Интеграционное: Все API-эндпоинты и вебхуки Slack/GitHub (Postman, Pact)
- Системное: Все user stories (Playwright)
- Приёмочное: Демо с PO каждый спринт
3. Подход
- На основе рисков: Платежи и файлы = критический, чат = высокий, отчёты = средний
- Исследовательское: 20% времени на исследовательские сессии
- Автоматизированная регрессия: Запуск на каждом merge PR
4. Окружения
- DEV (синтетические данные, по запросу), QA (обезличенные, обновление еженедельно), Staging (зеркало production, по релизу), Perf (масштабированные данные, ежемесячно)
5. Инструменты
- Playwright (E2E), k6 (производительность), Postman (API), Pact (контракты), SonarQube (статический анализ), Jira (дефект-трекинг)
6. Управление дефектами
- Серьёзность: Critical/High/Medium/Low
- SLA: Critical = 4ч, High = 24ч, Medium = спринт, Low = бэклог
- Triage: Обзор на ежедневном стендапе
7. Риски
- Недоступность стороннего API — mock-сервисы для тестирования
- Масштабирование чата в реальном времени — целевое spike-тестирование перед запуском
- Миграция данных из конкурирующих инструментов — выделенная фаза тестирования миграции
8. Вход/Выход
- Вход: Билд в QA, unit-тесты зелёные, тестовые данные готовы
- Выход: 100% критических кейсов выполнено, ноль багов P1, бенчмарки выполнены, sign-off от PO
Типичные ошибки
Ошибка 1: Написание романа. Тест-стратегия должна быть 5-15 страниц. Если превышает 20, вы включаете слишком много деталей, которые принадлежат тест-планам.
Ошибка 2: Копирование шаблонов без адаптации. У каждого проекта уникальные риски и ограничения. Общий шаблон без проектной специфики бесполезен.
Ошибка 3: Никогда не обновлять. Стратегия, написанная на старте проекта и никогда не пересматриваемая, устаревает. Пересматривайте ежеквартально или при существенных изменениях.
Ошибка 4: Нет поддержки стейкхолдеров. Стратегия, написанная QA в изоляции и не представленная лидам разработки и product owner-ам, не будет соблюдаться.
Ключевые выводы
- Тест-стратегия определяет подход к тестированию на высоком уровне для проекта или организации
- Охватывает область, уровни, подход, окружения, инструменты, управление дефектами, риски и критерии входа/выхода
- Отличается от тест-плана: стратегия — высокоуровневая и стабильная; план — конкретный и меняется по релизу
- Должна быть лаконичной (5-15 страниц), специфичной для проекта и согласованной со стейкхолдерами
- Пересматривайте и обновляйте ежеквартально или после значительных изменений проекта