6 ошибок в метриках дефектов, из-за которых QA теряет контроль над качеством

Вот важная новость с фронта ИИ: sproshchaev 4 минуты назад 6 ошибок в метриках дефектов, из-за которых QA теряет контроль над качеством Средний 11 мин 11 Блог компании OTUS Тестирование IT-систем * Управление разработкой * Управление проектами * Карьера в IT-индустрии Туториал Всем привет, меня зовут Сергей Прощаев, и в этой статье я расскажу про метрики дефектов: почему цифры, которые должны показывать качество продукта, чаще всего показывают что угодно, кроме него. Руковожу направлением Java | Kotlin разработки в FinTech & E-commerce и преподаю на курсах разработки и архитектуры в ОТУС. Я не QA по специальности.

Но за годы в FinTech насмотрелся, как руководители команд тестирования принимают решения по метрикам — и как эти метрики их подводят. Backend, на котором висят деньги, штука нервная: каждый дефект на проде стоит не «переоткрыть тикет», а вполне измеримых денег и пары седых волос у дежурного. Картина, которую я видел не раз.

Технические детали

Команда отчиталась: за квартал число багов упало на треть, дашборд зелёный, на ретро всех хвалят. А через две недели прод ловит инцидент на ровном месте. Метрика улучшилась, качество — нет.

Вот что я понял за такими историями: самая опасная метрика в управлении дефектами — «количество багов». Не потому, что бесполезна, а потому, что выглядит объективной. На неё легко повесить цель, под неё легко выдать премию, по ней легко отчитаться наверх.

А дальше начинается то, ради чего я и сел писать этот текст. Метрика горит зелёным, а качество тихо ухудшаетсяО чём речь и кому будет полезноСразу уточню рамку, чтобы снять вопрос у дотошного читателя. Под «анти-паттернами управления дефектами» дальше я понимаю ошибки использования метрик, на основании которых принимаются управленческие решения.

Отраслевые последствия

Это не весь defect management как процесс — это та его часть, где руководитель смотрит на цифры и делает выводы. Именно здесь, по моему опыту, ломается больше всего. Разберём шесть таких анти-паттернов — они чаще всего прячутся ровно до того момента, когда метрика уже всех обманула.

Для каждого: симптом, причина, последствия и как выбираться; в конце — сводная таблица и схема. Это не теория из учебника, а набор граблей, на которые я смотрел вблизи. Если вы QA Lead, тимлид или просто человек, которого однажды попросили «сделать так, чтобы багов было меньше», пару пунктов вы наверняка узнаете.

Маленькая история про то, как всё ломаетсяОдин пример, который хорошо объясняет механику. Мне как-то попалась заметка инженера Microsoft Реймонда Чена (ведёт блог The Old New Thing про кухню разработки Windows). Он рассказывал, как в порядке эксперимента какое-то время платил тестировщику из своего кармана за каждый найденный в его коде дефект — чтобы мотивировать искать баги.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.