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

Зрелым командам такие метрики ощутимо помогают:

• замечать периоды низкого перформанса команды и нехватку ресурсов;

• следить за такими показателями, как общая забагованность сервиса, время реагирования на различные события, количество задач, которые одновременно может обрабатывать команда, и за другими важными моментами;

• сравнивать показатели работы команд в подразделении перед предстоящим периодом ревью.

Меня зовут Катя, я руковожу службами тестирования Музыки и Букмейта, и в этом посте я хочу рассказать про основные метрики, которые мы используем в команде тестирования Яндекс Музыки, и обсудить, как правильно с ними работать.

Соглашение об уровне сервиса (SLA)

Время взятия тикета в тестирование. Здесь мониторится время, за которое тикет взят в тестирование после его готовности. Исключаются выходные, праздничные дни и нерабочее время. Метрика показывает, насколько оперативно команда реагирует на поступающие задачи.

Большая тема для холивара: почему не учитывается время выполнения работы (тестирования задачи)? Если следить только за временем реакции, то что мешает тестировщику быстро набрать в работу 100500 тикетов?

Во-первых, любые метрики можно хакнуть. Как вы используете метрики в своём проекте — вопрос целеполагания и культуры в команде (подробнее об этом в заключении).

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

Время реагирования на тикет, прилетевший в саппорт. Оно считается от момента передачи тикета от саппорта команде тестирования или разработки до момента взятия этого тикета в локализацию. Мониторится скорость ответа команды тестирования на обращение, переданное от пользователя. 

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

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

Ключевые показатели эффективности (KPI)

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

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

Метрика забагованности

Автоматическое проставление критичности бага

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

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

Мы доверили это ответственное дело беспристрастному роботу. В итоге критичность багу выставляется в зависимости от его веса.

Vol 1. Определение веса и критичности бага

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

Итак, как посчитать вес бага и определить его критичность:

Шаг 1: определить минимально необходимый набор параметров, которые будут учитываться при выставлении критичности (определяется индивидуально для каждого продукта или сервиса).

Браузер

Коэффициент воспроизводимости

Стадия

Важно: Под testing мы имеем ввиду баги регресса. В данном случае вес у Testing больше, чем вес у Production, потому что баги регресса блокируют выкатку релиза, и их нужно починить до выкатки. 

Влияние на пользователя

Количество обращений от пользователей

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

Шаг 2: сформировать формулу для расчёта веса бага (также может отличаться для каждого продукта или сервиса).

zbpWeight = platform_factor * reproduction_factor * stage_factor_music * impact_factor * 100 + complaintNumber * 0.35  

Шаг 3: определить диапазон весов.

Используя полученные знания, можно честно определять критичность заводимых багов. Идём дальше.

Vol 2. Автоматический расчёт

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

Автор тикета заполняет четыре поля, и ВЖУХ — вес считается автоматически, критичность также автоматически меняется на основании полученного веса.

Vol 3. Обвесы к процессу (улучшайзеры) 

Что ещё происходит в рамках существующего процесса: призываем и наказываем автора багрепорта и дежурного QA, если для тикета не были проставлены нужные поля.

Забагованность сервиса

Про графики. Графики, они как стодолларовые купюры — всем нравятся!

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

Поэтому мы обзавелись мониторингами, которые дают возможность отслеживать:

• общую забагованность сервиса;

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

Взвесив все существующие баги, мы узнали, что у нас не просто N незакрытых багов в очередях, но и насколько они приоритетные, как влияют на общую картину сервиса. Любой новый баг, который аффектит пользователя и Музыку, сразу покажется на графике. У нас могут быть десятки открытых миноров (их вес небольшой), которые почти не меняют график, а можем словить всего один блокер, вес которого значительно влияет на график, и он сразу же будет заметен.

Когда метрики могут быть недостаточными

1. Создание избыточного числа SLA и KPI может привести к тому, что команда будет фокусироваться только на достижении показателей, что может снизить мотивацию и вовлечённость в работу.

2. Оценка работы команды без контекста и сравнения с другими стандартами может быть бесполезной, так как не даёт понимания о том, являются ли достигнутые результаты хорошими или плохими. Использовать метрики для мониторинга — хорошо. А вот для того, чтобы начать натягивать показатели на метрики или поругать сотрудников — плохо.

3. Если метрики используются только для оценки работы одного подразделения (например, тестирования), это может привести к недостаточной объективности оценки и игнорированию взаимосвязи с другими командами. Оценка работы одной команды в вакууме ничего не даёт. Хорошо, когда есть с чем сравнить, а также понимание, к чему хочется прийти.

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

Что в итоге

Возвращаясь к заголовку статьи, хочется ответить на два вопроса:

Когда QA-метрики могут быть полезны?

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

Как использовать QA-метрики?

Ухудшения показателей могут сигнализировать, например, о том, что есть недостаток ресурсов (тогда силы команды можно перераспределить или нанять ещё сотрудников) или необходимо пересмотреть текущие процессы (например, процесс планирования починки багов или внедрение дополнительных quality-gate).

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