214 багов найдено, 209 закрыто. Релиз выкатили в пятницу вечером (классика). В субботу в 6 утра разбудил звонок: у части пользователей двойное списание. А потом всё как в тумане: разговор с заказчиком буквально в пижаме, который срочно хотел знать, как вообще такое оказалось в проде, и 14 часов сверхурочной работы в выходные.

❗️Это не выдуманный кейс. Это история из практики, которая навсегда изменила наш подход к метрикам тестирования.

При этом дело было не в людях. Команда работала хорошо, но была сфокусирована не на том KPI. Подсчёт багов – это измерение активности, а не результата. Всё равно что считать, сколько раз сходил в зал, вместо того чтобы смотреть на изменения качества тела.

Что ещё не так с подсчётом количества багов? Эта цифра не только ничего не говорит о качестве продукта, так ещё и приводит к конфликтам между QA и разработкой.

🤓Чего хочет бизнес на самом деле? Чтобы релизы были предсказуемыми. Чтобы заранее можно было получить информацию о возможных сбоях и ресурсах, которые необходимы для их решения. Не красивый отчёт на 40 страниц, а уверенность в том, что любые ситуации предусмотрены и контролируемы. Поэтому нужно смотреть совсем на другие показатели и уметь оценивать риски.

🔗 Читайте в новой статье, какие метрики мы советуем использовать вместо подсчёта багов. Вы узнаете, как за пару часов собрать риск‑матрицу, во сколько обойдётся внедрение нового подхода и что будет, если продолжать оценивать релизы по‑старому.

📄Бонус: в материале вы найдёте чек‑лист для экспресс‑анализа рисков перед тестированием. Можно скачать бесплатно.

#QAметрики #тестированиеПО #QA #РискОриентированноеТестирование #MTBF #MTTR #УправлениеITрисками #ReleasePredictability #ITкачество #QALead