Как оценить количество найденных багов перед релизом

Что проверяют

Умеете ли вы превратить счётчик в трекере в аргумент для решения о релизе. Голое число багов ничего не значит без контекста, и интервьюер ждёт, что вы это скажете. Следом обычно спрашивают: «багов стало меньше, это код лучше или тестировали хуже?».

Как отвечать

Сначала разложите найденное по срезам:

• критичность и статус: сколько открытых blocker и critical, сколько отложено осознанно с согласия продукта. Типичный критерий выхода: ноль открытых блокеров и критических, остальное разобрано;
• модули: плотность дефектов на фичу или объём изменений показывает горячие точки, где стоит дотестировать;
• динамика: график поступления и закрытия багов по дням. Если новые находки выходят на плато, а закрытие обгоняет поступление, продукт стабилизируется. Если находки растут в последние дни, выпускать рано;
• покрытие: сколько запланированных сценариев пройдено и какие риски не проверены. Мало багов при половине пройденных кейсов означает недотестированность, а не качество.

Затем сравните с историей: сколько находили на похожих по объёму релизах и сколько потом утекло в прод (defect leakage, DRE). Это ориентир, нормально ли текущее число.

Оценить, сколько дефектов ещё не найдено, можно статистикой: две независимые группы тестируют одно и то же, и по пересечению находок оценивают общее число (метод повторного отлова, оценка Линкольна и Петерсена: N ≈ n1 × n2 / m). Упомянуть его стоит, но честно добавить, что на практике опираются на тренды и историю.

Итог оформляется отчётом о готовности: открытые дефекты по критичности, риски, рекомендация. Если такой отчёт вы уже готовили, расскажите, какие цифры в нём были и чем закончилось обсуждение.

Где спотыкаются

Называют голую цифру или «процент багов от числа тестов». Такая метрика ничего не говорит о риске: один блокер важнее сотни опечаток.

Трактуют малое число найденных багов как высокое качество, не проверив покрытие и глубину тестирования.

Берут решение о выпуске на себя. Задача QA дать прозрачную картину рисков, а решение с учётом бизнеса принимает владелец продукта.