Кто составляет тест-план

Кто составляет тест-план?

В классическом понимании процесса тестирования ПО, тест-план — это ключевой документ, который определяет стратегию, объем, подход, график и ресурсы для тестирования конкретного проекта или функциональности. Ответственность за его создание лежит, в первую очередь, на руководителе тестирования (Test Lead) или менеджере по тестированию (Test Manager). В зависимости от зрелости процессов компании и структуры команды, к этому процессу также активно привлекаются старшие тестировщики (Senior QA Engineers) и тест-аналитики (Test Analysts).

Однако в современных гибких методологиях (Agile, Scrum) распределение ответственности может быть более широким и коллаборативным.

Ключевые участники и их роли в создании тест-плана

1. Руководитель тестирования / QA Team Lead

    *   **Основная ответственность.** Является владельцем документа и главным архитектором плана. Он:
        *   Определяет **общую стратегию** тестирования (например, риск-ориентированный подход).
        *   Формирует **расписание (график)** тестирования, синхронизируя его со спринтами или этапами разработки.
        *   Оценивает необходимые **ресурсы** (люди, тестовые среды, инструменты, данные).
        *   Устанавливает **критерии начала (Entry Criteria)** и **окончания (Exit Criteria)** тестирования.
        *   Координирует работу всей команды QA по наполнению плана.

1. Тест-аналитик / Старший QA-инженер

    *   **Контент-ответственность.** Отвечают за техническую и аналитическую глубину плана:
        *   Детализируют **область тестирования (Scope)** и, что не менее важно, **область НЕ тестирования (Out of Scope)**.
        *   Проектируют **тестовую стратегию** для различных уровней (модульное, интеграционное, системное тестирование) и типов (функциональное, нефункциональное, регрессионное).
        *   Определяют необходимые **тестовые среды, конфигурации и данные**.
        *   Выбирают и обосновывают **инструменты тестирования** (для автоматизации, управления тестами, баг-трекинга).
        *   Участвуют в оценке **рисков** и планировании действий по их смягчению.

1. Разработчики (Developers) и Архитекторы (Architects)

    *   **Роль консультантов.** Привлекаются для уточнения технических деталей:
        *   Предоставляют информацию о **архитектуре системы**, технологическом стеке, что критично для планирования интеграционного и нагрузочного тестирования.
        *   Согласовывают требования к **тестовым стендам** и процессу развертывания сборок (CI/CD).

1. Владелец продукта (Product Owner) / Бизнес-аналитик (Business Analyst)

    *   **Роль постановщиков целей.** Обеспечивают бизнес-контекст:
        *   Формулируют **цели тестирования** и **критерии приемки (Acceptance Criteria)**.
        *   Помогают расставить **приоритеты** для функциональности и, соответственно, для тестовых усилий.
        *   Участвуют в определении **критических бизнес-рисков**.

1. Вся команда QA (в Agile-среде)

    *   В рамках Agile/Scrum тест-план (часто в виде **Test Strategy** или «живого» документа) может создаваться всей командой тестирования на этапе планирования спринта или релиза. Каждый инженер вносит свой вклад в разделы, касающиеся его зоны ответственности.

Пример процесса и содержания

Процесс часто начинается с шаблона стандарта IEEE 829 или его адаптации. Вот ключевые разделы, над которыми работают перечисленные специалисты:

# Тест-план для проекта "Платежный шлюз v2.0"

## 1. Введение
*   **Ответственный:** Руководитель тестирования.
*   **Содержание:** Цели документа, ссылки на требования.

## 2. Объекты тестирования и область
*   **Ответственные:** Тест-аналитик + Владелец продукта.
*   **Содержание:** Список модулей (например, API процессинга, WEB-интерфейс администратора). Явно указано, что мобильное приложение не входит в scope текущего этапа.

## 3. Подход и стратегия
*   **Ответственные:** Руководитель тестирования + Старшие QA.
*   **Содержание:**
    *   Функциональное тестирование: метод черного ящика, эквивалентное разделение.
    *   Автоматизация: **API-тесты** на PyTest будут написаны для всех критичных платежных сценариев.
    *   Нагрузочное тестирование: с использованием **JMeter** для оценки пропускной способности.

## 4. Критерии входа/выхода и оценка рисков
*   **Ответственные:** Руководитель тестирования + Команда.
*   **Критерии входа:** Готова стабильная тест-среда, все критические баги предыдущего спринта закрыты.
*   **Главный риск:** Задержка поставки тестовых данных от внешнего провайдера. **План смягчения:** Разработать симулятор API провайдера силами разработчиков.

## 5. Ресурсы и расписание
*   **Ответственный:** Руководитель тестирования.
*   **Содержание:** График на 2 спринта, список ответственных, требования к окружениям (DEV, STAGE, PERF).

Итог

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