Приведи пример критерия окончания тестирования

Пример критерия окончания тестирования

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

Пример комплексного критерия окончания тестирования

Для веб-приложения "Интернет-банк" был разработан следующий набор критериев, который применяется перед каждым релизом в Production. Все условия должны быть выполнены одновременно.

1. Критерий, основанный на выполнении тестового плана

• Выполнено 100% запланированных тест-кейсов (как ручных, так и автоматизированных) с фиксацией результатов в тестовой системе (например, TestRail, Zephyr).
• Достигнут запланированный уровень покрытия требований (Requirements Coverage) в 95%. Это проверяется с помощью матрицы трассируемости (Traceability Matrix).

  -- Пример SQL-запроса для анализа покрытия в тест-менеджер системе
  SELECT
      r.requirement_id,
      r.description,
      COUNT(DISTINCT tc.test_case_id) as linked_test_count,
      CASE
          WHEN COUNT(DISTINCT tc.test_case_id) > 0 THEN 'COVERED'
          ELSE 'NOT COVERED'
      END as coverage_status
  FROM requirements r
  LEFT JOIN traceability_matrix tm ON r.id = tm.requirement_id
  LEFT JOIN test_cases tc ON tm.test_case_id = tc.id
  GROUP BY r.requirement_id, r.description;
  

• Автоматизированные регрессионные тесты (Automated Regression Suite) успешно прошли в CI/CD пайплайне не менее 3 раз подряд.

2. Критерий, основанный на метриках качества (Quality Metrics)

• Уровень критических и блокирующих дефектов (Severity 1 & 2) равен 0 в открытом состоянии. Все найденные дефекты этого уровня либо исправлены и перепроверены, либо приняты как "Не будет исправлено" с согласия Product Owner.
• Общее количество открытых дефектов не превышает заранее согласованного порога (например, 15 дефектов уровня Medium и ниже). Состояние дефектов стабильно, новых багов не появляется.
• Ключевые показатели производительности (Performance KPIs) соответствуют нефункциональным требованиям: время отклика основных операций < 2 секунды, система выдерживает расчетную пиковую нагрузку в 1000 пользователей.

3. Критерий, основанный на сроках и рисках (Risk-Based Criteria)

• Исчерпан выделенный на тестирование бюджет (время/ресурсы). Тестирование не может продолжаться бесконечно.
• Оставшиеся известные риски задокументированы, оценены и приняты ответственными лицами (руководителем проекта, заказчиком). Например: "В модуле отчётов известна некритическая ошибка форматирования при печати в браузере Safari. Риск принят, исправление запланировано в следующем спринте".
• Проведён тест-дизайн-ревью (Test Design Review) на предмет того, что все выявленные сценарии рисков (например, связанные с интеграцией платежного шлюза) были покрыты тестами.

4. Критерий, основанный на финальных активностях

• Проведена финальная демонстрация (Showcase/UAT) для заказчика, и получено его письменное или подтверждённое согласие на выпуск.
• Подготовлена и передана вся необходимая тестовая документация: итоговый отчёт о тестировании (Test Summary Report), акт о готовности, описание известных ограничений (Known Issues).
• Выполнены заключительные smoke-тесты (Smoke Testing) на предпродакшн-окружении (Staging Environment), максимально приближенном к боевому, и получен "зелёный" статус.

Почему это важно: выход за рамки "когда кончатся тест-кейсы"

Использование формальных критериев, как в примере выше, позволяет перевести решение о релизе из эмоциональной плоскости ("Кажется, всё работает") в объективную. Это минимизирует конфликты между командой разработки, которая хочет выпустить функционал быстрее, и командой тестирования, стремящейся к максимальному качеству. Все стороны заранее договорились о "правилах игры". Если все критерии соблюдены, продукт считается протестированным достаточно для выпуска, даже если у тестировщика осталось субъективное чувство незавершённости. Если критерии не выполнены — выпуск откладывается, и все понимают конкретную причину: например, остались два критических бага или не покрыто 10% требований.