Построение тестовой стратегии
Updated Jul 2026
От «Мы тестируем всё» к «Мы тестируем правильные вещи»
Тестовая стратегия отвечает на вопрос: при ограниченном времени, ограниченных людях и ограниченных окружениях, что мы должны тестировать, как мы должны это тестировать и как мы узнаем, что протестировали достаточно? Без стратегии тестирование реактивно — вы тестируете то, что попадёт на ваш стол. Со стратегией тестирование осознанно — вы вкладываете усилия туда, где они снижают наибольший риск.
Самая распространённая ошибка в QA — путать тест-план с тестовой стратегией. Это разные документы с разными целями.
Тестовая стратегия vs тест-план
| Измерение | Тестовая стратегия | Тест-план |
|---|---|---|
| Охват | Весь продукт или программа | Один релиз, функция или спринт |
| Временной горизонт | Долгосрочный (6-12+ месяцев) | Краткосрочный (от 1 спринта до 1 релиза) |
| Автор | QA-лид / QA-архитектор | QA-инженер на функциональности |
| Аудитория | Руководство инженерии, заинтересованные стороны | Команда разработки, QA-команда |
| Содержание | Подход, инструменты, допустимый уровень риска, принципы | Конкретные тест-кейсы, расписание, назначения |
| Частота изменений | Ежеквартально или при крупных изменениях продукта | Каждый спринт или релиз |
| На какой вопрос отвечает | «Как мы подходим к качеству этого продукта?» | «Что мы тестируем в этом спринте и когда?» |
Аналогия: Тестовая стратегия — это план военной кампании (где воевать, какие ресурсы задействовать, каковы цели). Тест-план — это план боя (конкретные передвижения войск, тайминг, анализ местности для одного сражения).
Компоненты документа тестовой стратегии
1. Область применения и цели
Определите, что охватывает стратегия и как выглядит успех.
SCOPE:
Product: ShopFlow e-commerce platform (web + mobile + API)
Includes: All customer-facing features, partner integrations, admin tools
Excludes: Third-party payment processor internals (tested via contract tests)
OBJECTIVES:
- Prevent critical defects from reaching production
- Maintain release cadence of weekly deployments
- Achieve > 90% automated regression coverage for core user journeys
- Detect performance regressions before they affect customers
2. Уровни и подход к тестированию
Определите, какие типы тестирования вы будете проводить и баланс между ними.
| Уровень тестирования | Область | Ответственный | Целевой показатель автоматизации |
|---|---|---|---|
| Модульные тесты | Отдельные функции и методы | Разработчики | > 80% покрытие строк |
| Интеграционные тесты | Взаимодействие сервисов, запросы к БД | Разработчики + QA | Все API-контракты |
| Сквозные тесты | Критические пользовательские пути через весь стек | QA | Топ-20 пользовательских путей |
| Исследовательское тестирование | Граничные случаи, юзабилити, неожиданное поведение | QA | Ручное (по определению) |
| Тестирование производительности | Нагрузка, стресс, выносливость | QA + DevOps | Автоматизировано в CI для ключевых эндпоинтов |
| Тестирование безопасности | OWASP Top 10, аутентификация, авторизация | QA + Безопасность | SAST в CI, DAST ежеквартально |
| Тестирование доступности | Соответствие WCAG 2.1 AA | QA + Дизайн | Автоматическое сканирование в CI, ручной аудит ежеквартально |
3. Тестовые окружения
| Окружение | Назначение | Данные | Частота обновления |
|---|---|---|---|
| Локальное | Тестирование разработчиком, модульные тесты | Моки/сиды | Каждая сессия разработчика |
| CI | Автоматическое выполнение тестов | Синтетические, сброс при каждом запуске | Каждый запуск пайплайна |
| Staging | Интеграционное тестирование, верификация QA | Анонимизированное подмножество продакшена | Еженедельно |
| Pre-production | Финальная валидация, тестирование производительности | Зеркало продакшена | Перед каждым релизом |
| Продакшен | Smoke-тесты, мониторинг | Реальные данные (тесты только на чтение) | После каждого деплоя |
4. Инструменты
| Категория | Инструмент | Назначение |
|---|---|---|
| Автоматизация тестов | Playwright | Браузерная автоматизация для E2E-тестов |
| API-тестирование | REST Assured / Supertest | Функциональные и контрактные API-тесты |
| Производительность | k6 | Нагрузочное тестирование и бенчмарки производительности |
| Управление тестами | TestRail | Управление тест-кейсами и отчётность |
| CI/CD | GitHub Actions | Оркестрация пайплайна |
| Мониторинг | Datadog | Мониторинг здоровья продакшена и алерты |
| Баг-трекер | JIRA | Управление жизненным циклом дефектов |
5. Оценка рисков
Определите области наивысшего риска и распределите усилия на тестирование соответственно.
| Область функциональности | Бизнес-влияние | Частота изменений | Сложность | Уровень риска | Инвестиции в тестирование |
|---|---|---|---|---|---|
| Оформление заказа / Оплата | Критический | Средняя | Высокая | ВЫСОКИЙ | Автоматизированные E2E + ручное тестирование граничных случаев |
| Аутентификация пользователей | Критический | Низкая | Средняя | ВЫСОКИЙ | Автоматизированные E2E + тестирование безопасности |
| Поиск продуктов | Высокий | Высокая | Средняя | ВЫСОКИЙ | Автоматизированные E2E + тестирование производительности |
| Панель администратора | Средний | Средняя | Низкая | СРЕДНИЙ | Автоматизированные smoke-тесты + ручное |
| Маркетинговые страницы | Низкий | Высокая | Низкая | НИЗКИЙ | Автоматизированная визуальная регрессия + доступность |
6. Критерии входа и выхода
Критерии входа (тестирование может начаться, когда):
- Код развёрнут в тестовом окружении
- Тестовые данные доступны и проверены
- Зависимости (внешние сервисы, API) доступны
- Проверка здоровья тестового окружения пройдена
Критерии выхода (тестирование завершено, когда):
- Все критические и высокоприоритетные тест-кейсы выполнены
- Ноль открытых критических багов, менее 3 открытых крупных багов
- Автоматический регрессионный набор проходит с уровнем нестабильности менее 2%
- Бенчмарки производительности соответствуют определённым порогам
- Согласование product owner по критериям приёмки
Тестовая стратегия на основе рисков
Принцип
Вы не можете протестировать всё. Тестирование на основе рисков распределяет усилия на области, где баги причинят наибольший ущерб.
Расчёт рисков
Risk = Likelihood of Failure x Impact of Failure
Likelihood factors:
- Complexity of the code
- Frequency of changes
- Developer experience with the area
- Number of integration points
- History of bugs in this area
Impact factors:
- Number of users affected
- Revenue impact
- Regulatory / compliance implications
- Reputation damage
- Data loss potential
Применение рисков к распределению тестирования
| Уровень риска | Подход к тестированию | Пример |
|---|---|---|
| Критический | Полное автоматизированное покрытие + исследовательское + производительность + безопасность | Обработка платежей |
| Высокий | Автоматизированные E2E для основных путей + ручное для граничных случаев | Регистрация пользователей, поиск |
| Средний | Автоматизированные smoke-тесты + ручное для новых изменений | Инструменты администрирования, отчётность |
| Низкий | Автоматизированная визуальная регрессия + точечные проверки | Страницы со статическим контентом |
Тестовая стратегия для разных типов продуктов
SaaS веб-приложение
- Акцент на кросс-браузерном и адаптивном тестировании
- Тестирование feature flag (разные сегменты пользователей видят разные функции)
- Мультитенантное тестирование (изоляция данных между клиентами)
- Непрерывное развёртывание означает, что каждый коммит должен быть тестируемым
- Интеграция A/B-тестирования
Мобильное приложение
- Тестирование фрагментации устройств и версий ОС
- Тестирование сетевых условий (офлайн, медленный 3G, Wi-Fi)
- Соответствие требованиям магазинов приложений (рекомендации часто меняются)
- Тестирование push-уведомлений на разных платформах
- Тестирование влияния на батарею и производительность
- Тестирование установки, обновления и миграции
API-платформа
- Контрактное тестирование со всеми потребителями
- Тестирование ограничения частоты запросов и троттлинга
- Тестирование обратной совместимости для версионированных API
- Проверка точности документации
- Тестирование SDK на всех поддерживаемых языках
- Аутентификация и авторизация для каждого эндпоинта
Встраиваемые системы
- Тестирование hardware-in-the-loop
- Ограничения производительности реального времени
- Тестирование обновления и отката прошивки
- Тестирование в различных условиях среды (температура, перепады напряжения)
- Длительное тестирование стабильности (дни/недели)
- Требования сертификации для критически важных систем безопасности
Шаблон документа тестовой стратегии
TEST STRATEGY: [Product Name]
Version: [X.Y]
Author: [Name]
Last Updated: [Date]
Approved By: [Name, Role]
1. INTRODUCTION
1.1 Purpose of this document
1.2 Product overview
1.3 Scope (in-scope and out-of-scope)
2. TEST APPROACH
2.1 Test levels (unit, integration, E2E, etc.)
2.2 Test types (functional, performance, security, accessibility)
2.3 Automation strategy (what to automate, tools, targets)
2.4 Manual testing approach (exploratory, session-based)
3. RISK ASSESSMENT
3.1 Feature risk matrix
3.2 Test allocation by risk level
3.3 Risk review cadence
4. ENVIRONMENTS AND DATA
4.1 Environment inventory
4.2 Test data strategy
4.3 Environment maintenance responsibilities
5. TOOLS AND INFRASTRUCTURE
5.1 Tool inventory
5.2 CI/CD integration
5.3 Monitoring and alerting
6. PROCESSES
6.1 Bug triage and severity definitions
6.2 Release criteria (entry/exit)
6.3 Escalation paths
6.4 Reporting cadence and audience
7. TEAM AND RESPONSIBILITIES
7.1 QA team structure
7.2 Developer testing responsibilities
7.3 Specialist testing (security, performance, accessibility)
8. CONTINUOUS IMPROVEMENT
8.1 Metrics to track
8.2 Review and update cadence
8.3 Feedback mechanisms
Получение поддержки заинтересованных сторон
Тестовая стратегия бесполезна, если никто её не соблюдает. Получение поддержки требует демонстрации релевантности стратегии для задач каждой заинтересованной стороны.
| Заинтересованная сторона | Её забота | Как получить поддержку |
|---|---|---|
| VP по разработке | Скорость релизов, продуктивность команды | «Эта стратегия сократит наш цикл регрессии с 3 дней до 4 часов» |
| Продуктовый менеджер | Скорость доставки функций, удовлетворённость клиентов | «Приоритизация по рискам означает, что мы тестируем поток оформления заказа исчерпывающе, но тратим меньше времени на страницы администрирования» |
| Лид разработки | Продуктивность разработчиков, качество кода | «Разработчики владеют модульными тестами, QA — E2E: чёткое разделение ответственности, без дублирования» |
| CTO | Технический долг, надёжность платформы | «Эта стратегия включает ежеквартальные оценки безопасности и производительности» |
| CFO | Стоимость | «Инвестиции в автоматизацию в размере $X окупаются через Y релизов за счёт сокращения ручного тестирования» |
Процесс получения поддержки
- Составьте черновик стратегии на основе оценки рисков и анализа продукта
- Обсудите индивидуально — встретьтесь с каждой заинтересованной стороной лично и учтите их обратную связь
- Представьте финальную версию всей команде, показав, как их вклад её сформировал
- Получите явное одобрение от руководителя инженерии, который распоряжается бюджетом на качество
- Пересматривайте ежеквартально и отчитывайтесь о том, работает ли стратегия, используя метрики, определённые в разделе 8
Практическое упражнение
- Напишите одностраничное резюме тестовой стратегии для вашего текущего проекта, используя шаблон выше (только разделы 1-3)
- Создайте матрицу рисков для 10 основных функций вашего продукта и распределите усилия на тестирование соответственно
- Сравните вашу текущую тестовую стратегию (даже если неформальную) со списком компонентов. Чего не хватает?
- Определите 3 ключевых заинтересованных стороны, от которых вам нужна поддержка, и подготовьте одно предложение-питч для каждой
- Определите критерии входа и выхода для вашего следующего релиза