Какая документация разрабатывалась на каждом этапе классического цикла тестирования?

Документация в классическом цикле тестирования (V-Model)

В классическом цикле тестирования, часто представленном V-моделью (V-Model), документация разрабатывается параллельно с этапами разработки, что обеспечивает прямую трассировку требований к тестам. Каждый этап разработки "левой" части V имеет соответствующий этап тестирования на "правой" части, и для каждого из них создается специфическая документация. Основная цель — обеспечить полную и контролируемую проверку соответствия продукта исходным требованиям.

Этапы "левой" части V (Разработка) и сопутствующая документация

• Этап определения требований (Requirements Analysis)

    *   Разрабатывается: **Документ требований (Requirements Specification Document — RSD)** или **Бизнес-требования (Business Requirements)**.
    *   Форматы: Это может быть текстовый документ, набор функциональных требований (FR) и нефункциональных требований (NFR), таблицы в Excel или использование систем управления требованиями (например, Jira, Rally). Часто включает **Use Cases** и **User Stories**.
    *   Пример содержания:

    ```markdown
    # FR-001: Авторизация пользователя
    Система должна позволять пользователю войти с помощью email и пароля.
    Критерии приемки:
    1. При корректных данных — доступ предоставляется.
    2. При неверном пароле — выводится ошибка "Invalid password".
    3. При несуществующем email — выводится ошибка "User not found".
    ```

• Этап проектирования системы (System Design)

    *   Разрабатывается: **Архитектурный документ (System Design Document)** и **Высокоуровневые спецификации (High-Level Design — HLD)**.
    *   Цель: Описывает архитектуру системы, основные компоненты, их взаимодействие, технологии. Это основа для планирования интеграционного тестирования.

• Этап проектирования модулей (Module Design)

    *   Разрабатывается: **Детальные спецификации (Detailed Design Document — DDD)** или **Low-Level Design (LLD)**.
    *   Цель: Описывает внутреннюю логику отдельных модулей или классов, алгоритмы, структуры данных. Используется для создания юнит-тестов.

Этапы "правой" части V (Тестирование) и сопутствующая документация

• Юнит-тестирование (Unit Testing) — соответствует Module Design

    *   Разрабатывается: **План юнит-тестов (Unit Test Plan)** и сами **Юнит-тесты (Unit Test Cases)**.
    *   Цель: Проверить корректность работы отдельных функций, методов или классов.
    *   Форматы: Тесты обычно пишутся разработчиками в виде кода с использованием фреймворков (JUnit для Java, pytest для Python). Документацией может служить сам код тестов и, возможно, краткий план в виде checklist.
    *   Пример кода юнит-теста:

    ```python
    # test_login.py
    import pytest
    def test_valid_login():
        user = authenticate("test@mail.com", "correct_pass")
        assert user.is_authenticated == True
    
    def test_invalid_password():
        error = authenticate("test@mail.com", "wrong_pass")
        assert error == "Invalid password"
    ```

• Интеграционное тестирование (Integration Testing) — соответствует System Design

    *   Разрабатывается: **План интеграционного тестирования (Integration Test Plan)** и **Спецификации интеграционных тестов (Integration Test Cases)**.
    *   Цель: Проверить взаимодействие между модулями, компонентами или системами.
    *   Форматы: Документ описывает порядок интеграции (например, "Big Bang", поэтапно), сценарии взаимодействия, данные для передачи. Тест-кейсы часто включают проверки API, передачи данных между сервисами.

• Системное тестирование (System Testing) — соответствует Requirements Analysis

    *   Разрабатывается: **План системного тестирования (System Test Plan — один из ключевых документов QA)** и **Спецификации системных тестов (System Test Cases)**.
    *   Цель: Проверить готовую систему в целом на соответствие всем исходным функциональным и нефункциональным требованиям.
    *   Форматы:
        *   **План тестирования (Test Plan)**: Определяет **scope, подход, ресурсы, расписание, критерии начала/окончания тестов, риски**. По стандарту IEEE 829.
        *   **Тест-кейсы (Test Cases)**: Детальные шаги для проверки каждой функции. Часто хранятся в Test Management Tools (TestRail, Zephyr). Включают **Preconditions, Test Steps, Expected Results, Postconditions**.
        *   Пример структуры тест-кейса:

        ```markdown
        TC-ID: ST-001
        Title: Проверка успешной авторизации пользователя
        Precondition: Пользователь с email "user@test.com" и паролем "Pass123" зарегистрирован в системе.
        Steps:
        1. Открыть страницу логина.
        2. Ввести email "user@test.com".
        3. Ввести пароль "Pass123".
        4. Нажать кнопку "Login".
        Expected Result: Открывается главная страница пользователя, в верхнем меню отображается "Welcome, user@test.com".
        ```

• Приемочное тестирование (Acceptance Testing) — финальная проверка

    *   Разрабатывается: **План приемочного тестирования (Acceptance Test Plan)** и часто **Критерии приемки (Acceptance Criteria)**.
    *   Цель: Проверить, что система удовлетворяет потребности бизнеса и пользователя и готовы к выпуску.
    *   Форматы:
        *   **User Acceptance Test (UAT) Cases**: Сценарии, основанные на реальных бизнес-процессах пользователя.
        *   **Contract/Regulatory Acceptance Test Cases**: Для соответствия контрактам или нормативным требованиям.
        *   Критерии приемки часто изначально определяются в Requirements и затем формализуются в тест-кейсы.

Дополнительная документация, сопровождающая весь цикл

• Тест–стратегия (Test Strategy): Высокоуровневый документ, определяющий общие подходы, методологии и стандарты тестирования для проекта или организации.
• Чек-листы (Checklists): Используются для быстрых проверок, особенно в smoke/sanity тестировании или для проверки соответствия стандартам UI.
• Отчеты о дефектах (Bug Reports/Defect Reports): Создаются при обнаружении ошибок на любом этапе тестирования. Включают краткое описание, шаги для воспроизведения, ожидаемый/фактический результат, severity/priority, environment.
• Отчеты о тестировании (Test Summary Report/Test Completion Report): Финальный документ, суммирующий результаты тестирования, статистику (пройденные/непройденные тесты, найденные/исправленные дефекты), оценку качества и рекомендации по выпуску.

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