Какую документацию нужно заводить на этапе планирования?

Документация на этапе планирования в QA

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

1. Документы, описывающие что тестировать и зачем

• Тест-стратегия (Test Strategy): Высокоуровневый документ, определяющий общий подход к тестированию на проекте. Он отвечает на вопросы:

    *   Каковы **цели и объем (scope)** тестирования?
    *   Какие **типы тестирования** будут применяться (функциональное, нефункциональное, регрессионное)?
    *   Каковы **критерии начала (Entry Criteria)** и **окончания (Exit Criteria)** тестирования?
    *   Как будут управляться **риски**?
    *   Какие **метрики** будут использоваться для оценки качества?
    *   Стратегия часто является частью **Плана обеспечения качества (Quality Assurance Plan)**.

• План тестирования (Test Plan): Более детальный, "рабочий" документ, основанный на стратегии. Он фокусируется на конкретной итерации, релизе или функциональном модуле. В нем описывается:

    *   **Расписание (Schedule)** и сроки.
    *   Распределение **ресурсов** (команда, стенды, инструменты).
    *   Детальный **объем тестирования (Features in/out of scope)**.
    *   Окружения (**Test Environments**): стенды для тестирования, конфигурации.
    *   **Критерии приемки (Acceptance Criteria)** для функций.

2. Документы, описывающие как тестировать

• Чек-листы (Checklists): Структурированные, но не детализированные списки проверок для определенной функциональности или типа тестирования (например, "Чек-лист smoke-тестов" или "Чек-лист проверки формы регистрации"). Обеспечивают покрытие и предотвращают пропуск очевидных сценариев.

• Тест-кейсы (Test Cases): Детальные, пошаговые инструкции для проверки конкретного условия. На этапе планирования часто создаются их высокоуровневые прототипы или шаблоны. Ключевые атрибуты:

    *   Уникальный ID и название.
    *   Предусловия (Preconditions).
    *   Шаги (Test Steps) с ожидаемыми результатами (Expected Results).
    *   Приоритет (Priority) и серьезность (Severity).
    *   Пример простого тест-кейса в формате Gherkin (Behavior-Driven Development):

    ```gherkin
    Feature: Login functionality
      Scenario: Successful login with valid credentials
        Given the user is on the login page
        When the user enters a valid username and password
        And clicks the 'Login' button
        Then the user is redirected to the dashboard page
        And a welcome message is displayed
    ```

3. Документы, описывающие что разрабатывается

• Требования (Requirements): Основа для всей тестовой документации. QA-инженер должен работать с:

    *   **Техническим заданием (ТЗ / SRS - Software Requirements Specification)**.
    *   **Пользовательскими историями (User Stories)** в backlog.
    *   **Макетами и прототипами (Wireframes, Mockups, UI/UX Design)**.
    *   На этом этапе критически важно проводить **анализ и ревью требований**, выявляя неоднозначности, противоречия и "дыры". Результатом такого анализа может стать **чек-лист требований** или список уточняющих вопросов к аналитикам/заказчику.

4. Вспомогательная и процессная документация

• Матрица трассируемости требований (Requirements Traceability Matrix - RTM): Таблица, которая связывает требования с тест-кейсами. На этапе планирования заводится ее каркас, что позволяет сразу видеть, какое требование какими тестами покрыто, и обеспечить полное покрытие (coverage).
• План по рискам (Risk Management Plan): Выявление потенциальных рисков (технических, ресурсных, временных), их оценка и планирование митигирующих действий.
• Конфигурация тестовых окружений (Test Environment Setup Document): Описание состава, настроек, данных и доступа к стендам. План по подготовке тестовых данных (Test Data).
• Чарт/план автоматизации (Test Automation Charter/Plan): Если планируется автоматизация, определяются ее цели, охват, выбираются фреймворк и инструменты, оцениваются усилия.

Ключевые принципы при создании документации на этапе планирования

1. Живые документы: Документация должна легко актуализироваться. Используйте wiki (Confluence), системы управления тестированием (TestRail, Zephyr), позволяющие хранить все артефакты в одном месте и иметь историю изменений.
2. Достаточная детализация: Документ должен быть полезным, а не формальным. Он должен давать ответы команде, а не просто существовать для галочки.
3. Согласованность: Все документы должны быть логически связаны друг с другом (Требование -> Чек-лист -> Тест-кейс -> Баг-репорт).
4. Практичность: Фокус на том, что реально будет использоваться в работе. Избыточная документация так же вредна, как и ее отсутствие.

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