Когда надо заканчивать тестирование
Что проверяют
Понимаете ли вы, что протестировать всё невозможно, поэтому окончание тестирования определяют заранее оговорённые критерии и принятый риск, а не ощущение «вроде всё». Следом обычно спрашивают, кто решает судьбу релиза, если критерии не выполнены, а дедлайн уже наступил.
Как отвечать
Опирайтесь на критерии выхода (exit criteria), которые фиксируют в тест-плане или в definition of done ещё до начала работ:
- выполнение запланированного: пройдены тесты по приоритетным требованиям и рискам, результаты записаны в TMS (Test IT, Qase, Allure TestOps или аналог);
- покрытие: требования и критичные пользовательские сценарии покрыты, дыры в покрытии названы явно;
- состояние дефектов: нет открытых blocker и critical, по остальным есть решение «исправляем» или «выпускаем с известной проблемой»;
- тренд: новые серьёзные баги перестали находиться, регрессия на релиз-кандидате зелёная;
- ресурсы: время и бюджет. Это законный критерий, если риски непроверенного описаны.
Главное, что стоит сказать: QA не решает «выпускать или нет» в одиночку. Ваша работа дать команде и владельцу продукта картину: что проверено, что нет, какие дефекты открыты и чем они грозят. Итог оформляется отчётом о тестировании, а решение о релизе принимают вместе.
Хорошо добавить, что после релиза проверка не заканчивается: смоук на проде, мониторинг ошибок и метрик, фича-флаги и постепенная раскатка ловят то, что не воспроизвелось на стенде.
Где спотыкаются
Отвечают «когда все баги найдены». Это противоречит базовому принципу тестирования: тесты показывают наличие дефектов, а не их отсутствие.
Называют критерием «все тесты зелёные». Сто процентов прохождения не обязательны: релиз с известным минорным дефектом и описанным обходом нормален, а зелёный прогон по устаревшим кейсам ничего не гарантирует.
Не упоминают, что критерии договариваются до старта. Если их придумывают в день релиза, окончание тестирования превращается в торг, и крайним остаётся тестировщик.