Ответ
Решение о завершении тестирования — это взвешенная оценка рисков, основанная на заранее определенных и измеримых критериях (Exit Criteria).
Ключевые факторы:
- Выполнение критериев завершения (Exit Criteria):
- Достигнут целевой процент покрытия кода тестами.
- Все запланированные тестовые сценарии выполнены.
- Выполнены требования к качеству: отсутствуют открытые баги с приоритетами Blocker/Critical, количество багов High/Medium ниже установленного порога.
- Оценка рисков: Анализ потенциального воздействия необнаруженных багов на бизнес и пользователей. Приемлемый уровень риска согласуется с продукт-менеджером.
- Ограничения по срокам и бюджету: Реальные сроки релиза могут диктовать окончание тестовой фазы.
- Стабильность продукта: Частота появления новых багов снизилась до минимума, основные функциональные потоки работают стабильно.
Пример формализации критериев (псевдокод):
def should_stop_testing(project_metrics, risk_profile="standard"):
exit_criteria = {
"test_execution": project_metrics.percent_tests_executed >= 100,
"critical_bugs": project_metrics.open_critical_bugs == 0,
"high_priority_bugs": project_metrics.open_high_bugs <= 3,
"new_bug_rate": project_metrics.new_bugs_last_week < 5
}
# Для высокорисковых проектов критерии строже
if risk_profile == "high":
exit_criteria["high_priority_bugs"] = 0
return all(exit_criteria.values())Решение принимается совместно QA-лидом, менеджером проекта и продукт-менеджером.
Ответ 18+ 🔞
Слушай, ну вот смотри, все эти умные книжки про тестирование рассказывают, как надо красиво и по науке. А на деле-то часто получается, что мы, как Герасим с Муму, стоим у реки и думаем: топить или не топить, то есть заканчивать или нет. Страшно, блядь, ошибиться!
Так вот, чтобы не быть немым крестьянином, который только «Му-му» мычит, когда у него спрашивают «чё по релизу?», нужно иметь чёткие, ёбта, ориентиры. Не просто «ну вроде всё ок», а измеримую хуйню, в которую тыкнуть можно.
На что смотрим, когда решаем, что пора валить домой:
-
Критерии завершения — наш святой грааль. Это не абстрактные пожелания, а конкретные цифры, которые мы все заранее подписали кровью.
- Накрыли тестами нужный процент кода? Не «ой, вроде много», а вот эта вот циферка в отчёте.
- Все запланированные тест-кейсы прошли? Все, блядь, до единого. Не «ну кроме этих трёх хитрых, их завтра доделаем» — нихуя, сегодня.
- Качество в норме? Нет открытых багов, от которых продукт горит синим пламенем (Blocker/Critical). А багов уровня «высокий» и «средний» — не больше, чем мы сами себе позволили. Иначе это не релиз, а автоподжог.
-
Оценка риска, или «а нам на это похуй?». Вот представь: нашли баг — кнопка «купить» мигает розовым раз в сто нажатий. Риск? Пользователь, может, офигеет, но купит всё равно. А если баг — «после оплаты деньги списываются, а заказ не создаётся»? Это уже, простите, пиздец и разговор с юристами. Оцениваем, какой риск мы готовы затолкать в релиз, и договариваемся об этом с продактом. Он потом не скажет «а чё так вышло?».
-
Давление сроков, оно же «пора уже, блядь». Реальность — жестокая шлюха. Иногда календарь и бюджет кричат «СТОП!» громче, чем все наши идеальные критерии. Приходится принимать решение: вот с таким набором косяков мы можем жить, потому что иначе проект накроется медным тазом.
-
Стабильность, она же «перестало сыпаться». Если в последние дни тестирования новые баги появляются реже, чем трезвые мысли у менеджера в пятницу, — это хороший знак. Основные сценарии работают, не падают. Продукт устаканился.
А вот как это может выглядеть в коде, чтобы не мычать, а чётко знать:
def пора_ли_уже_закругляться(метрики_проекта, профиль_риска="стандартный"):
наши_требования = {
"тесты_выполнены": метрики_проекта.процент_выполненных_тестов >= 100,
"критические_баги": метрики_проекта.открытые_критические_баги == 0,
"баги_высокого_уровня": метрики_проекта.открытые_баги_хай <= 3,
"темп_появления_багов": метрики_проекта.новые_баги_за_неделю < 5
}
# Если проект важный, как ипотека твоей бабушки, то затягиваем гайки
if профиль_риска == "высокий":
наши_требования["баги_высокого_уровня"] = 0
# Если ВСЕ условия True — можно нести билд на прод. Если нет — сиди, работай.
return all(наши_требования.values())И главное, ёпта! Это решение не тестировщик в одиночку принимает, упиваясь своей властью. Нет! Это коллективное творчество: QA-лид, менеджер проекта и продакт-менеджер садятся, смотрят на цифры, на риски, на календарь и вместе говорят: «Да, хуле, пошли уже в прод, или нет, блядь, ещё недельку потыкаем». Чтобы потом не было мучительно больно, как Герасиму на берегу.