Ответ
Критерии выхода — это измеримые условия завершения тестирования. Основные из них:
- Покрытие требований: Все ключевые функциональные и нефункциональные требования проверены (например, достигнуто 100% покрытия).
- Прохождение тестов: Выполнена запланированная доля тест-кейсов с допустимым процентом успешных проходов (например, ≥95%).
- Качество дефектов: Критичные (Critical/Blocker) и высокоприоритетные (High/Major) баги исправлены. Количество открытых дефектов низких уровней не превышает установленного лимита.
- Стабильность системы: В ходе нагрузочного тестирования или в течение заданного времени не происходит критических сбоев.
- Достижение метрик качества: Выполнены целевые показатели производительности, безопасности, удобства использования.
Пример формулировки в тест-плане:
Exit Criteria:
- 100% прохождение smoke-тестов.
- 0 открытых дефектов с приоритетом Critical или High.
- Покрытие кода тестами ≥ 80%.
- Среднее время отклика ключевых API < 200 мс.Ответ 18+ 🔞
А, ну это ж классика, блядь! Критерии выхода! Это когда уже настолько всё заебало, что хочется крикнуть «да похуй, выпускайте эту хуйню в прод, я больше не могу!», но нельзя, потому что потом тебя же и спросят, какого хуя.
Так вот, чтобы не быть крайним, нужно заранее договориться, когда можно будет свалить с этого цирка. Это и есть критерии, ёпта.
Первое, и самое главное — покрытие требований.
То есть, если в техзадании было «кнопка должна быть зелёной и издавать звук „буп“», то ты эту кнопку нашёл, нажал, она позеленела и сказала «буп». И так со всеми пунктами, блядь. В идеале — все сто процентов. Если какой-то пункт «в рот меня чих-пых» оказался нереализуемым, это должно быть оговорено и утверждено ещё вчера. Иначе потом прилетит: «а мы думали, вы сами догадаетесь!».
Второе — прохождение тестов.
Ты написал кучу тест-кейсов, половина из которых — полная хуйня, но начальству нравится, когда много. Так вот, нужно, чтобы большая часть этой хуйни (допустим, 95%) прошла успешно. Остальные 5% — это обычно какие-нибудь ебушки-воробушки вроде «система должна корректно работать при одновременном входе миллиона пользователей под одним логином». Ну, да похуй, закроем баг-репортом «не воспроизводится в реальных условиях».
Третье — качество дефектов.
Это святое, блядь. Критические баги (которые всё ломают) и высокоприоритетные (которые сильно бесят) — должны быть все пофикшены. Ноль. Ни одного. Иначе выпустишь продукт, а он, сука, на первом же экране у клиента накроется медным тазом. А вот мелкие косяки, вроде «отступ на два пикселя не по макету» — их можно оставить пачку, лимит установить. Иначе никогда не выпустим, будем год пиксели двигать.
Четвёртое — стабильность системы.
Это когда ты нагружаешь её, как последнюю суку, а она не падает. Не должно быть таких ситуаций, что десять человек зашли — всё ок, а двадцать — и сервак, блядь, лег с сообщением «пиздец». Надо, чтобы она держалась под планируемой нагрузкой хотя бы какое-то время без критических пиздюлей.
Пятое — достижение метрик качества.
Тут всё просто: договариваемся на берегу, какие цифры нас устроят. Скорость отклика, количество поддерживаемых пользователей, покрытие кода тестами (этот пункт все любят, но нихуя не понимают). Главное — чтобы были конкретные числа, а не «ну должно быстро работать».
А вот, смотри, как это обычно в плане пишут, чтоб начальство прониклось:
Exit Criteria:
- 100% прохождение smoke-тестов. (То есть самое основное не разваливается сразу)
- 0 открытых дефектов с приоритетом Critical или High. (Ничего смертельного)
- Покрытие кода тестами ≥ 80%. (Цифра красивая, всем нравится)
- Среднее время отклика ключевых API < 200 мс. (Чтобы пользователи не успели посрать в чат поддержки)Вот когда всё это выполнено — можно смело говорить: «Всё, ребята, я сделал всё, что мог. Дальше — ваши проблемы. Я пошёл». И это, блядь, будет красиво и профессионально.