Перейти на PRO

Что такое критерии входа (Test Entry Criteria)?

Тип вопроса: Управление тестированием Вероятность: 10% Категория: QA Тестировщик

Ответ

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

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

  1. Готовность кода:
    • Код зафиксирован в системе контроля версий и помечен для тестирования (например, тег сборки).
    • Выполнено модульное и интеграционное тестирование разработчиками.
  2. Готовность тестовых артефактов:
    • Тест-план и тест-кейсы утверждены.
    • Тестовые данные подготовлены и доступны.
  3. Готовность окружения:
    • Тестовое окружение развёрнуто, настроено и доступно.
    • Выполнен smoke-тест для проверки базовой работоспособности окружения.
  4. Готовность команды:
    • Тестировщики ознакомлены с требованиями и тестовой документацией.

Пример реализации в CI/CD пайплайне (псевдокод):

# .gitlab-ci.yml или аналог
run_system_tests:
  stage: test
  script:
    - ./run_test_suite.sh
  # Критерии входа заданы правилами (rules)
  rules:
    - if: $CI_COMMIT_TAG =~ /-release-candidate$/  # Критерий 1: это RC-сборка
      when: on_success
    - if: $DEPLOY_TO_TEST_ENV == "true"            # Критерий 2: окружение развёрнуто
      when: on_success
    - when: never  # Если критерии не выполнены, этап пропускается

Последствия невыполнения: Начало тестирования при несоблюдении критериев ведёт к ложным срабатываниям, блокировкам тестов, нерелевантным результатам и потере времени.

Ответ 18+ 🔞

А, слушай, про эти ваши "критерии входа"! Это ж как турникет в метро, блядь. Не выполнил условия — нихуя не попадёшь на фазу тестирования, и правильно, ёпта!

Вот представь: приходит тестировщик, весь такой воодушевлённый, а ему — раз! Система не готова, код сырой, как говно мамонта, окружение не поднято. И что он будет делать? Смотреть в потолок и еб*ть веник? Ресурсы на ветер, время на хуй, а риск — овердохуища!

Типичные пунктики, которые надо прочекать, чтоб не сесть в лужу:

  1. Код, сука: Он должен быть не где попало, а зафиксирован, с тегом, чтоб я знал, что тестирую. И чтоб разработчики уже свою домашнюю работу сделали — модульки потестили, интеграцию проверили. А то принесут недописанный пиздёж, а мы потом баги ищем там, где их быть не должно!
  2. Бумажки всякие: План тестов, кейсы — утверждены, блядь. Данные тестовые приготовлены. Не чтобы я, как дурак, вручную сто значений вбивал, пока вы тут кофе пьёте.
  3. Окружение, ёпта: Стенд должен стоять, дышать и не падать от одного запроса. Обязательно smoke-тест гоняем — если система базово не работает, то какой смысл дальше-то, в рот меня чих-пых?
  4. Люди: Тестировщики в курсе, что за зверь им предстоит. Не тыкают кнопки наугад, а понимают, что и зачем проверяют.

Вот смотри, как в этих ваших CI/CD пайплайнах это выглядит, чтоб не было мудацких запусков:

run_system_tests:
  stage: test
  script:
    - ./run_test_suite.sh
  # А вот тут правила — наш турникет, блядь!
  rules:
    - if: $CI_COMMIT_TAG =~ /-release-candidate$/  # Во-первых, это точно RC-сборка, а не какая-то левая хуйня
      when: on_success
    - if: $DEPLOY_TO_TEST_ENV == "true"            # Во-вторых, окружение уже развернули, а не только обещали
      when: on_success
    - when: never  # Если хуйня какая — этап просто скипается, и не тратится ни секунды!

А если проигнорить эти критерии? Да писец просто! Ложные срабатывания посыпятся, как из дырявого мешка. Тесты будут висеть и падать не из-за багов, а потому что окружение кривое. Результаты — ни о чём. И время, блядь, самое дорогое, будет просрано в промышленных масштабах. Так что нехуй халявить, выполняем входные условия, и тогда уже работаем как люди!

© ХакСобесов, 2026
support@hacksobesov.com