Современные метрики тестирования: что важнее количества найденных багов

Как понять, что перед вами хороший тестировщик? Он будет говорить о рисках, а не о багах. В статье рассказываем, какие метрики мы внедрили вместо подсчёта количества багов, как собрать риск‑матрицу за пару часов, сколько это стоит и что будет, если забить и игнорировать новые подходы в тестировании. Читайте о проверенных на практике решениях, которые действительно работают — без претензии на истину в последней инстанции.

Вот история, которая много лет назад навсегда отучила нас гордиться количеством найденных дефектов. Был у нас релиз – чистый, образцовый. За спринт команда тестирования нашла 214 багов, закрыла 209, а пять оставшихся сочла косметическими – решили поправить позже. На ретро все были довольны: менеджер строил график «найдено/исправлено», стрелочка вверх, дофамин рекой. Релиз выкатили в прод в пятницу вечером (да, знаем, знаем, — это же классика).

В субботу в 6 утра раздался звонок: у части пользователей при оплате двойное списание. Не критический сбой, не белый экран, а тихая, незаметная штука, которая ни в один из тех 214 багов не вошла. Но проблема касалась реальных денег.

Мы тогда чинили это 14 часов. И пока в шесть утра приходилось буквально в пижаме объяснять по телефону, почему мы пустили это в прод, стало ясно: нам платят не за найденные баги, а за то, чтобы релиз был качественным и предсказуемым. Оказалось, всё это время мы измеряли не то. Заказчику было всё равно сколько багов удалось найти - его боль была в том, чтобы релиз не был похож на лотерею.

Почему считать баги уже недостаточно?

Сначала разберёмся, почему подсчёт багов — это уже прошлый день. Не потому что баги не важны. А потому что это метрика активности, а не результата. Всё равно что считать, сколько тренировок в месяц вы посетили вместо оценки изменений тела.

Что не так с этой метрикой? Разберёмся по пунктам:

Она ничего не говорит о качестве продукта. 500 багов в спринте – это плохой продукт или хорошая команда тестирования? А 5 багов – это шедевр разработки или просто никто толком не тестировал?
Она прямо вредит, как только становится KPI. Тут работает закон Гудхарта: как только показатель превращается в цель, то он перестаёт быть хорошим показателем. Платите тестировщику за количество багов – получаете больше багов. Каждую опечатку в плейсхолдере оформят отдельным тикетом с тремя скриншотами. А искать причину, по которой баги вообще появляются, никто не станет – это же себя обкрадывать.
Она ссорит команду. Когда для QA главное – найти как можно больше багов, а для разработки – сделать всё побыстрее, они невольно оказываются по разные стороны баррикад. QA заинтересовано в большом числе дефектов, а разработка стремится доказать, что часть из них вовсе не баги. В итоге общая цель – выпустить качественный продукт – отходит на второй план, а вместо совместной работы начинается подсчёт и споры в комментариях к тикетам.

Но главная проблема в другом. Тот релиз с 214 багами провалился не из‑за слабой работы команды. Мы хорошо искали, но пропустили реальный неочевидный риск, который и привёл к проблеме. Подсчёт багов создаёт иллюзию контроля: цифры растут, графики выглядят благополучно, а настоящая угроза остаётся незамеченной – и может напомнить о себе в самый неподходящий момент.

В чём настоящая ценность QA для бизнеса?

Если коротко: зрелое тестирование должно обеспечивать предсказуемость. Чтобы за день до релиза можно было честно сообщить бизнесу: с вероятностью N% релиз пройдёт без серьёзных проблем, а если что‑то и сломается – то вот в этой зоне, при этом восстановление займёт столько-то минут.

Вот это и есть настоящий QA. Не отчёт на 40 страниц о том, что протестировано, а чёткий анализ с пониманием цены и вероятности возможной ошибки. Бизнесу неважно, сколько багов нашли. Ему важно планировать: обещать ли клиенту дату, быть ли уверенным в стабильности, брать ли с собой в отпуск ноутбук? И вот тут на сцену выходят метрики тестирования, которые измеряют именно предсказуемость продуктов, а не демонстрацию активной деятельности.

MTBF и MTTR – две QA-метрики нового поколения

Эти показатели давно используют в эксплуатации оборудования и в SRE, но в продуктовом тестировании, к нашему глубокому сожалению, они приживаются медленно. Сейчас объясним простыми словами, что это такое, как считать и применять.

MTBF (Mean Time Between Failures) – среднее время между сбоями.
Суть: сколько ваша система спокойно работает, прежде чем что-то отвалится.

Считается так:

MTBF = суммарное время нормальной работы /количество сбоев

Например: работали 30 дней, было 3 серьёзных инцидента – MTBF около 10 дней. Это метрика стабильности. Чем она больше, тем реже сбои.

MTTR (Mean Time To Recovery) – среднее время восстановления.
Суть: это метрика устойчивости. Чем она меньше, тем система стабильнее.

Считается так:

MTTR = суммарное время простоя / количество инцидентов

Например: за месяц случилось три инцидента общей продолжительностью 150 минут, поэтому среднее время восстановления (MTTR) составило 50 минут.

Ключевой сдвиг в подходе, который не сразу удаётся принять: полностью исключить сбои невозможно. Сложная система неизбежно будет ломаться – это закономерность, а не признак непрофессионализма.

Настоящая цель – не стремиться к мифическому «нулю багов», а работать над двумя показателями: увеличивать MTBF (чтобы система ломалась реже) и сокращать MTTR (чтобы восстанавливаться быстрее).

Именно на основе этих значений рассчитывают доступность (availability) – ту самую, что закладывают в SLA как «четыре девятки».

Доступность = MTBF / (MTBF + MTTR)

Почувствуйте разницу. Фраза «нашли 214 багов» говорит о прошлом и отражает сам процесс работы. А показатели «MTBF вырос с 6 до 19 дней, MTTR сократился с 4 часов до 35 минут» показывают реальный результат и дают представление о будущем. Первые цифры уместно обсуждать внутри команды, вторые – спокойно представлять совету директоров.

Важное уточнение: без нормального мониторинга прода и чёткого учёта инцидентов посчитать MTBF и MTTR не получится. Поэтому первый шаг к предсказуемости – начать фиксировать данные. Об этом расскажем дальше.

Риск-ориентированное тестирование: как выпускать релизы без лишних затрат?

Почем тестировать всё подряд — это плохая идея? Если пытаться одинаково тщательно проверять всё, то проект либо станет слишком дорогим, либо релиз никогда не выйдет в прод.

Предсказуемость достигается не за счёт тестирования всего подряд, а благодаря фокусу на самом важном – и ровно в той степени, в какой это действительно нужно. В этом и суть риск‑ориентированного подхода. Его формула проста до неприличия:

Риск = Вероятность сбоя × Влияние сбоя

Дальше берём все наши функции/модули/сценарии и раскидываем по матрице.

Вот рабочая риск-матрица, которую мы используем (5×5 многим избыточна, начните с 3×3):

	Влияние низкое	Влияние среднее	Влияние высокое
Вероятность высокая	Средний риск	Высокий	Критический
Вероятность средняя	Низкий	Средний	Высокий
Вероятность низкая	Низкий	Низкий	Средний

Как пользоваться матрицей:

Критический и высокий it-риски – оплата, авторизация, целостность данных: всё, где возможна утечка денег или персональных данных, – требуют максимального внимания. Сюда направляем основные усилия: автотесты, ручную проверку, негативные сценарии, нагрузочное тестирование, контроль на проде после релиза. Именно в этой зоне случился тот самый случай с двойным списанием – мы его не заметили, потому что ориентировались на количество багов.
Средний риск – проверяем разумно, без фанатизма.
Низкий риск – вопросы вроде настроек цвета кнопки в профиле – допускают отдельные недочёты: их наличие не несёт серьёзных последствий, и можно сознательно экономить на них ресурсы.

Что вы получаете на выходе:

Чёткое понимание рисков релиза
Аргумент для бизнеса: «вот этот модуль мы покрываем на 95%, а вот этот – на 40%, потому что цена ошибки тут копеечная». Это взрослый разговор.
Защиту от неэффективного расходования ресурсов на проекте.

Практический совет: формируйте риск‑матрицу совместно с разработкой, продактом и поддержкой – не в одиночку. Поддержка особенно ценна: её сотрудники лучше всех знают реальные проблемы пользователей. Всего час такой встречи раз в квартал помогает сэкономить недели на устранении инцидентов.

Какие ещё показатели помогают в управлении IT-рисками?

Окей, баги считать перестали. Что вешаем на дашборд вместо них? Предлагаем набор метрик, которые можно внедрить уже завтра.

Defect Escape Rate, доля «сбежавших» дефектов. Она показывает соотношение багов, найденных до продакшена, к тем, что всё‑таки попали в прод.

Escape Rate = баги, найденные в проде / (баги в проде + баги до прода)

Это самая честная оценка качества тестирования – не сколько багов нашли, а сколько проворонили. Например, 214 багов до релиза и один в проде – это отличная работа. А вот 12 багов до релиза и 8 в проде – явный пробел в покрытии, сколько бы дефектов ни выявили. Стремитесь держать Defect Escape Rate на уровне ниже 5–10% – дальше ориентируйтесь по особенностям проекта.

MTBF / MTTR – про них уже писали выше. Это база.
Change Failure Rate – доля провальных изменений: она показывает, какой процент релизов приводит к инциденту, откату или хотфиксу. Эта метрика из исследования DORA прямо отвечает на вопрос, насколько предсказуем релиз. У сильных команд показатель держится на уровне единиц процентов, у команд в постоянном аврале – превышает 30%.
MTTD (Mean Time To Detect) – это время, за которое команда замечает, что система сломалась. Бывает, что MTTR отличный, но проблема в другом: о сбое узнают от недовольных пользователей в соцсетях спустя два дня. Если вы узнаёте о проблеме последним – быстрое исправление уже не спасает ситуацию.
Покрытие рисков важнее покрытия строк кода. Code coverage в процентах нередко вводит в заблуждение: можно иметь 90% покрытия и при этом тестировать то, что не влияет на стабильность системы. Гораздо полезнее отслеживать, какая доля критических сценариев из риск‑матрицы покрыта тестами. Именно этот показатель помогает в управлении IT-рисками , а не показывает формальные проценты.
Доля флакающих тестов – важный показатель. Тесты, которые то падают, то проходят, опаснее, чем полное их отсутствие: они притупляют бдительность команды и приучают игнорировать предупреждения. Держите их под контролем – иначе дашборд перестанет быть инструментом управления и станет просто пустышкой.

Обратите внимание: все эти метрики отражают результат для пользователя и бизнеса, а не активность команды. Их не получится «накрутить», например, оформив опечатку как отдельный тикет.

Пошаговый план перехода к риск-ориентированному тестированию

Мы собрали набор практик, которые доказали свою эффективность. Это не план на неделю – это маршрут на несколько кварталов, позволяющий внедрить риск ориентированный подход в тестировании. При этом каждый шаг приносит пользу сразу, поэтому внедряйте их по очереди.

Начните с измерения состояния прода. Без мониторинга и учёта инцидентов MTBF и MTTR – просто красивые термины, а не рабочие метрики. Заведите простой журнал инцидентов: фиксируйте, что случилось, когда, сколько времени ушло на исправление и как проблему обнаружили. Это не требует затрат, но сразу даёт чёткую картину.
Соберите риск‑матрицу – на это хватит одного вечера, а польза сохранится на месяцы.
Сосредоточьте усилия на зонах высокого риска: вместо тотальной автоматизации сначала закройте автотестами критически важные участки – например, оплату и авторизацию.
Введите блеймлесс-постмортемы. Внедрите разбор инцидентов без поиска виноватых. Пусть каждый такой разбор порождает новый тест‑кейс или проверку – так MTBF будет расти естественным образом.
Сдвигайте тестирование влево (shift-left). чем раньше выявлен дефект, тем дешевле его исправить. Привлекайте QA ещё на стадии обсуждения требований – многие проблемы возникают не из‑за кода, а из‑за расплывчатых формулировок.
Создайте дашборд здоровья релиза с 5–6 ключевыми метриками и разместите его на видном месте. Когда команда ежедневно видит показатели вроде Defect Escape Rate и Change Failure Rate, подход к работе меняется сам собой.
Заранее согласуйте SLO и бюджет ошибок: определите, какой уровень сбоев допустим. Это снимет невроз с ориентацией на «ноль багов» и переведёт разговор в плоскость «у нас бюджет на N минут простоя в месяц, тратим его осознанно».

Хотите узнать, как оценить риски перед тестированием за 15 минут? Забирайте чек-лист для экспресс-анализа бесплатно. Используйте, когда времени в обрез. Заполните форму и мы отправим документ вам на электронную почту.

Получить чек-лист

Во сколько обойдётся такой подход?

Честно говоря, такие меры требуют вложений – но они окупаются. Возьмём известное правило «1–10–100»: дефект, выявленный на этапе требований, условно стоит 1 единицу, в коде – уже 10, а в проде – от 100 и выше. И это без учёта репутации, возвратов, срочных ночных работ и выгорания команды – а эти потери тоже дорого обходятся, хоть их и трудно посчитать.

Посчитайте стоимость одного серьёзного инцидента: 
простой сервиса помножить на выручку в час + затраты на устранение (время команды и ставки) + потерянные клиенты и нагрузка на поддержку.

Для среднего бизнеса это нередко выливается в сотни тысяч или даже миллионы рублей. Например, инцидент с двойным списанием – с учётом возвратов, ручного разбора транзакций и 14 человеко‑часов в выходные – обошёлся примерно в две месячные зарплаты тестировщика.

При этом вложения в предсказуемость в основном разовые: настроить метрики эффективности тестирования, сформировать риск‑матрицу, скорректировать процессы, обучить команду. Дальше система работает сама и экономит ресурсы с каждым новым релизом. По опыту, грамотно выстроенный риск‑ориентированный QA окупает затраты за счёт одного‑двух предотвращённых инцидентов – то есть примерно за квартал.

А что если забить и считать баги дальше?

Имеете полное право. Только давайте честно про то, что вас ждёт.

Релизы будут непредсказуемыми. Когда повезёт, когда нет. Вы никогда не будете знать заранее, что вас ждёт и не сможете ничего планировать в таких условиях.
Команду настигнет неумолимое выгорание. Постоянные стрессы, конфликты, переработки. Лучшие уйдут первыми – никто не любит героически чинить то, что можно было предотвратить.
QA и разработка будут постоянно конфликтовать. KPI по количеству багов противопоставляет их по самой своей природе.
Деньги будут утекать незаметно тонкой струйкой: возвраты, отток клиентов, ухудшение репутации, упущенные возможности. В отчётах вы этого не увидите, потому что продолжите измерять не то, что нужно.
И главное – вы продолжите гордиться не тем. Графиком найденных багов вместо растущего MTBF. Вредно, обманчиво, ведёт в тупик из иллюзий.
Самое коварное – что по старым метрикам всё будет выглядеть отлично ровно до того момента, пока не станет слишком поздно.

Когда стоит обратиться к нам?

Мы в «Лаборатории Качества» не изобретаем велосипед, а берём проверенные практики и системно внедряем их, выжимая максимум пользы для клиентов. Наша помощь обычно сводится к трём ключевым шагам – это как раз та разовая инвестиция, которая быстро окупается:

проводим аудит текущего QA: разбираем, как устроено тестирование, где кроются главные риски, какие дефекты попадают в прод и почему. Даём не формальный отчёт, а реальную картину состояния дел;
помогаем перейти на осмысленные метрики: вместо простого подсчёта багов внедряем MTBF, MTTR, Defect Escape Rate, Change Failure Rate, выстраиваем риск‑матрицу и собираем понятный дашборд – такой, который не стыдно показать руководству;
обучаем вашу команду: чтобы после завершения проекта процессы продолжали жить и развиваться внутри компании. Наша цель – не сделать вас зависимыми от подрядчика, а научить команду мыслить категориями рисков и предсказуемости.

Если этот подход вам близок – запишитесь на бесплатную стратегическую консультацию. Разберём текущий процесс тестирования и метрики, подсветим зоны высоких рисков и подскажем, с каких шагов начать, чтобы уже в ближайший квартал снизить количество инцидентов и сделать релизы предсказуемыми.

Проконсультироваться