Что такое критерии выхода?

Что такое критерии выхода?

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

Основные цели критериев выхода

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

Типичные примеры критериев выхода

Критерии выхода можно разделить на несколько категорий:

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

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

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

• Все критические (Critical) и высокоприоритетные (High) дефекты исправлены и перепроверены (закрыты).
• Количество открытых дефектов среднего (Medium) и низкого (Low) приоритета не превышает согласованного порога (например, не более 10 Medium и 20 Low).
• Период стабильности: в течение последних N дней (или часов) не обнаружено новых критичных багов.
• Достигнут определенный уровень коэффициента эффективности исправления дефектов (Defect Fix Rate или Defect Closure Ratio).

3. Критерии, связанные с процессами и артефактами:

• Вся требуемая тестовая документация (тест-планы, отчеты, матрица трассируемости) завершена и утверждена.
• Выполнена регрессионная проверка областей, затронутых последними исправлениями.
• Получено формальное разрешение (sign-off) от стейкхолдеров (product owner, бизнес-аналитик, менеджмент) на основе предоставленной отчетности.
• Все автоматизированные тесты из регрессионного набора прошли успешно (зелёный прогон).

Практический пример: критерии выхода для фазы System Testing

Допустим, мы готовим релиз версии 2.0 веб-приложения. Критерии выхода для фазы System Testing могут выглядеть так:

КРИТЕРИИ ВЫХОДА (System Testing v2.0)

1. Покрытие:
   - 100% функциональных требований, описанных в спецификации v2.0, покрыто тест-кейсами и проверено.
   - 90% кода основной бизнес-логики покрыто модульными тестами (по отчету SonarQube).

2. Дефекты:
   - Все дефекты с Severity "Blocker" и "Critical" (Priority P0-P1) закрыты (исправлены и верифицированы).
   - Количество открытых дефектов Severity "Major" (Priority P2) ≤ 5.
   - Общее количество открытых дефектов Severity "Minor"/"Trivial" (Priority P3-P4) ≤ 15.
   - За последние 48 часов непрерывного тестирования не выявлено новых дефектов с Severity выше "Major".

3. Нефункциональные требования:
   - Стресс-тестирование подтвердило поддержку 1000 одновременных пользователей со временем отклика ≤ 2 сек (p95).
   - Основные сценарии безопасности (авторизация, инъекции) проверены и уязвимостей не обнаружено.

4. Процессы:
   - Составлен итоговый отчет о тестировании.
   - Регрессионный прогон 300 ключевых автоматизированных UI-тестов успешно завершен (успешность > 98%).
   - Product Owner провел демонстрацию ключевого функционала и подтвердил соответствие ожиданиям.

Важность критериев выхода для QA-инженера

Для QA-инженера работа с критериями выхода — это:

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

Заключение: Практически всегда критерии выхода устанавливаются в тест-плане на этапе планирования и являются его неотъемлемой частью. Их корректная установка и мониторинг — признак зрелого процесса тестирования и ключевая компетенция опытного QA-специалиста, позволяющая нести конкретную измеримую ответственность за качество продукта.

Что такое критерии выхода (Exit Criteria)?

Критерии выхода — это заранее определённый набор условий, требований или метрик, которые должны быть выполнены для успешного завершения определённой фазы тестирования (например, тест-плана, тест-цикла, спринта или всего проекта). Это объективные и измеримые «ворота», которые позволяют команде принять обоснованное решение: можно ли считать тестирование завершённым и переходить к следующему этапу (релизу, передаче в эксплуатацию) или нет. По сути, это ответ на ключевой вопрос: «Когда мы можем закончить тестирование?».

В противоположность критериям входа (Entry Criteria), которые определяют, когда можно начинать тестирование, критерии выхода фокусируются на его окончании. Их установка — одна из ключевых задач планирования тестирования, которая помогает избежать двух крайностей: преждевременного прекращения тестирования (что ведёт к выходу некачественного продукта) и бесконечного, неэффективного «перетестирования».

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

• Объективная оценка готовности: Заменяют субъективное мнение («мне кажется, уже достаточно») на объективные данные.
• Управление рисками: Позволяют осознанно принимать решение о релизе, понимая, какие риски остаются (например, «все критические баги исправлены, но 5 незначительных багов в low-priority функционале приняты как known issues»).
• Повышение прозрачности: Дают чёткое понимание статуса проекта всем заинтересованным сторонам (менеджменту, разработке, заказчику).
• Контроль качества: Гарантируют, что продукт соответствует минимально приемлемому уровню качества для выпуска.
• Эффективное планирование: Помогают оценить необходимые усилия и сроки для достижения целей тестирования.

Типичные примеры критериев выхода

Критерии выхода обычно делятся на несколько категорий и должны быть SMART (конкретными, измеримыми, достижимыми, релевантными, ограниченными по времени).

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

• Достигнут запланированный % покрытия требований тестами (например, 100%).
• Выполнено не менее X% запланированных тест-кейсов (часто 95-100% для smoke/sanity и critical path).
• Автоматизированные регрессионные тесты выполнены успешно на определённых окружениях.

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

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

• Все баги с критической и высокой степенью серьёзности (Blocker, Critical, Major) закрыты (исправлены и перепроверены).
• Количество открытых багов с приоритетом Medium и Low не превышает согласованного лимита (например, не более 5 Medium и 10 Low).
• Отслеживание тенденций: График открытия/закрытия дефектов показывает плато, новые критичные баги не обнаруживаются в течение последних N дней тестирования.
• Для оставшихся открытых багов низкого приоритета оформлены согласованные known issues (документированы, оценены по риску и приняты Product Owner'ом).

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

• Достигнуты целевые показатели производительности (время отклика, throughput) под нагрузкой.
• Проведено и успешно пройдено тестирование безопасности по заданному чек-листу или стандарту (например, OWASP Top 10).
• Тестирование совместимости на целевых браузерах, устройствах и ОС завершено с приемлемым результатом.
• Выполнены требования по юзабилити (успешное прохождение usability-сессий с фокус-группой).

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

• Вся необходимая документация (руководства пользователя, релиз-ноты, отчёты о тестировании) подготовлена и утверждена.
• Критерии приёмки (Acceptance Criteria) для всех пользовательских историй (User Stories) в спринте выполнены и подтверждены Product Owner'ом.
• Получен сигнал одобрения от ключевых стейкхолдеров (например, подпись акта о готовности).

Пример из практики (Agile/Scrum спринт)

Для двухнедельного спринта в Jira критерии выхода для команды QA могут выглядеть так:

# Пример критериев выхода для спринта "Реализация корзины покупок v2.0"

1. Критерии выполнения:
   - Все тест-кейсы (75 штук) для затронутых пользовательских историй выполнены.
   - Автоматизированные API-тесты для корзины (набор из 20 тестов) проходят успешно в CI/CD пайплайне.

2. Критерии по дефектам:
   - Нет открытых багов с приоритетом P1 (Blocker) и P2 (Critical).
   - Количество открытых багов P3 (Major) ≤ 2.
   - Все баги, обнаруженные в этом спринте, имеют актуальный статус (не в состоянии "Open" без комментариев более 2 дней).
   - Для 3-х оставшихся багов P4 (Minor) по визуальному оформлению созданы known issues и приняты PO.

3. Критерии качества:
   - Новый функционал проходит E2E-сценарий "Добавление товара -> применение промокода -> оформление заказа" без ошибок.
   - Время отклика API корзины под нагрузкой (50 concurrent users) не превышает 200 мс (p95).
   - Релиз-ноты для новой версии корзины составлены и выложены в Confluence.

Процесс работы с критериями выхода

1. Определение: Устанавливаются на этапе планирования тестирования (в тест-плане) или в начале спринта. Обязательно согласуются со всей командой (разработка, PM, PO).
2. Мониторинг: Регулярно отслеживается прогресс в их достижении (на ежедневных стендапах, по итогам тест-циклов).
3. Верификация: По завершению фазы тестирования проводится финальная проверка.
4. Принятие решения:

    *   Если **все критерии выполнены** — тестирование считается успешно завершённым, продукт/версия готовы к следующему шагу.
    *   Если **критерии не выполнены** — команда либо продлевает тестирование, либо (после оценки рисков и согласования) **осознанно** меняет/смягчает сами критерии для выхода, документируя причины и потенциальные последствия.

Заключение: Критерии выхода — это не просто формальность, а мощный инструмент управления качеством и проектом. Они переводят разговоры о готовности из эмоциональной плоскости в плоскость фактов и данных, что значительно повышает зрелость процессов разработки и предсказуемость результатов. Грамотно определённые критерии защищают команду от необоснованного давления с целью «выпустить хоть что-то» и дают QA-инженеру чёткие основания для своего вердикта о качестве.