При завершении спринта критерии выхода тестирования выполнены не полностью: почему нельзя считать тестирование завершённым только по истечении запланированного срока?
Истечение срока само по себе не доказывает, что тестирование завершено. Решение о завершении принимают по заранее определённым критериям выхода: например, по достаточному покрытию рисков, допустимому числу открытых дефектов и выполнению обязательных проверок. Если критерии не выполнены, команда должна явно принять риск переноса или выпуска, а не маскировать незавершённость работы календарной датой.
Критерии выхода появились как элемент управляемого тестового процесса. Они решают проблему субъективного решения «проверили достаточно», особенно когда сроки ограничены, а объём возможных проверок велик.
Такой подход отделяет факт окончания запланированного времени от фактической готовности продукта. Он также делает решение проверяемым: можно сравнить достигнутые результаты с условиями, согласованными до начала тестирования.
Если тестирование автоматически прекращают по сроку, непроверенные риски могут попасть в релиз. Например, обязательный сценарий оплаты может быть не выполнен, а критический дефект может оставаться открытым только потому, что закончился спринт.
Дополнительная опасность — ложная отчётность. В отчёте появится формулировка «тестирование завершено», хотя фактически завершился лишь выделенный интервал времени. Это затрудняет оценку качества и последующий анализ инцидентов.
Сначала определяют критерии выхода для конкретного объёма работ. Обычно они включают выполнение обязательных тестов, покрытие приоритетных рисков, отсутствие блокирующих дефектов и согласованные ограничения по оставшимся проблемам.
Затем фактические результаты сравнивают с этими критериями. Если условия выполнены, тестирование можно считать завершённым в рамках заявленного объёма. Если нет, фиксируют невыполненные пункты, оценивают влияние и передают решение ответственным лицам.
Критерии выхода не гарантируют отсутствия дефектов. Они задают минимально приемлемый уровень свидетельств о качестве и позволяют принимать решение на основе риска, а не впечатления тестировщика.
Критерии должны быть измеримыми и применимыми к задаче. Требование «протестировать хорошо» непригодно, а условие «выполнены все обязательные сценарии оплаты и нет открытых дефектов с блокирующим влиянием» существенно полезнее.
Команда готовит релиз за день до маркетингового запуска. Время полного цикла закончилось, но проверки восстановления после сбоя и часть сценариев оплаты не выполнены.
Вариант «выпустить по сроку» сохраняет дату запуска, но оставляет неизвестными критичные риски. Вариант «перенести релиз без анализа» снижает технический риск, однако может создать существенные бизнес-потери. Вариант «сократить проверки случайным образом» быстрее, но не даёт обоснования того, какие риски приняты.
Рациональное решение — свериться с критериями выхода, явно зафиксировать невыполненные проверки и провести оценку риска. Если обязательные платёжные сценарии входят в критерии и не проверены, релиз блокируют либо выпускают только после формального согласования риска уполномоченным владельцем продукта. Такой подход сохраняет прозрачность и не выдаёт ограничение времени за доказательство готовности.
1. Достаточно ли установить критерии выхода один раз для всего продукта?
Нет. Набор критериев зависит от типа релиза, критичности изменений, регулируемых требований и затронутых областей. Для исправления текста и для изменения механизма платежей нужны разные обязательные проверки и разные допустимые риски.
2. Можно ли считать критерий выхода выполненным, если тесты не запускались, но дефектов пока не обнаружено?
Нет. Отсутствие найденных дефектов без выполнения проверки не является свидетельством корректности. Такой пункт следует отметить как непроверенный, а решение о дальнейшем действии принять через явную оценку риска.
3. Кто должен решать, что невыполненный критерий можно принять?
Это зависит от процесса организации, но решение должно принадлежать роли, отвечающей за соответствующий риск и выпуск продукта, например владельцу продукта совместно с ответственными за качество и разработку. Тестировщик предоставляет факты, ограничения и оценку последствий, но не должен скрыто заменять формальное решение своим молчаливым согласием.