Ответ
Тестирование считается завершенным при выполнении заранее определенных и согласованных критериев выхода (exit criteria). Основные критерии:
- Выполнение плана: Все запланированные тесты (по приоритетам) выполнены.
- Покрытие требований: Проверены все ключевые функциональные и нефункциональные требования.
- Качество дефектов: Достигнуты целевые показатели по дефектам (например,
0 Critical/Highбагов в статусе "Open"). - Стабильность системы: Нет блокирующих проблем, система готова к релизу.
- Исчерпание ресурсов: Выделенное время или бюджет израсходованы (этот критерий часто требует пересмотра плана, если другие цели не достигнуты).
Пример критериев в тест-плане:
- Выполнено 100% тест-кейсов с приоритетом P1 и P2.
- Открыто 0 дефектов с severity Critical или Blocker.
- 95% дефектов с severity High исправлены и верифицированы.
- Покрытие кода unit-тестами достигло 80%.Важно: Завершение тестирования — это не гарантия отсутствия багов, а выполнение формальных условий, позволяющих принять решение о выпуске продукта с приемлемым уровнем риска.
Ответ 18+ 🔞
Ага, слушай, вот эта вся официальщина про «критерии выхода» — она, конечно, нужна, чтобы начальство не охуело с утра. Но если на пальцах, то тестирование заканчивается, когда все уже настолько заебались, что готовы рискнуть и выпустить эту бандуру в продакшн.
Вот смотри, как это работает на самом деле:
-
План выполнен? Ну типа да. Все тесты из списка, на которые у нас были силы и время, мы проебались. Особо важные (P1, P2) — те точно. Остальное — по остаточному принципу, но в отчёте пишем «100%», ёпта. Главное — график красиво закрасить.
-
Требования покрыты? Те, которые нам вменяемые аналитики написали и которые не менялись каждые три часа — да, покрыты. А те, которые «ну это же очевидно» или «ой, мы забыли вам сказать» — нихуя не покрыты. Но в отчёт идёт пункт «Ключевые требования проверены». И все довольны.
-
Качество дефектов. Вот это святое. Наша главная мантра:
0 Critical/High открытых багов. Пока эта цифра не ноль, мы можем орать «НЕ ГОТОВО!» и кидать тапками в разработчиков. Как только они всё починили (или спихнули в бэклог со статусом «пофиксим потом»), можно выдыхать. 95% High-багов починено? Отлично, оставшиеся 5% — это «особенности реализации», ебать их в сраку. -
Стабильность системы. То есть после всех наших тестов система не падает каждые пять минут, данные не исчезают в никуда, а главный экран не показывает «Hello, World!». Если так — уже хорошо. Готова к релизу? Ну, готова в том смысле, что падать будет, но не сразу и не везде. Приемлемый риск, ёбушки-воробушки.
-
Ресурсы исчерпаны. Самый честный критерий. Кончились деньги, время или терпение у заказчика. Всё, пиздец, пора закругляться. Если другие цели не достигнуты — начинается цирк с пересмотром сроков или, что чаще, с понижением планки качества. «Ладно, этот баг в статистике — пофиг, пользователь не заметит».
Вот тебе пример, как это выглядит в бумажке, чтобы отмазаться:
- Выполнено 100% тест-кейсов с приоритетом P1 и P2. (А про P3-P100 скромно умолчим)
- Открыто 0 дефектов с severity Critical или Blocker. (Их либо пофиксили, либо перевели в Major, хитрая жопа!)
- 95% дефектов с severity High исправлены и верифицированы. (Остальные — «не воспроизводится» или «так и задумано»)
- Покрытие кода unit-тестами достигло 80%. (Это разработчики сами написали, мы им верим. Ну почти.)И главное, что всем надо понять: завершение тестирования — это не волшебная палочка, которая делает продукт идеальным. Это просто формальный пинок под жопу для менеджмента, чтобы они сказали: «Окей, риски просчитаны, пиздуем в релиз. А там — как бог даст».