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

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

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

Проще говоря, это "зеленый свет" или разрешение на старт тестирования. Если критерии не выполнены, начало тестирования либо откладывается, либо осуществляется с четким пониманием и документированием принятых рисков.

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

Основная цель — минимизировать бесполезные затраты и время команды QA. Запуск тестирования на "сыром", нестабильном продукте приводит к:

• Нахождению огромного количества блокирующих багов, которые маскируют более глубокие проблемы.
• Трате времени тестировщиков на создание и прогон тестов, которые не дадут релевантной информации о качестве.
• Разочарованию команды и подрыву доверия к процессу.

Конкретные задачи:

• Обеспечение готовности тестовой среды: Среда развернута, стабильна, соответствует спецификации и доступна для команды QA.
• Гарантия доступности и качества тестовых артефактов: Тест-кейсы, чек-листы, тестовые данные и автоматизированные скрипты подготовлены и проверены.
• Подтверждение готовности билда/версии для тестирования: Полученная сборка прошла базовую проверку (смок-тестирование, санитарные проверки) и содержит все заявленные функциональные изменения.
• Формализация договоренностей: Четкое определение момента передачи ответственности от команды разработки к команде тестирования.

Типичные примеры Test Entry Criteria

Критерии варьируются в зависимости от проекта, методологии (Waterfall, Agile) и этапа тестирования (например, критерии для старта приемочного тестирования (UAT) будут строже, чем для начала интеграционного). Вот распространенные примеры:

1. Критерии для начала функционального тестирования новой версии:

    *   Код залит в выделенную тестовую среду и промаркирован определенным тегом/ревизией.
    *   Выполнено и успешно пройдено **Smoke Test** (или **Build Verification Test**) — минимальный набор тестов, проверяющий "живучесть" основных функций.
    *   Все критические и блокирующие баги из предыдущего цикла закрыты.
    *   Тест-план утвержден.
    *   Актуальная версия требований/спецификаций доступна команде тестирования.
    *   Тестовая среда изолирована от продуктовой и других процессов.

1. Критерии для запуска регрессионного тестирования:

    *   Все баги, связанные с исправляемым функционалом, верифицированы и закрыты.
    *   Наборы для регрессии (ручные и/или автотесты) актуализированы и готовы к выполнению.
    *   Среда очищена от данных предыдущих регрессионных циклов или подготовлены скрипты для инициализации.

1. Технический пример критерия (скрипт проверки):

    Часто автоматизируется. Например, перед запуском ночного прогона автотестов может проверяться:

```bash
#!/bin/bash
# Скрипт проверки критериев входа для автотестов
BUILD_STATUS=$(curl -s http://jenkins/job/project-build/lastBuild/api/json | jq -r '.result')
ENV_AVAILABLE=$(curl -s -o /dev/null -w "%{http_code}" http://test-environment:8080/health)

if [ "$BUILD_STATUS" = "SUCCESS" ] && [ "$ENV_AVAILABLE" = "200" ]; then
    echo "Entry Criteria MET. Starting test suite..."
    # Запуск тестового фреймворка (например, pytest)
    pytest ./regression_suite/
else
    echo "Entry Criteria NOT MET. Build status: $BUILD_STATUS, Env status: $ENV_AVAILABLE"
    exit 1
fi
```

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

1. Определение: Критерии устанавливаются совместно командами разработки, тестирования и менеджмента на этапе планирования (в Test Plan). Они должны быть измеримыми и объективными (не "код хороший", а "смок-тест пройден").
2. Проверка: Ответственное лицо (часто лид QA или менеджер) перед намеченной датой старта проверяет выполнение каждого пункта.
3. Решение:

    *   **Критерии выполнены** -> Тестирование начинается.
    *   **Критерии не выполнены** -> Проводится встреча (например, **Quality Gate meeting**). Принимается решение: отложить старт, начать с незавершенными критериями (осознавая риски) или пересмотреть сами критерии, если они нерелевантны.

1. Документирование: Результат проверки и решение фиксируются. Это важно для аудита и анализа процесса.

Связь с другими концепциями

• Test Exit Criteria (Критерии выхода): Логическое продолжение. Условия, при которых тестирование считается завершенным (например, "все тесты выполнены", "уровень критических багов = 0", "достигнут целевой уровень покрытия кода").
• Definition of Ready (DoR) в Agile: Очень близкое по смыслу понятие. DoR для пользовательской истории часто включает в себя и критерии для начала ее тестирования (например, "API mock готов", "дизайн утвержден").
• Quality Gates: Контрольные точки в процессе разработки, где проверяется набор критериев (часто включающих Entry Criteria) для перехода на следующий этап.

Вывод: Test Entry Criteria — это не бюрократическое препятствие, а инструмент профессионального risk-based подхода к тестированию. Их использование повышает предсказуемость процессов, защищает время и ресурсы команды QA и, в конечном итоге, способствует выпуску более качественного продукта, так как тестирование фокусируется на поиске существенных дефектов, а не на борьбе с нестабильностью окружения или недоработанными функциями.