Стратегия тестирования: зачем она нужна и как ее составить
В большинстве случаев работа над IT-проектом идет в условиях ограниченных человеческих и временных ресурсов. Понимать, какие именно это ресурсы и как использовать их эффективно, помогает стратегия тестирования. О документе, отвечающем заказчику на вопросы кто, что и как будет тестировать на проекте, рассказывает Никита Кузнецов, QA-инженер IT Test.
В стратегии тестирования четко определены подход и цели тестирования п роекта: после ее прочтения должно быть понятно, что именно будет делать QA-команда. Также на ее основе пишут тест-планы и другие низкоуровневые документы.Содержание стратегии тестирования Не существует единого шаблона тест-стратегии. Содержание документа будет зависеть от компании, проекта и того, насколько заказчик хочет быть в курсе тестирования. Однако можно выделить наиболее часто прописываемые в разных сочетаниях пункты. Общий обзор проекта и сферы тестирования В первую очередь стоит зафиксировать цели тестирования проекта и определить, каким критериям должен соответствовать конечный результат. Здесь же место для расписания этапов работы со сроками выполнения и назначения ответственных за реализацию целей. Методология В этом разделе следует описать уровни и типы тестирования, которые будут использоваться на проекте, способы автоматизации и обязанности каждого члена QA-команды. Тестовые окружения В этом блоке перечисляют, на чем будут тестировать продукт в зависимости от типов тестирования и какие будут использовать тестовые данные. А также — каков порядок доступов на проекте, как происходят резервное копирование и восстановление, и кто за них ответственен. Инструменты Здесь необходимо раскрыть, какими именно способами проджект-менеджеры будут управлять процессами в команде, а QA-инженеры — тестировать производительность и безопасность. Сюда же стоит включить спецификации предлагаемых инструментов (возможное количество пользователей и прочую специфику применения) и метрики, с помощью которых будут анализировать статус проекта. Управление релизами Это раздел для информации о релизах: насколько часто они будут происходить, что должно быть проверено перед ними, каков порядок регресса и развертывания релиза на продакшен, возможности и условия незапланированных релизов, и кто за всё это отвечает. Возможные риски Место для краткого описания всего, что может пойти не так, с возможными способами устранения этих рисков и их последствий. Также полезно составить план действий на крайний случай — если произойдет что-то, чего вы не предусмотрели. Результаты тестов Здесь нужно перечислить виды документации, составляемой до, во время и после тестирования, а также порядок сводных отчетов о тестах с указанием периодичности (ежедневно, еженедельно или ежемесячно) в зависимости от критичности проекта. Согласование и утверждение Последний раздел документа предназначен для виз ответственных лиц. После подготовки стратегии тестирования ее проверяют и подтверждают команда управления проекта, лиды разработчиков, команда бизнеса и менеджмент компании. Здесь фиксируют даты утверждения, внесенные изменения с указанием инициатора, а также обновления и корректировки, сделанные уже в ходе процесса тестирования. В итоге должен получиться документ, после прочтения которого станет ясно, какую команду нужно собрать и какие ресурсы выделить для тестирования проекта. Несомненно, всё предусмотреть невозможно, но грамотно составленная стратегия тестирования поможет определить сроки проекта, порядок привлекаемых ресурсов и возможные затраты на устранение возникающих проблем.Стратегию прописывают, чтобы понять, сколько человек, какими инструментами и в какие сроки будут решать задачу по тестированию продукта, то есть какие нужны ресурсы, и как менеджеру проекта использовать их наиболее эффективно.