Привет, Хабр! Сегодня с вами Анна Асабина, главный инженер по тестированию, и Ольга Султанова, руководитель направления тестирования в Рунити.
Мы расскажем о нашем опыте внедрения метрик в тестировании: какие метрики для нас работают, зачем мы автоматизировали их сбор и что в итоге изменилось.
Навигация по тексту:
Как мы пришли к метрикам
Когда метрики нужны — обычно уже поздно. Данные требуются «ещё вчера», и команда начинает судорожно собирать их вручную. Так было и у нас: менеджеры просили показать загрузку тестировщиков или эффективность тестирования, а я вместо анализа багов часами ковырялась в Jira, выгружая данные.
Со временем это превратилось в рутинный и нелюбимый процесс: в конце каждого месяца каждый тестировщик отправлял свои метрики вручную, перебирая тикеты и вспоминая, что вообще было в работе. Последний день месяца стал днём, когда команда откладывала все задачи, чтобы просто собрать цифры. В один из таких дней и появилась идея подумать над упрощением — за счёт автоматизации.
Этот момент стал для нас переломным — стало понятно, что без метрик и автоматизации дальше двигаться нельзя.
Вопрос «зачем собирать метрики» быстро сменился другим: «Как собирать их так, чтобы это не отнимало рабочее время». Сейчас метрики стали нашим важным инструментом: мы всегда знаем текущее качество продукта, контролируем процесс и заранее видим проблемные зоны.
Признаки «правильной» метрики
Мы много экспериментировали и в итоге оставили только те метрики, которые дают реальную пользу. У нас сформировались три критерия:
Полезность. Метрика должна отвечать на конкретный вопрос бизнеса или продукта.
Прозрачность. Процесс сбора понятен всем: от тестировщика до менеджера.
Масштабируемость. Метрику можно адаптировать для других команд и продуктов.
Процессные метрики
«Светофор нагрузки»
Каждый месяц тестировщики в Rocket.Chat (наш внутренний корпоративный мессенджер) отмечают свою загруженность:
зелёный — всё в порядке;
жёлтый — есть сложности, но работа идёт;
красный — перегруз, нужен пересмотр процессов.
Если несколько месяцев подряд горит красный — это повод вмешаться до того, как человек выгорит.
Соотношение разработчиков и тестировщиков
Мы отслеживаем, сколько разработчиков приходится на одного тестировщика. В продуктовых командах рост этого показателя — сигнал, что нагрузка на тестирование может выйти из-под контроля.
Количество тикетов на тестировщика
Каждый вторник в Rocket.Chat приходит уведомление: фамилия, команда, количество назначенных задач. Источник — данные из Jira API. Метрика помогает планировать нагрузку и перераспределять ресурсы.
Метрики дефектов
Мы используем шесть метрик:
Баги в старом коде — стабильность продукта. Отслеживаются по метке PROD в Jira и выводятся в Grafana.
Баги до релиза — качество тестирования до выкатки. Считаются по внутренней метке «баг».
Баги после релиза — указывают на недоработки, которые просочились в прод. В ближайшее время хотим доработать метрику: учитывать, кто нашёл баг (тестировщик, менеджер и т. д.).
Баги, найденные автотестами — эффективность автоматизации.
Критичные баги — дефекты в важном функционале (метка CRIT). В идеале — ноль.
Доля отфильтрованных дефектов — насколько хорошо тестирование отсеяло баги до релиза.
Для наглядности все данные выводятся в Grafana. Это система мониторинга и визуализации, которая превращает цифры из баз данных и API в удобные графики и дашборды. Благодаря ей мы сразу видим динамику и можем анализировать тренды.
Метрики автотестов
Покрытие кейсов автотестами
В TestRail тестировщики помечают автоматизированные кейсы (automation type = automated). Через TestRail API данные попадают в БД, и Grafana показывает процент покрытия.
Покрытие автотестами в штуках
Это те же данные, что и процент покрытия, но в абсолютных значениях — количестве кейсов, закрытых автотестами. Такой подход помогает увидеть реальный масштаб работы, особенно при сравнении разных модулей.
Процент может вводить в заблуждение: 90 % покрытия для небольшого модуля — это всего 9 тестов, а 50 % для крупного — уже 50. Поэтому важно смотреть на обе метрики вместе — процент и количество.
Запуск и сбор данных автоматизирован через GitLab CI: результаты сборок и прогонов тестов поступают в Rocket.Chat.
Хрупкость сборок
Метрика отслеживает нестабильные тесты. Если в сборке слишком много «флаки», команда рефакторит сценарии. Порог — не более 5%.
Средняя продолжительность сборок
Важно понимать, сколько времени занимает прогон. Это помогает планировать регрессионное тестирование перед релизом.
Автоматизация: как мы это сделали
Когда стало понятно, что без автоматизации дальше не продвинуться, мы начали с самого важного — требований. Нужно было понять, какие данные и метки добавить, чтобы сбор можно было полностью автоматизировать. Собирали рабочие группы, обсуждали, переписывали регламенты, внедряли флаги и поля, на которые можно было бы опираться.
Когда структура данных устоялась, реализация пошла быстро. Скрипты написали за пару недель. Весь процесс — от идеи до готового первого варианта — занял примерно 2–3 месяца и шел параллельно с основной работой.
Мы интегрировали сбор метрик в рабочие процессы:
Jira API — для багов и загрузки;
TestRail API — для покрытия кейсов;
логи автотестов — для данных о сборках;
GitLab CI — для управления запуском;
Grafana — для визуализации;
Rocket.Chat — для уведомлений и алертов.
Пример: если за месяц багов в новом коде больше пяти, система сама отправляет сообщение в Rocket.Chat с перечнем команд, причастных к функционалу.
Алерты в Rocket.Chat
После автоматизации метрики не только собираются автоматически, но и сразу обрабатываются через систему уведомлений.
Сейчас у нас несколько типов алертов:
Баги без меток. Сигнал тестировщикам пройтись по тикетам и добавить недостающие флаги.
Падение процента покрытия или рост хрупкости автотестов. Повод проверить сценарии и спланировать исправления.
Нагрузка по тикетам. Уведомление для менеджеров: показывает, сколько задач назначено на тестировщика, чтобы можно было сбалансировать распределение.
Слишком много багов на проекте. Сигнал для тимлидов, что стоит пересмотреть процессы или обратить внимание на конкретную фичу.
Человеческий фактор — главный источник ошибок
Главные сложности в автоматизации оказались не техническими, а человеческими. Метрики зависят от корректно проставленных флагов и меток в Jira и TestRail. Если тестировщик забывает указать тип теста или поставить метку autotesting, данные искажаются — процент покрытия оказывается ниже, чем есть на самом деле, а баг может не попасть в нужный отчёт.
Сейчас команда готовит новую итерацию системы метрик, чтобы снизить зависимость от ручного ввода и исключить подобные ошибки.
Что изменилось после внедрения
После запуска автоматизации метрики перестали быть отдельной задачей — они органично стали частью рабочих процессов. Теперь ничего не нужно собирать вручную: данные обновляются автоматически, а команда видит результаты в Grafana и Rocket.Chat.
За сбор и работоспособность метрик отвечает команда тестирования. Мы поддерживаем логику и корректность автоматизации, следим за актуальностью флагов и меток, по которым строятся отчёты.
Теперь в конце месяца никто не тратит день на отчётность: метрики собираются автоматически, а тестировщики занимаются своей основной работой. Для руководителей данные стали прозрачными — видны загрузка по людям, качество тестирования, динамика автотестов и общая картина по проектам.
Среди основных результатов:
Экономия времени. Автоматизация освободила около 100 человеко-часов в месяц.
Прозрачность. Все — от тестировщика до продакта — видят актуальные данные.
Быстрая реакция. Алерты в Rocket.Chat помогают вовремя заметить проблемы.
Качество. Количество багов, попадающих в прод, снизилось почти в три раза.
Итоги
Метрики — это инвестиция в процессы. Они не существуют сами по себе, но дают опору для решений, помогают держать под контролем нагрузку и качество, а главное — экономят время.
Наш совет: начинайте с малого, адаптируйте под свои задачи и не бойтесь экспериментировать. А ещё делитесь своим опытом: какие метрики вы собираете и какие инструменты вам помогают?