Тут недавно просили поделиться инфой по метрикам.
Описываю только те метрики, которые собирал сам на практике.
Текста будет много, да и метрик тоже. Поэтому...
Часть 1.
Метрики с участием багов:
1) Открытые/закрытые баги (Open/Closed Bugs).
Считается просто, лучше считать большими диапазонами, от спринта и выше(месяц, квартал) , в зависимости от процесса работы на проекте.
С одной стороны показывает темп работы команды. Ну как команды?! Типа тестировщики открыли, а девелоперы реально пофиксили(хотя мы, конечно, перепроверили). Ну и куча других людей может быть вовлечено в зависимости от содержимого. С другой стороны является хорошим маркером для определения растущего технического долга (Technical Debt), когда мы делаем кучу нового, но и ничего не фиксим в противовес. Для некоторых этапов разработки - это нормально, но все равно полезно.
Также, хочу отметить, что я использую именно статус Closed для этой метрики, потому как плохо настроенный трекер задач, где нет других статусов может очень сильно вводить погрешность в эту метрику, когда баги по итогу оказываются отмененными (Cancelled), или настолько не существенными, что фиксить их никто и не собирается (Rejected, Won't fix, etc.).
2) Количество отмененных дефектов (Canceled bugs).
Иногда собирают рейт (Cancellation rate) по отношению к открытым или собирают обе метрики.
По сути это цифра отображает количество багов признанных избыточными или несущественными, а высокий уровень этой метрики покажет нам то, что есть проблемы в процессе работы, например слабая техническая документация или бизнес требования, проблемы коммуникации, недостаток знаний у тестировщиков или техподдержки.
3) Рейт дефектов на продакшене (Defect Containment Rate).
Одна из самых крутых метрик при регулярных релизах в рамках Скрамов (Scrum), хотя подходит и для других вариантов Agile процессов. Считаем ее, как отношение багов на проде ко всем найденным багам вообще. Чем ниже, тем, соответственно, лучше! Кстати можно считать его не только к продакшену, но и например к UAT, если у вас построен полноценный процесс для этой фазы, а не "просто так называется энвайромент" для тестировщиков или препродакшена.
По факту показывает насколько мы "лоханулись", что может говорить о проблемах с регрессией или покрытием тестами. Хотя тоже бывают и "лишние волнения", когда например продакшен имеет очень специфическую конфигурацию, тогда может быть открыто много дефектов в разных местах на проде, а по сути все может свестись к неверной настройке в одном единственном месте, так что будте осторожны и не вводите себя в заблуждение.
4) Количество дубликатов (Duplicated Bugs).
Вынес эту метрику отдельно от Сancelled потому, что дубликаты показывают рассинхрон именно в QA команде(если кроме вас баги никто не открывает), особенно, актуально для распределенных больших команд, которые могут работать над одним "монолитом" (это не про архитектуру). Можно также считать рейт, тут уже кому как удобнее. Лично я предпочитаю количество.
5) Соотношение багов к задачам (Bug/Task rate).
Считается в основном в разрезе спринтов или релизов. По сути мы оцениваем насколько много или мало багов мы пофиксили за определенный промежуток времени, по сравнению с основной задачей проекта - разработкой приложения.
Метрика "капризная", ей нужно соблюдать баланс. Почему спросите вы?!
Да потому, что если багов мало - значит мы их не исправляем и накапливаем долг, что при накоплении, только еще больше ухудшит качество продукта. А если много, то скорее всего мы только фиксим и ничего нового не производим, а значит, придет "злой" заказчик/менеджер/продукт/хозяин/хаосит-сланешит(нужное подчеркнуть) и накажет нас.
К слову, это тоже может быть не всегда верным, потому что действительно сильная команда разработки может делать хорошо с минимальным количеством проблем, а в "стабилизационные" спринты в составе могут быть только баги. Так что нужно не терять голову, оценивать исторические данные и разумно подходить к любым сигналам от метрик.
На сегодня все 😘.
До встречи в Части 2.
Всем добра!
5October 2, 2024 731 3 15
