Стратегия тестирования: зачем она нужна и как ее составить

В большинстве случаев работа над IT-проектом идет в условиях ограниченных человеческих и временных ресурсов. Понимать, какие именно это ресурсы и как использовать их эффективно, помогает стратегия тестирования. О документе, отвечающем заказчику на вопросы кто, что и как будет тестировать на проекте, рассказывает Никита Кузнецов, QA-инженер IT Test.

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

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

Общий обзор проекта и сферы тестирования

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

Методология

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

Тестовые окружения

В этом блоке перечисляют, на чем будут тестировать продукт в зависимости от типов тестирования и какие будут использовать тестовые данные. А также — каков порядок доступов на проекте, как происходят резервное копирование и восстановление, и кто за них ответственен.

Инструменты

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

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

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

Возможные риски

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

Результаты тестов

Здесь нужно перечислить виды документации, составляемой до, во время и после тестирования, а также порядок сводных отчетов о тестах с указанием периодичности (ежедневно, еженедельно или ежемесячно) в зависимости от критичности проекта.

Согласование и утверждение

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

Больше экспертных материалов о заказной разработке, дизайне и тестировании в Telegram-канале IT Test.