Всем привет, меня зовут Сергей Прощаев, и в этой статье я расскажу про метрики дефектов: почему цифры, которые должны показывать качество продукта, чаще всего показывают что угодно, кроме него. Руковожу направлением Java | Kotlin разработки в FinTech & E-commerce и преподаю на курсах разработки и архитектуры в ОТУС.
Я не QA по специальности. Но за годы в FinTech насмотрелся, как руководители команд тестирования принимают решения по метрикам — и как эти метрики их подводят. Backend, на котором висят деньги, штука нервная: каждый дефект на проде стоит не «переоткрыть тикет», а вполне измеримых денег и пары седых волос у дежурного.
Картина, которую я видел не раз. Команда отчиталась: за квартал число багов упало на треть, дашборд зелёный, на ретро всех хвалят. А через две недели прод ловит инцидент на ровном месте. Метрика улучшилась, качество — нет. Вот что я понял за такими историями: самая опасная метрика в управлении дефектами — «количество багов». Не потому, что бесполезна, а потому, что выглядит объективной. На неё легко повесить цель, под неё легко выдать премию, по ней легко отчитаться наверх. А дальше начинается то, ради чего я и сел писать этот текст.
О чём речь и кому будет полезно
Сразу уточню рамку, чтобы снять вопрос у дотошного читателя. Под «анти-паттернами управления дефектами» дальше я понимаю ошибки использования метрик, на основании которых принимаются управленческие решения. Это не весь defect management как процесс — это та его часть, где руководитель смотрит на цифры и делает выводы. Именно здесь, по моему опыту, ломается больше всего.
Разберём шесть таких анти-паттернов — они чаще всего прячутся ровно до того момента, когда метрика уже всех обманула. Для каждого: симптом, причина, последствия и как выбираться; в конце — сводная таблица и схема. Это не теория из учебника, а набор граблей, на которые я смотрел вблизи. Если вы QA Lead, тимлид или просто человек, которого однажды попросили «сделать так, чтобы багов было меньше», пару пунктов вы наверняка узнаете.
Маленькая история про то, как всё ломается
Один пример, который хорошо объясняет механику. Мне как-то попалась заметка инженера Microsoft Реймонда Чена (ведёт блог The Old New Thing про кухню разработки Windows). Он рассказывал, как в порядке эксперимента какое-то время платил тестировщику из своего кармана за каждый найденный в его коде дефект — чтобы мотивировать искать баги. И сам же разбирал, как это искажает стимулы: возник риск, что он начнёт закрывать баги как INVALID или WONTFIX, лишь бы не платить штраф.
Спас только присмотр: тестировщик видел резолюции и мог переоткрыть тикет, если закрытие было липовым. А без присмотра получается классика — история про «write me a minivan» по старому комиксу Dilbert: менеджер объявил премию за каждый исправленный баг, и программист Уолли радостно пошёл «писать себе новый минивэн», то есть сначала наплодить багов, потом героически их чинить за деньги. Шутка-то шутка, но за ней реальный экономический механизм.
Экономисты называют это законом Гудхарта: когда мера становится целью, она перестаёт быть хорошей мерой. Рядом «эффект кобры»: в колониальной Индии за убитых змей назначили награду, местные начали разводить кобр ради выплат, программу закрыли, змей выпустили — и популяция выросла. Хотели меньше кобр, получили больше. С багами ровно то же: как только «количество дефектов» становится целью, команда без всякого злого умысла, просто следуя стимулам, начинает оптимизировать цифру, а не качество.
Ниже на рисунке 2 — та самая порочная петля: цель «снизить число багов» по кругу возвращается к росту дефектов на проде.
Главная мысль этой схемы простая: цифра пошла вниз, а качество — нет. Петля замыкается, потому что давление идёт на метрику, а не на причину дефектов. Пока вы смотрите только на одно число, вы не отличите настоящее улучшение от того, что команда просто перестала вам показывать баги. Дальше — конкретные формы, в которых эта петля проявляется.
Ошибка 1. Bug count как KPI отдельного человека
Симптом. В команде есть негласный или гласный показатель: сколько багов нашёл тестировщик, сколько закрыл разработчик. Эти цифры всплывают на перформанс-ревью, по ним сравнивают людей, иногда к ним привязана премия.
Почему так делают. Это самая доступная цифра в трекере — Jira покажет её сама. Руководителю хочется объективности, а тут вот же она, в готовом виде.
Что ломает. Как только число багов становится личным KPI, оно начинает жить своей жизнью. Тестировщик, которого оценивают по числу заведённых дефектов, заводит три тикета там, где хватило бы одного. Разработчик, которого оценивают по числу закрытых, спорит по каждому багу, закрывая его как «не воспроизводится». Между QA и разработкой вырастает стена: одни мотивированы находить, другие — отрицать. Помню команду, где половина стендапа уходила на споры, баг это или фича.
Как исправить. Количество дефектов — характеристика продукта и процесса, а не человека. Как диагностика процесса оно полезно (где растёт приток багов, какой модуль фонит), но в роли персонального KPI плохо. Я бы вообще убрал bug count из персональной оценки. Оценивать стоит командный результат: насколько мало дефектов утекает к пользователю, насколько быстро команда реагирует на критичное. Привязали число багов к зарплате человека — купили кобру.
Ошибка 2. «Багов стало меньше» читается как «качество выросло»
Симптом. На ретро звучит: в этом спринте багов меньше, чем в прошлом, — значит, стали лучше работать. Все кивают, никто не спрашивает, почему меньше.
Почему так делают. Это интуитивно: меньше багов — звучит как хорошая новость, и связь «меньше дефектов = выше качество» напрашивается сама, хотя её может и не быть.
Что ломает. У снижения числа найденных багов пять типовых причин, и только одна хорошая. Багов меньше, потому что: код стал чище (хорошо); протестировали меньше, не успели (плохо); часть функциональности заморозили (нейтрально); тестировщик в отпуске (никак); перестали заводить мелочь в трекер (очень плохо). По одной цифре вы не отличите первый случай от пятого. А решения принимаете так, будто это всегда первый.
Как исправить. Число найденных багов нельзя читать в отрыве от объёма и глубины тестирования. Минимум рядом — покрытие требований или критичных пользовательских сценариев (не code coverage ради процента, а доля важной функциональности, реально прошедшей проверку). Держится покрытие, а багов меньше — повод осторожно порадоваться. Просело покрытие вместе с числом багов — это не рост качества, а слепая зона. Цифру дефектов всегда читайте в паре с вопросом «а сколько мы вообще смотрели».
Ошибка 3. Абсолютные числа вместо динамики и распределения
Симптом. В отчёте: «в релизе 47 дефектов». Точка. Без сравнения с прошлым релизом, без разбивки по критичности, без указания, в каких модулях они сидят.
Почему так делают. Абсолютное число легко получить и вставить в слайд. Динамику надо строить, распределение — считать, это работа.
Что ломает. 47 дефектов — это много или мало? Без контекста ответа нет. Оговорка про шкалу: дальше P0–P3 — это критичность; в вашей компании она может зваться Severity (Blocker, Critical, Major, Minor) или Priority, суть не меняется — важно лишь, что дефекты неравноценны. Так вот: сорок семь P3-замечаний по верстке в некритичном разделе — одна история. Пять дефектов, но все P0 в платёжном модуле — совсем другая. И escape rate 10% из одних P0 хуже, чем 30% из P3 — severity-распределение надо держать рядом с любой headline-цифрой. Сама по себе цифра 8% мало о чём говорит, а падение с 15% до 8% за три месяца — уже понятная история улучшения.
Как исправить. Я бы никогда не показывал абсолютное число дефектов без двух вещей: тренда (как было в предыдущих релизах) и разбивки по severity и модулям. Покажу на пальцах, как одна и та же «цифра 20» означает противоположное:
Релиз A: 20 дефектов → 2×P0, 3×P1, 15×P3, все P0 в модуле «Платежи» Релиз B: 20 дефектов → 0×P0, 1×P1, 19×P3, равномерно по UI-разделам
Число одинаковое, а решения противоположные: релиз A нельзя выпускать, релиз B можно. И ещё измерение, без которого абсолютное число обманывает, — нормализация: 20 дефектов на 100 story points и 20 на 300 — разные истории, число стоит соотносить с объёмом изменений. Распределение по модулям сразу подсвечивает проблемную зону — видно, какие части продукта пропускают больше всего дефектов. Одна цифра без контекста — не метрика, а украшение отчёта.
Ошибка 4. Среднее время закрытия без разбивки по критичности
Симптом. Команда отслеживает среднее время жизни бага от заведения до закрытия и гордится, когда оно снижается.
Почему так делают. Среднее — простое, привычное, одно число на весь процесс. Кажется, что оно описывает скорость команды.
Что ломает. Среднее усредняет несравнимое. Критичный баг чинится за два часа, сотня мелких висит месяцами — среднее покажет что-то бессмысленное посередине. Хуже того: его можно «улучшить», быстро закрывая мелочь и игнорируя один тяжёлый дефект, который как раз и опасен. Я видел, как команда отчитывалась о снижении среднего времени закрытия, пока в очереди тихо лежал P1, до которого никто не доходил — он «портил статистику».
Как исправить. Любое время — закрытия, реакции, обнаружения — режьте по severity. И инженерная деталь: распределение времени жизни дефектов почти всегда длиннохвостое, поэтому медиана и перцентили (P90) информативнее среднего — среднее тащит вверх горстка зависших тяжёлых багов. Добавлю и две метрики, которые в эксплуатации значат больше: MTTD и MTTR — время обнаружения и восстановления. Для критичных систем именно связка escape rate, severity-распределения, defect containment и MTTD/MTTR показывает, где реально дыры. Среднее по всем багам сразу — метрика, которой удобно отчитываться и невозможно управлять.
Ошибка 5. Метрики без привязки к этапу, на котором ловится дефект
Симптом. Все найденные дефекты валятся в одну кучу. Неважно, поймали баг на unit-тестах, на интеграции, на staging или его принёс пользователь из прода — в отчёте это просто «дефект».
Почему так делают. Так проще считать: один счётчик вместо четырёх. Точку перехвата надо проставлять руками или настраивать в трекере, а это дисциплина.
Что ломает. Дефект, пойманный на unit-тестах, и дефект, найденный пользователем на проде, отличаются по стоимости на порядки. Первый — рабочий момент, второй — деньги, репутация и ночной звонок. Не разделяете их — теряете самый важный сигнал: где рвётся сеть тестирования. Эта метрика называется defect containment (встречается и как phase containment effectiveness) — насколько эффективно каждый этап удерживает дефекты. Вместе с severity-распределением она показывает, где качество проседает.
Как исправить. Простое правило, которое я бы внедрил первым: каждый дефект при заведении помечается местом, где его поймали — unit-тесты, интеграционные, системное тестирование, staging, production (да, это смесь уровней тестирования и окружений — для отчёта по containment важна сама точка перехвата). Дальше смотрите на тренд: всё больше дефектов ловится поздно, ближе к проду, — ранняя сеть рвётся, чините процесс. И нюанс 2026 года, который я бы не подавал как факт: по наблюдениям ряда команд, активно использующих AI-ассистентов вроде Copilot или Cursor, дефекты кучнее садятся на стыках интеграций и в edge-кейсах, где у модели не было контекста. Исследований пока мало, но если AI-кодинг в команде стал нормой, за этим распределением стоит присматривать.
Ошибка 6. Reopen rate прячут переоткрытием в новой задаче
Симптом. Баг «закрыт», но проблема осталась. И вместо того чтобы переоткрыть старый тикет, заводят новый — формально свежий дефект. Старый числится исправленным, метрика довольна.
Почему так делают. Если reopen rate стал метрикой оценки разработки, переоткрытый баг «портит» статистику. Проще завести новый тикет — старый останется красиво закрытым.
Что ломает. Reopen rate — индикатор качества фиксов: доля дефектов, помеченных исправленными, но затем переоткрытых из-за неполного фикса или возврата дефекта. Когда команда обходит его, заводя новые тикеты, вы теряете способность видеть, что чините симптом, а не причину. Один баг всплывает под тремя номерами и выглядит как три разных дефекта. Это прямой наследник первой ошибки: как только reopen rate стал целью, он перестал быть мерой — снова Гудхарт.
Как исправить. Reopen rate полезен, только пока он диагностический, а не оценочный. Я бы держал его как сигнал для самой команды («что-то часто возвращаемся к этим фиксам»), но не вешал бы на него премию. И правило по root cause: причина та же — переоткрываем старый тикет; симптом тот же, но root cause другой (через полгода всплыла новая причина) — это честный новый тикет, а не обход метрики.
Что со всем этим делать: метрики как система, а не как одна цифра
Общий вывод из шести ошибок: ни одна метрика дефектов не работает в одиночку — любое одно число обходится ровно в тот момент, когда становится целью. Лекарство не в поиске одной «правильной» метрики, а в системе из нескольких связанных, читаемых вместе с контекстом. Лучшие команды на середину 2026 года строят это так. Сырые данные о каждом дефекте размечаются по осям: severity, этап обнаружения, модуль, факт переоткрытия. На них считается связка: escape rate с весом по severity, эффективность поимки (DRE или DDP), defect containment и reopen rate. И только из неё руководитель делает выводы — где слабое покрытие, какие модули рискованные, куда направить силы. Посмотрите на рисунке 3, как данные превращаются в решение.
Главная мысль схемы: метрика — это не цифра в отчёте, а маршрут от факта к действию. Не помогает ответить «что мне с этим делать» — украшение. Помогает — инструмент. И ещё: пять понятных метрик, которые команда реально понимает, бьют двадцать, которые никто не читает. Гонитесь не за числом показателей, а за тем, чтобы каждый было невозможно обойти, не улучшив продукт.
Чтобы было предметно, вот как считаются три метрики минимального набора — суть в формулах.
# Defect Escape Rate. Важно: единого определения нет. # Распространённые варианты: # (1) production / (production + pre-release defects) # (2) production / all detected defects # Ниже — вариант (2), взвешенный по severity. В своей команде # зафиксируйте одно определение и не меняйте его между релизами. severity_weight = {"P0": 8, "P1": 4, "P2": 2, "P3": 1} escaped_weighted = sum(severity_weight[d.severity] for d in defects if d.found_stage == "production") total_weighted = sum(severity_weight[d.severity] for d in defects) severity_weighted_escape_rate = escaped_weighted / total_weighted * 100 # 10% из одних P0 даст совсем другую цифру, чем 30% из P3 — # именно этого мы и добиваемся # Defect Removal Efficiency: какую долю дефектов поймали до прода removed_before_prod = len([d for d in defects if d.found_stage != "production"]) escaped_to_prod = len([d for d in defects if d.found_stage == "production"]) dre = removed_before_prod / (removed_before_prod + escaped_to_prod) * 100 # Зрелые процессы часто держат DRE выше 90%, но универсального # порога нет: в embedded, medical, avionics, банках планка своя # Defect Containment: на каком этапе ловим дефекты from collections import Counter containment = Counter(d.found_stage for d in defects) # если доля 'production' и 'staging' растёт от релиза к релизу — # ранняя сеть тестирования рвётся, чините процесс, а не цифру
Про ограничения, потому что серебряной пули нет. Веса severity субъективны — калибруйте под продукт: для платёжного сервиса и для внутренней админки они разные. DRE требует честной разметки этапа обнаружения, а это дисциплина. Могу представить, как кто-то внедрит весь набор и упрётся в то, что данные размечают спустя рукава — тогда и связка поедет. Так что начинать я бы советовал не с дашборда, а с дисциплины заведения дефектов.
Сводная таблица: ошибка → признак → что проверить
Анти-паттерн | По какому признаку узнать | Что проверить у себя |
|---|---|---|
Bug count как личный KPI | Число багов попадает в перформанс-ревью, к нему привязана премия | Влияет ли количество дефектов на оценку конкретного человека |
«Меньше багов = выше качество» | На ретро радуются снижению, не спрашивая о причине | Держится ли покрытие тестами рядом со снижением числа дефектов |
Абсолютные числа без контекста | В отчёте голая цифра без тренда и severity | Есть ли разбивка по критичности и по модулям, есть ли сравнение с прошлым |
Среднее время без severity | Одно среднее время закрытия на все баги | Разрезано ли время реакции и закрытия по P0–P3 |
Дефекты без этапа обнаружения | Все баги в одной куче, неважно где пойманы | Проставляется ли точка перехвата (unit / integration / system / staging / prod) |
Обход reopen rate | Вместо переоткрытия заводят новый тикет | Возвращается ли та же проблема в тот же тикет, не плодятся ли дубли |
Какой навык на самом деле проверяет эта группа ошибок
Если присмотреться, все шесть ошибок об одном. Они проверяют не знание формул, а зрелость мышления руководителя: способность не доверять цифре только за то, что она цифра. Хороший QA Lead смотрит на метрику и сразу спрашивает — а как её обойти, не улучшив продукт? Если ответ «легко», метрику нельзя ставить целью. Это и есть навык, отделяющий управление качеством от управления отчётностью.
Чтобы это не осталось абстракцией — мой практический минимум для зрелой команды:
Escape Rate (взвешенный по severity) — сколько и какого качества дефектов утекло к пользователю.
Severity Distribution — как распределены по критичности; без этого Escape Rate обманывает.
DRE — какую долю ловим до прода.
MTTR — как быстро восстанавливаемся после инцидента.
Reopen Rate — насколько качественные фиксы.
Если урезать до трёх — Escape Rate, Severity Distribution, DRE: видно и сколько дефектов уходит в прод, и насколько они опасны, и где рвётся сеть тестирования. Остальное — уточнения поверх.
Метрики дефектов — мощный инструмент, когда вы понимаете их пределы. Они показывают реальное состояние продукта, помогают найти проблемные зоны и принимать решения на данных, а не на ощущениях. Но ровно до того момента, пока вы не превратили одну из них в самоцель. Дальше начинается кобра.
Тема с метриками дефектов редко упирается только в формулы: важнее понять, какие решения команда принимает на их основе и где цифры начинают обманывать.
7 июля в 19:00 на бесплатном уроке курса «Руководитель группы тестирования (QA Lead)» будет разбор, как читать баги, оценивать динамику и распределение дефектов, находить проблемные зоны в процессах и не делать выводы по одной красивой цифре. Заодно можно будет посмотреть на формат обучения и задать вопросы преподавателям. Записаться на урок.
