Тестовая стратегия: что это и как её составить

🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 15.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks 

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

Проще говоря, тестовая стратегия отвечает на вопросы: что тестировать, как тестировать и, что особенно важно, — зачем. В этой статье мы расскажем всё, что нужно знать, чтобы разработать надёжную и продуманную стратегию тестирования.

Содержание:

• Что такое тестовая стратегия?
• Преимущества тестовой стратегии
• Виды тестовых стратегий
• Что включить в тестовую стратегию?
• Пример тестовой стратегии
• План тестирования vs. Стратегия тестирования

Что такое тестовая стратегия?

Тестовая стратегия — это документ высокого уровня, в котором описываются общий подход и основные принципы тестирования программного обеспечения. Она предоставляет структурированную основу, направляющую работу команды тестирования, чтобы обеспечить эффективное и полное проведение проверок и валидацию всех ключевых аспектов продукта.

Преимущества тестовой стратегии

1. Задает понятный вектор и приоритеты для всей работы по тестированию.
2. Позволяет заранее выявить и снизить критические риски.
3. Делает процессы более четкими и слаженными, экономит время и ресурсы.
4. Способствует соблюдению отраслевых и нормативных стандартов.
5. Улучшает командную работу, объединяя участников проекта вокруг общих целей.
6. Помогает грамотно распределять ресурсы.
7. Обеспечивает прозрачный мониторинг и отчетность о ходе тестирования.
8. Обеспечивает полноценную проверку всех важных функций продукта.

Виды тестовых стратегий

Существует три ключевых типа стратегий тестирования:

1. Статическая и динамическая

• Статическое тестирование предполагает анализ кода и документации без их выполнения, позволяя выявить ошибки на ранних этапах.
• Динамическое тестирование включает запуск программного обеспечения для проверки его поведения в реальных сценариях.
  

Преимущества:

• Статическое тестирование помогает находить дефекты до того, как они станут дорогостоящими.
• Динамическое тестирование показывает, как приложение ведет себя на практике — то есть для пользователя.

2. Превентивная и реактивная

Данный подход сочетает профилактику дефектов до их появления и реагирование на проблемы, выявленные после релиза.

Преимущества:

• Превентивное тестирование позволяет заранее проработать известные риски и снизить затраты.
• Реактивное тестирование помогает оперативно решать непредвиденные проблемы, особенно в процессе интеграции или при использовании продукта в реальных условиях.

Так как не все дефекты можно предугадать заранее, комбинация обоих подходов позволяет выявлять скрытые и «плавающие» баги.

3. Гибридная стратегия

Смысл гибридного подхода — найти оптимальное соотношение между ручным и автоматизированным тестированием.

Зачем нужен этот баланс? Ручное тестирование отлично подходит для начальных этапов, особенно для проведения исследовательского тестирования и выявления багов. После этого команда решает, стоит ли автоматизировать конкретный кейс. Если да — подключаются автотесты и инструменты, чтобы потом не повторять рутину вручную.

Что включить в тестовую стратегию?

1. Уровни тестирования

Хорошая стратегия начинается с пирамиды тестирования, которая включает три уровня:

• Юнит-тесты (база) — быстрые, автоматизированные, покрывают 70–80% кода. Проверяют логику на уровне отдельных компонентов.
• Интеграционные тесты (средний уровень) — смотрят, как модули взаимодействуют между собой. Покрытие — около 15–20%.
• E2E (end-to-end) (верхушка) — симулируют поведение пользователя, тестируя всю систему. Медленные, сложные, но критично важные для проверки ключевых пользовательских сценариев. Их — не больше 5–10%.

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

2. Цели и охват тестирования

• Поставьте цели — уточните, что именно будет проверяться: функциональные требования (фичи) или нефункциональные характеристики (безопасность, производительность, удобство использования). Цели должны соответствовать требованиям проекта.
• Определите охват действия — задайте границы: что будет тестироваться, а что — нет. Это поможет избежать неконтролируемого расширения задач (scope creep).
  

Что стоит включить:

• Функциональность, подлежащую тестированию
• Исключенные фичи
• Типы тестирования
• Тестовое окружение
  

На что стоит обратить особое внимание:

• Часто используемые и критичные функции
• Основные пользовательские сценарии
• Интеграции с внешними сервисами (API, платёжные системы)
• Недавние изменения, где выше риск багов
  

3. Типы тестирования

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

• По типу тестируемого приложения (AUT — Application Under Test): тесты классифицируются в зависимости от типа тестируемого ПО — веб-приложения, мобильные, десктопные и т. д.
• По уровню архитектуры приложения: тестирование разделяется по уровням типовой трехуровневой архитектуры: пользовательский интерфейс (UI), бэкенд, API и т. д.
• По проверяемым атрибутам: тесты классифицируются в зависимости от фокусировки — визуальное тестирование, функциональное, нагрузочное и др.
• По подходу: виды тестирования по методам проведения: ручное, автоматизированное, с использованием AI-инструментов.
• По степени детализации: группировка по уровню охвата — модульное тестирование, интеграционное, end-to-end и т. п.
• По техникам тестирования: классификация на основе методологии написания и выполнения тестов: black-box, white-box, gray-box и др.
  

4. Подход к тестированию

Сегодня большинство QA-команд используют Agile-подход. В рамках этой методологии тестирование не выносится в отдельную фазу, а становится неотъемлемой частью всего цикла разработки. Такой подход позволяет проводить проверки постоянно, быстро выявлять баги и тесно работать с разработчиками, что ускоряет релизы и улучшает качество продукта.

Agile-подход поддерживает стратегию сдвига влево (shift-left testing), при которой тестирование переносится на более ранние этапы разработки и тесно интегрируется с процессом разработки.

5. Критерии тестирования

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

Критерии входа (условия, необходимые для начала тестирования):

• Код завершён, допускаются только исправления ошибок
• Пройдены модульные и интеграционные тесты
• Основные функции (вход в систему, навигация и т.д.) работают
• Настроено тестовое окружение
• Все обнаруженные баги задокументированы
• Подготовлены тестовые данные
  

Критерии выхода (условия, необходимые для завершения тестирования):

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

6. Аппаратно-программная конфигурация

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

• Аппаратная часть: серверы, рабочие станции, мобильные устройства, специализированное оборудование (роутеры, коммутаторы, фаерволы и т. д.).
• Программная часть: операционные системы, браузеры, базы данных, API, инструменты тестирования, сторонние сервисы и зависимые программные компоненты.

Для проведения нагрузочного и производительного тестирования требуется также настроить сетевую инфраструктуру, чтобы эмулировать реальные условия: пропускную способность сети, задержки, настройки прокси, фаерволы, VPN и сетевые протоколы.

Пример такой конфигурации ниже:

Категория	Мобильное тестирование	Веб-тестирование
Аппаратное обеспечение	– iPhone 13 Pro (iOS 15) – iPad Air (iOS 14) – Google Pixel 6 (Android 12) – Samsung Galaxy S21 (Android 11)	– Windows 10: Intel Core i7, 16 ГБ ОЗУ, 256 ГБ SSD – macOS Monterey: чип Apple M1, 16 ГБ ОЗУ, 512 ГБ SSD
Программное обеспечение	–  Google Chrome (все версии) – Mozilla Firefox (все версии) – Safari (все версии) – Edge (все версии) – Opera (все версии) – Brave (все версии)
Конфигурация сети	– Моделирование сред 3G, 4G, 5G и сред с высокой задержкой – Wi-Fi и Ethernet-соединения
База данных	MySQL 8.0
Интеграция CI/CD	Jenkins или GitLab CI

7. Инструменты для тестирования

Если вы используете ручное тестирование, вам понадобится система управления тестированием, чтобы отслеживать результаты выполнения тест-кейсов. Наиболее часто используется Jira — универсальный инструмент для управления проектами, который также помогает отслеживать баги.

А результаты тестов и найденные баги часто фиксируют в гугл-таблицах — например, в такой:

Конечно, по мере масштабирования проекта такой подход становится неэффективным. В какой-то момент целесообразнее внедрить полноценную систему управления тестированием, которая интегрируется с другими действиями: написанием тестов, их выполнением и формированием отчетов.

Такая система должна также поддерживать автоматизацию тестирования. Представьте платформу, где можно писать автотесты, хранить тестовые объекты, данные и артефакты, запускать тесты в нужной среде и получать подробные отчеты по результатам.

Чтобы достичь такого уровня, у тестировщиков есть два варианта:

1. Разработать собственный фреймворк автоматизации с нуля
2. Использовать готовое решение от вендора

У каждого из вариантов есть плюсы и минусы. Первый — максимально гибкий и настраиваемый, но потребуются хорошие технические знания. Второй — предоставляет функциональность “из коробки”, но потребует вложений (временных, финансовых или и тех и других).

8. Результаты тестирования

Итоги тестирования отражают ранее поставленные цели.

Укажите, какие артефакты и документы должны быть созданы в ходе тестирования для отражения его хода и выявленных результатов. Поскольку стратегия тестирования — это документ высокого уровня, не требуется подробно расписывать каждый пункт, достаточно кратко обозначить перечень материалов, которые команда планирует подготовить.

9. Метрики и показатели тестирования

Определите ключевые показатели эффективности (KPI) и метрики успеха проекта. Эти метрики позволят оценить как эффективность и качество процесса тестирования, так и станут общей точкой отсчета и языком коммуникации внутри команды.

Типичные метрики тестирования включают:

• Покрытие тестами (Test Coverage): показывает процент кода, охваченного тестами.
• Плотность дефектов (Defect Density): число дефектов в определённом модуле или единице кода. Обычно измеряется как количество дефектов на тысячу строк кода (KLOC). Чем ниже показатель — тем выше качество.
• Утечка дефектов (Defect Leakage): количество багов, не обнаруженных на предыдущих этапах тестирования и выявленных позднее или после релиза.
• Среднее время до сбоя (MTTF – Mean Time to Failure): среднее время работы системы до момента сбоя.

Позже эти метрики визуализируются в итоговом отчете по тестированию.

10. Риски

Определите потенциальные риски и способы их минимизации. Добавьте запасной план действий, если риск все-таки реализуется.

Обычно тестировщики проводят анализ рисков (вероятность возникновения × потенциальное влияние), чтобы определить приоритеты в их устранении.

Например, после составления плана команда понимает, что сроки крайне сжаты, при этом не хватает технической экспертизы для выполнения задач. Это случай с высокой вероятностью и высоким влиянием. Необходим план действий: пересмотр целей, вложение в обучение команды или полное привлечение внешних специалистов.

Все перечисленные риски и меры должны быть внимательно изучены бизнес-командой, тимлидом QA и тимлидом разработки. На основе этого документа можно разрабатывать детализированные тест-планы для отдельных подпроектов или итераций спринта.

Пример тестовой стратегии

Для наглядности — пример тестовой стратегии:

Раздел	Содержание
1. Продукт, версия и обзор	–  Название продукта: Веб-приложение для электронной коммерции –  Редакция: v1.5 –  Обзор: Продукт представляет собой онлайн-платформу электронной коммерции, которая позволяет пользователям просматривать товары, добавлять их в корзину и совершать безопасные покупки. Включает адаптивный веб-интерфейс, мобильное приложение и серверную часть для управления запасами и обработки платежей.
2. История продукта	–  Предыдущие версии: v1.0, v1.2, v1.3 –  История ошибок: В предыдущих версиях наблюдались проблемы с интеграцией платежного шлюза и сохранением товаров в корзине. Эти проблемы были устранены благодаря модульному и интеграционному тестированию, что привело к улучшению общей надежности системы.
3. Функционал для тестирования	–  Пользовательские функции: поиск товаров, работа корзины, регистрация пользователей, оформление заказа. –  Уровни приложения: фронтенд (React.js), бэкенд (Node.js), база данных (MySQL), интеграции с API. –  Мобильное приложение: процесс покупки, push-уведомления. –  Сервер: балансировка нагрузки, синхронизация базы данных.
4. Функции, не подлежащие тестированию	–  Интеграция сторонней программы лояльности: будет протестирована в отдельном релизе. –  Устаревший способ оплаты: больше не поддерживается и исключён из тестирования в данном релизе.
5. Конфигурации, подлежащие тестированию	–  Мобильные устройства: iPhone 13 (iOS 15), Google Pixel 6 (Android 12). –  Десктоп: Windows 10, macOS Monterey. –  Браузеры : Chrome 95, Firefox 92, Safari 15, Edge 95. Исключенные конфигурации: старые версии Android (<9.0) и iOS (<12).
6. Требования к среде тестирования	–  Аппаратное обеспечение: реальные мобильные устройства, десктопы (Intel i7, Apple M1). –  Сеть: эмуляция сетевых условий (3G, 4G, Wi-Fi). –  Программное обеспечение: инструменты тестирования (Selenium, Appium, JMeter). –  Серверы: облачные среды на AWS для тестирования масштабируемости.
7. Методология системного тестирования	–  Модульное тестирование: проверка основных функций, таких как поиск и добавление в корзину. –  Интеграционное тестирование: проверка взаимодействия между корзиной, платежными системами и управлением запасами. –  Системное тестирование: полные сквозные сценарии пользователя (просмотр товаров, добавление в корзину, оформление заказа, получение подтверждения). –  Тестирование производительности: стресс-тестирование с помощью JMeter, имитирующее до 5000 одновременных пользователей. –  Тестирование безопасности: использование OWASP ZAP для выявления уязвимостей.
8. Первоначальные требования к тестированию	–  Стратегия тестирования: составлена специалистами по QA и утверждена продуктовой командой. –  Настройка тестовой среды: среды должны быть полностью настроены, включая серверы промежуточного (стейджинг) окружения, тестовые данные и имитацию платежных систем. –  Тестовые данные: создать фиктивных пользователей и каталоги товаров для комплексного системного тестирования.
9. Критерии начала системного тестирования	–  Основная функциональность работает: все ключевые функции (поиск, вход в систему, корзина) должны корректно функционировать. –  Пройдено 100% модульных тестов: все юнит-тесты должны быть успешно выполнены без ошибок. –  Заморозка кода: все функции реализованы, и код зафиксирован в репозитории. –  Известные ошибки задокументированы: все известные дефекты должны быть зарегистрированы в системе отслеживания багов.
10. Критерии завершения системного тестирования	–  Все системные тесты выполнены: все запланированные тесты должны быть проведены. –  Успешное прохождение критических сценариев: все основные сценарии («счастливый путь») — регистрация пользователя, покупка товара и т.д. — должны быть пройдены. –  Успешная сборка: должны быть получены исполняемые сборки для всех поддерживаемых платформ. –  Отсутствие критических ошибок: нет серьезных дефектов или блокирующих багов. –  Максимальное количество багов: не более 5 серьезных и 10 незначительных ошибок.
11. Результаты тестирования	–  План тестирования: подробный план, охватывающий системное, регрессионное и нагрузочное тестирование. –  Тест-кейсы: задокументированные тест-кейсы в Jira/TestRail. –  Логи выполнения тестов: записи всех проведённых тестов. –  Отчеты о дефектах: отчеты из системы отслеживания багов (Jira). –  Отчет о покрытии тестами: процент охваченных тестами функций и кода.
12. Метрики и показатели тестирования	–  Покрытие тестами: целевой показатель — 95% покрытия по юнит-, интеграционным и системным тестам. –  Плотность дефектов: поддерживать плотность дефектов менее 1 дефекта на 1000 строк кода. –  Производительность: обеспечить время отклика ключевых операций не более 2 секунд. –  Утечка дефектов: не допускать более 2% дефектов, попавших в продуктивную среду.
13. Риски	–  Нестабильность платежного шлюза: может вызвать сбои транзакций при высокой нагрузке. –  Проблемы кроссбраузерности: возможные несовпадения в работе на старых версиях браузеров. –  Высокая нагрузка пользователей: снижение производительности при количестве одновременно активных пользователей более 5000. –  Безопасность: риск уязвимостей из-за новых функций аутентификации пользователей.
14. Справочные материалы	–  Документация по продукту: внутренняя документация API для разработчиков. –  Документация по тестовым инструментам: руководства по настройке Selenium и JMeter. –  Внешние источники: рекомендации OWASP по обеспечению безопасности при тестировании.

При создании документа стратегии тестирования вы можете составить таблицу со всеми перечисленными выше пунктами и провести мозговой штурм с ключевыми заинтересованными сторонами (менеджером проекта, бизнес-аналитиком, лидом QA и техническим лидом разработки), чтобы заполнить необходимую информацию по каждому из пунктов. В качестве отправной точки можно использовать таблицу ниже.

План тестирования vs. Стратегия тестирования

Стратегия тестирования — это более общий документ, который задаёт направление для тестирования, тогда как план тестирования содержит конкретные детали и должен соответствовать стратегии.

Стратегия описывает общие методы и подходы к качеству продукта, учитывая разные типы ПО, потребности организации и политику качества. План тестирования составляется для конкретного проекта, где учитываются цели, участники и риски. В Agile можно создавать общий план для проекта и отдельные планы для каждой итерации.

В таблице ниже приведено подробное сравнение этих двух документов:

	Стратегия тестирования	План тестирования
Цель	Представляет общий подход, задачи и рамки тестирования ПО	Определяет подробные инструкции, процедуры и конкретные тесты, которые необходимо выполнить
Фокус	Подход к тестированию, уровни тестирования, типы и методы	Конкретные цели, тест-кейсы, данные для тестирования и ожидаемые итоги
Аудитория	Заинтересованные лица, руководители проектов, старшие специалисты по тестированию	Команда тестирования, тест-лиды, тестировщики и заинтересованные участники процесса тестирования
Область применения	Весь объём тестирования в рамках проекта	Определённый этап, функциональность или часть ПО
Уровень детализации	Меньше деталей, более общий подход	Очень подробный, с указанием сценариев, кейсов, скриптов и данных для тестирования
Гибкость	Позволяет быстро адаптироваться к изменениям требований проекта	Довольно жесткий, изменения во время тестирования нежелательны
Продолжительность действия	Относительно стабильна на протяжении всего жизненного цикла проекта	Развивается и изменяется в процессе тестирования, с учетом отзывов и корректировок

Перевод статьи «What is Test Strategy? Guide To Develop Test Strategy (With Sample)».