Автор статьи: Глеб Саркисов (Gleb Sarkisov)
Оригинал статьи

Всем привет, меня зовут Глеб! Я — Head of QA в Mayflower. В последние несколько лет мне стали интересны метрики QA — особенно такие, которые позволяют искать проблемы в процессах, вести переговоры с бизнесом, показывать пользу тестирования для проекта и использовать показатели в качестве KPI.

За время работы в различных компаниях я видел разные подходы для решения этих задач и среди множества метрик я сконцентрировался на defect density. В результате ее изучения, я кастомизировал ее и запилил свою dd “со звездочкой”. Если вы тоже находитесь в поиске метрики, учитывающей чистоту релизов, их объем и скорость, вам может быть полезна моя статья.

По классике, метрика defect density — это доля дефектов, приходящаяся на отдельный модуль в течение итерации или релиза; считается на тысячу строк кода. Идея метрики заключается в том, чтобы определить отношение дефектов в вашем коде к его объему и постепенно уменьшать его. Идея, надо признать, отличная, но нюансы внедрения метрики могут сделать ее достаточно неудобной для использования.

1. Если ваш проект написан на нескольких языках, имеет много модулей, отдельных сервисов, механизм подсчета этой метрики будет непросто прикрутить.
2. Интерпретация значений может быть затруднена: для кого-то соотносить баги и количество строк может показаться неудобным, нелогичным и неприменимым, например, при тестировании “на стороне”, когда к коду вообще может не быть доступа, а данные о его качестве хочется получать.

Хочется взять самое лучшее от этой метрики, модифицировав ее для удобства и большей информативности. Если оттолкнуться от идеи, добавить производительность команды, критичность разных дефектов, то можно посчитать defect density ”со звездочкой” — отношение дефектов различных приоритетов на продакшне к фактической пользе, которую донесла команда за спринт. Так можно учесть сразу и чистоту тестирования внутри спринта, и скорость доставки через доставленный объем задач и багфиксов. Такой показатель можно понятно объяснять бизнесу и на него можно подвязываться как на качество релизного процесса — как на уровне отдельной команды, так и на уровне всего продукта.

Подсчет метрики

Посчитать плотность дефектов “со звездочкой” можно по формуле:

D — плотность дефектов “со звездочкой”

d — дефект соответствующего приоритета p1, p2, pn

k — коэффициент соответствующего приоритета p1, p2, pn

t — тикет (задача/багфикс) соответствующего уровня сложности c1, c2, cn

h — коэффициент соответствующего уровня сложности c1, c2, cn

Числитель — вес дефектов с продакшна, знаменатель — вес доставленных тикетов. Чем показатель ниже, тем лучше был спринт

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

Рекомендации по числителю

Для того, чтобы не складывать в корзину разные по приоритету дефекты, вводим понятие коэффициента приоритета дефекта:

Делим дефекты на 5 типов приоритета (у вас может быть и меньше или больше) — critical, major, medium, minor, trivial:

• p1 это critical
• p2 это major
• p3 это medium
• p4 это minor
• p5 это trivial

При учете critical дефектов умножаем их, скажем, на 5, чтобы вес таких дефектов был внушительным и они не потерялись на фоне не особо важной мелочи; введем коэффициенты для других приоритетов (вводите столько, сколько у вас видов приоритетов):

• kp1 = 5
• kp2 = 2
• kp3 = 1
• kp4 = 0.5
• kp5 = 0.1

Как результат, в числителе имеем суммарный вес дефектов с продакшна за спринт — все, что мы не смогли предотвратить в результате тестирования.

Рекомендации по знаменателю

Аналогично можно было бы поступить с задачами и багфиксами, но есть пара моментов.

Во-первых, есть риск смешения severity и priority для продуктовых задач под соусом проставления приоритета — и потом, перемножая количество задач определенного приоритета на соответствующий приоритет, оценка слишком сильно будет зависеть от понимания смысла приоритета продактом. Например, часто критическим приоритетом задачи помечают, если их просто нужно сделать как можно быстрее (классическая проблема, когда путают severity и priority).

Во-вторых, как я уже упоминал ранее, хочется учитывать и объем затраченных усилий в этой же формуле. Можно отделить один доставленный до продакшна тикет от другого по тому, как много времени потратили на разработку и тестирование — это и есть уровни сложности c в знаменателе. Как пример, задачи, на которые команда тратит максимальное количество времени можно пометить уровнем сложности Extreme, задачи поменьше Huge, Medium и так далее. Как выявить эти уровни сложности?

Возьмем выгрузку доставленных до продакшна тикетов (багфиксов, задач) за 4 спринта (можно взять и больше, так даже лучше) и нарежем на 5 слоев по перцентилям в зависимости от залогированного в них разработкой и тестированием суммарного времени:

• 100p — сложность Extreme, c1
• 95p — сложность Huge, c2
• 90p — сложность Long, c3
• 75p — сложность Normal, c4
• 50p — сложность Quick, c5

Note: Вы можете брать и больше разных перцентилей, если хотите еще больше градаций уровней сложности

Посчитав перцентили для каждого из 4 спринтов, считаем среднее арифметическое для каждого перцентиля в 4х спринтах. В результате мы выявим границы для каждого из уровней сложности.

Нам также надо проранжировать тикеты, доставленные до продакшна, умножив количество тикетов в данном уровне сложности на коэффициент данного уровня сложности h. Эти коэффициенты можете придумать сами, например:

• hc1 = 8
• hc2 = 5
• hc3 = 3
• hc4 = 2
• hc5 = 1

Нестрашно, что коэффициенты берутся “от балды” эмпирически: важно, что с их помощью мы получим отранжированные тикеты.

Как итог, в знаменателе имеем суммарный вес тикетов, доставленных до продакшна за спринт — вся польза, которую мы доставили для пользователя продукта.

Итак, веса для себя определили, показатель рассчитали — давайте разберемся, как это трактовать и что с этим делать.

Как работать с метрикой

Процесс работы с метрикой, наверное, покажется кому-то очевидным — надо собирать данные, находить “норму” и делать изменения в процессах, чтобы достичь лучшего показателя. Ниже опишу подробнее каждую часть процесса.

Нахождение показателя текущего состояния процесса доставки

Для поиска текущей “нормы” важно собрать какое-то весомое количество значений — анализ хотя бы 10 спринтов вполне подойдет. Разумеется, чем больше спринтов посчитаете, тем будет лучше. При этом, не обязательно ждать 10 спринтов — можно посчитать закрытые спринты (при условии, что вам доступны эти данные и разработчики и QA списывали время в тикеты).

Определение границ и фокуса

Как только есть хотя бы 10 значений метрики, имеет смысл:

1. Определить верхнюю границу, выход за которую вы будете считать плохим состоянием процесса доставки — вы можете сделать это по 100 перцентилю, либо добавить среднеквадратичное отклонение к 100 перцентилю или как-то иначе.
2. Посчитать 95, 90 и другие перцентили для этого набора значений, чтобы обозначить себе уровни, на которые вы хотите впоследствии выходить и закрепляться (чем ниже перцентиль, тем более амбициозная цель).
3. К слову про KPI — как раз эти перцентили и можно выбирать как цель проектной команды / QA-лида и тд на период в зависимости от вашей конфигурации.

Метрики не работают на вас, пока вы не начинаете на них комититься и менять процессы соответственно.

Проведение анализа внутри спринта

Очевидно, максимальный вес для числителя будут составлять дефекты критических приоритетов, а плохая производительность команды (количество залогированных часов в тикетах, доставленных до продакшна из знаменателя) ухудшит показатель.

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

Нюансы при внедрении метрики

1. Ваших разработчиков и QA придется приучить аккуратно и своевременно логировать время в задачи, если они еще этого не делают. Также, объясните вашей команде, что метрики нужны для измеримого результата, а не для поиска виновных — это классическая ментальная проблема команд.
2. Нужно проследить, что тикеты вовремя проходят по вашему флоу и меняют статусы — чтобы не получилось так, что какой-то тикет был доставлен в прошлом спринте и не попал в вашу выборку по спринту из-за того, что он не был переведен в статус delivered / closed / тд (зависит от вашего флоу).

Заключение

Для меня в работе с метриками часто было сложно описать четкую взаимосвязь одной стороны процесса с другой. Когда ко мне приходили руководители/менеджеры проектов и говорили, что QA медленно тестируют, я показывал количество багов, которое мы находим до выкатки на прод, и думал, что так понятно объясняю, какой уровень качества мы обеспечиваем. В то же время, мне хотелось самому понимать, насколько стабильна моя команда по релизам, действительно ли мы консистентно доставляем именно столько новых фичей и именно такого качества.

Плотность дефектов “со звездочкой” дала мне возможность в одной цифре учесть объем релизов, их чАстоту и чИстоту. Метрика не решит ваши проблемы за вас, но поможет их подсветить и увидеть результаты ваших усилий по исправлению процесса.

Несколько слов в напутствие:

1. Автоматизируйте сбор метрики, чтобы избавиться от человеческого фактора при сборе данных;
2. Сделайте визуализацию этой метрики общедоступной, объясните механику метрики вашей команде;
3. Если вы можете управлять целеполаганием команды, эта метрика хорошо подойдет для установки KPI на квартал/отчетный период в вашем флоу компании;
4. Подключайте и другие метрики, показывающие изъяны текущего процесса на разных этапах и в различной зоне ответственности — defect leakage, соотношение багов prod/testing и тд.