Привет, Хабр! Я — Ольга Султанова, руководитель тестирования в Рунити. Сегодня я расскажу о QA-метриках, которые мы применяем в работе: как мы их внедряли, как собираем данные, как автоматизируем и анализируем. А также о том, какие у нас стоят пороговые значения и о том, какие действия мы предпринимаем, когда они нарушаются. 

Навигация по тексту:

→ Основные понятия

→ Метрики дефектов

→ Метрики автотестов

→ Светофор

→ Автоматизация сбора метрик

→ Анализ метрик

→ Выводы

Основные понятия

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

Мы разделили наши метрики на три блока:

• Метрики дефектов;

• Метрики автотестов;

• Светофор.

Метрики дефектов

Метрик дефектов у нас 7:

1. Баги в старом коде;

2. Баги до релиза; 

3. Баги после релиза;

4. Доля отфильтрованных дефектов;

5. Найдено авто-тестами;

6. Критичные баги;

7. Инциденты (тип, команда, сервис).

Баги в старом коде. Эта метрика нужна для измерения общего качества и понимания, сколько багов мы обнаружили в старом коде. Собираются автоматически из Jira: учитываются задачи с типом «Баг» и меткой «prod».

Баги до релиза. Их находит тестировщик. Благодаря этой метрике мы понимаем, сколько дефектов обнаружено в новой фиче до того, как мы ее зарелизили. Собираются автоматически из Jira. Считаются по количеству чек-боксов в чек-листе «only_for_qa» или количеству, указанному в поле «Внутренние баги» в тикетах с типом «Баг».

Баги после релиза — это баги, найденные тестировщиками, менеджерами, другими сотрудниками или пользователями после выпуска фичи. Собираются автоматически из Jira. Учитываются задачи с типом «Баг» и меткой «баг_в_новом_коде».

Вторая и третья метрики нужны для формирования четвертой — доля отфильтрованных дефектов. Это показатель эффективности обнаружения багов: мы смотрим, какую долю дефектов удалось отфильтровать, а какая все-таки попала на прод. Здесь есть определенный показатель, который мы не должны превысить — об этом расскажем далее. Рассчитывается по формуле: количество багов после релиза поделенное на количество всех багов (до и после релиза).

Баги, найденные автотестами. Эта метрика по большей части нужна для оценки эффективности наших автотестов. Собирается автоматически из Jira. Учитываются баги, найденные в проде, с меткой «autotesting»

Критичные баги. Эта метрика нужна командам для понимания, какой функционал был задет. Разумеется, критичных багов должно быть как можно меньше. Если их пропускается много — значит, в тестировании есть какие-то проблемы. Собирается автоматически из Jira. Учитываются баги, найденные в проде, с меткой «crit»

Инциденты — ситуации, задевшие более 10% пользователей. Мы смотрим на тип инцидента: либо инфраструктурный, либо ошибка разработки. Также смотрим, в какой команде произошел инцидент, и сервис этой команды. Все показатели мы в дальнейшем обрабатываем. Собирается автоматически из Jira с доски аварий. Из тикетов берется информация о типе, команде и сервисе, в котором произошел инцидент.

Если представить работу нашей команды и проставление меток дефектов в Jira в виде схемы, то получится вот так:

Метрики автотестов

Метрик автотестов мы используем всего четыре:

1. Общий процент покрытия автотестами требований в %;

2. Актуальное покрытие автотестами в шт;

3. Процент хрупкости сборок;

4. Средняя продолжительность сборок в минутах. 

Общий процент покрытия автотестами требований в % — первая метрика, которую мы начинаем собирать. Все наши требования в виде тест-кейсов прописаны в Testrail. Мы смотрим, сколько из них покрыты автотестами, а сколько еще нет. Здесь у нас всё расписано по командам: мы можем наглядно посмотреть, сколько процентов по каждой команде у нас покрыто. 

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

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

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

Светофор

При помощи третьего блока метрик — светофора — мы отслеживаем ментальное состояние тестировщиков. Считаем, что это важный момент в нашей работе.

В этом блоке у нас две метрики:

1. Количество разработчиков и тестировщиков по командам;

2. Общее состояние сотрудника в текущем месяце.

Количество разработчиков и тестировщиков по командам — метрика, которая примерно показывает нагрузку на одного сотрудника. Без дополнительных данных это не очень объективная метрика: в командах могут быть разные задачи. Например, только технические, где не так много тестирования, либо продуктовые с высокой QA-нагрузкой. Метрика показывает, у каких сотрудников может быть перегруз, и к кому руководителю нужно в первую очередь обратиться с вопросом, всё ли хорошо. Эту метрику мы собираем из списка сотрудников на корпоративном портале.

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

Автоматизация сбора метрик

Мы постарались максимально автоматизировать сбор метрик. Сейчас у нас 4 сервиса, из которых мы берем информацию:

• Логи автотестов;

• Баг-трекер;

• Внутренний корпоративный портал;

• TestRail.

Мы получаем информацию из этих источников при помощи самописного скрипта при помощи API. Затем результаты попадают в базу данных — у нас это MySQL. Оттуда они подтягиваются в Grafana, где превращаются в информативные графики и таблицы. 

Анализ метрик тестирования

Теперь давайте разберемся, что делать дальше с собранными данными. Мы пришли к определенным пороговым значениям, при превышении которых понимаем, что у нас что-то идёт не так и нужно предпринимать действия. Сейчас таких значений у нас 5:

1. Количество багов после релиза в старом коде: не больше 10 за квартал

2. Количество багов после релиза: не больше 5 за месяц

3. Доля отфильтрованных дефектов: не больше 0,1

4. Покрытие автотестами требований в %: текущее значение не должно падать больше, чем на 10%

5. Хрупкость автотестов: не больше 5%

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

Выводы: зачем нам нужны QA-метрики?

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