Что такое Test Exit Criteria?

Что такое Test Exit Criteria?

Test Exit Criteria (Критерии завершения тестирования) — это формально определенный и задокументированный набор условий, требований или метрик, при достижении которых команда тестирования может принять объективное решение о завершении тестирования на текущем этапе (итерации, спринта, фазы) или в целом по проекту. Это критически важный элемент планирования тестирования и управления качеством, который обеспечивает прозрачность, предотвращает преждевременное или, наоборот, чрезмерно затянутое тестирование, и формализует точку, когда продукт считается достаточно протестированным для перехода на следующий этап жизненного цикла (например, в релиз).

Главная цель критериев выхода — перевести субъективные суждения о "достаточности" тестирования ("мы всё проверили, можно выпускать") в объективные, измеримые и согласованные со всеми заинтересованными сторонами (разработка, менеджмент, бизнес) показатели.

Ключевые цели и функции

• Объективность принятия решений: Замена вопросов "Вы уже закончили?" на проверку конкретных чек-листов.
• Управление рисками: Четкое понимание, какие риски (в виде непротестированных областей или открытых дефектов) мы сознательно принимаем, выпуская продукт.
• Прогнозируемость и планирование: Помогает оценить и контролировать сроки тестирования.
• Повышение прозрачности: Все участники проекта понимают, что именно должно быть выполнено, чтобы тестирование считалось успешным.

Типичные категории критериев завершения тестирования

1. Критерии, связанные с выполнением тестов

• Достижение запланированного покрытия требований (Requirements Coverage): Все ключевые пользовательские истории или функциональные требования покрыты тест-кейсами и проверены.

  -- Пример метрики: Доля покрытых требований
  SELECT (COUNT(DISTINCT requirement_id_covered) / COUNT(DISTINCT requirement_id_total)) * 100 AS coverage_percent
  FROM test_coverage;
  -- Критерий: coverage_percent >= 95%
  

• Выполнение тестового набора: Успешно выполнена запланированная доля всех тест-кейсов (например, 100% кейсов с высоким приоритетом и 95% всех остальных). Учитывается процент успешных, проваленных и заблокированных тестов.

2. Критерии, связанные с качеством кода (для автоматизированного тестирования)

• Достижение целевых показателей покрытия кода (Code Coverage): Например, модульные тесты покрывают 80% бизнес-логики.
• Устранение "слабых мест" (Hotspots): Протестированы модули с высокой цикломатической сложностью или частыми изменениями.

3. Критерии, связанные с дефектами

Это наиболее распространенная и критичная группа критериев.

• Статистика дефектов: Все заведенные дефекты имеют конечный статус (Closed, Deferred, Rejected). Нет дефектов в статусах "Open" или "Reopened" для определенных уровней серьезности.
• Пороги серьезности/приоритета дефектов:

    *   Критичные (Severity: Critical/Blocker) дефекты: **0 открытых**.
    *   Серьезные (Major) дефекты: **≤ 3 открытых** (и все имеют согласованные обходные пути или запланированы на следующий релиз).
    *   Количество дефектов с низким приоритетом (Minor/Trivial) не превышает оговоренного лимита.

• Стабилизация дефектного потока: Количество вновь обнаруживаемых дефектов за последние N дней стабилизировалось и упало ниже определенного порога (кривая открытия дефектов вышла на "плато").

4. Критерии, связанные со сроками и ресурсами

• Исчерпание выделенного на тестирование времени/бюджета. Этот критерий часто вторичен и должен рассматриваться в связке с критериями по дефектам и покрытию. Релиз "по дате" — это осознанный компромисс.

5. Критерии, связанные с нефункциональными требованиями

• Выполнение тестов производительности с достижением целевых показателей (например, время отклика < 2 сек при нагрузке 1000 пользователей).
• Завершение тестирования безопасности и устранение уязвимостей критического и высокого уровня.
• Успешное прохождение тестов на совместимость с целевыми браузерами, устройствами, ОС.

Процесс применения на практике

1. Определение: Критерии выхода обсуждаются и фиксируются в Test Plan в начале проекта/спринта.
2. Мониторинг: В ходе тестирования команда регулярно (например, на ежедневных стендапах или по итогам тестового цикла) сверяет текущие метрики с целевыми критериями.
3. Принятие решения: По завершению цикла тестирования ответственное лицо (Test Lead, QA Manager) проводит финальную оценку.

    *   Если **ВСЕ** критерии выполнены — тестирование может быть завершено, продукт готов к следующей фазе.
    *   Если **НЕ ВСЕ** критерии выполнены — возможны три варианта:
        *   **Продолжить тестирование** для достижения критериев (если есть время/ресурсы).
        *   **Пересмотреть и ослабить критерии** по согласованию с заинтересованными сторонами (например, согласиться выпустить продукт с 2 открытыми дефектами уровня Major, если для них есть workaround).
        *   **Заблокировать релиз** и вернуть продукт на доработку (если есть неисправленные критические дефекты).

Таким образом, Test Exit Criteria — это не просто бюрократический пункт в плане, а рабочий инструмент контроля качества, который позволяет команде выйти из фазы тестирования обоснованно, предсказуемо и с четким пониманием уровня рисков, которые несет с собой выпускаемая версия продукта.