В воспитании детей есть интересный каламбур: если вы в любой момент времени не знаете, чем заняты ваши дети, то, возможно, это уже не ваши дети. Перефразируя под процессы обеспечения качества в проекте, можно сказать: если вы не знаете, чем занимаются ваши QA‑инженеры, и не внедрили метрики в проекте, то, возможно, это уже не ваш проект?

Меня зовут Илья я лид тестирования в проекте Сбер Диск. Про управление командой тестирования поговорим как‑нибудь в другой раз. А сейчас мне хотелось бы обсудить именно метрики тестирования.

Метрики. Кого‑то они пугают, кто‑то их ненавидит, кто‑то молится на них. Признаюсь, когда я только начинал заниматься тестированием, они меня дико раздражали. «Да зачем они вообще нужны?» — думал я. — «Давайте просто работать. Писать тест‑кейсы, потом их автоматизировать». Нужны метрики? Ну вот, я вручную проверял неавтоматизированные кейсы и запустил автотесты. Вот аллюр отчёт по ним. Разве это не метрики?

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

Нельзя прийти к своему руководителю и на вопрос: «Что там с проектом?» ответить: «Всё отлично, проект качественный, зуб даю!» Невозможно повысить зарплату, обосновывая, что тестировщик Ваня — отличный парень и чётко работает, а наш проект — лучший по обеспечению качества, потому что я в этом уверен!

Что такое метрики в тестировании?

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

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

«Они помогают принимать обоснованные решения на основе объективных данных.»

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

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

Я выделяю три группы:

1. Метрики покрытия измеряют степень охвата различными видами тестирования или автоматизации разных областей продукта.

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

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

Метрики покрытия

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

По своему опыту скажу: если у вас есть аналитики, не стесняйтесь общаться с ними относительно полноты и структуры требований. Для этого например подойдет метод «Три амиго». Кратко напомню про него.

«Три амиго» — это техника группового обсуждения, которая помогает участникам глубже разобраться в сложной теме или проблеме. На встрече должны присутствовать представители бизнеса, разработки и тестирования. Такая команда может удовлетворить запросы каждой из заинтересованных сторон и наиболее полно обсудить требования.

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

Теперь перейдём к самим метрикам.

Покрытие требований

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

Формула расчёта

Формула покрытия требований (Requirement Coverage Ratio — RCR), используемая для оценки полноты тестирования программного продукта, выглядит следующим образом:

Зачем нужна эта метрика?

1. Выявление пробелов в тестировании. Метрика помогает определить, какие требования остались без тестов. Это важно для предотвращения ошибок и сбоев в работе продукта.

2. Планирование ресурсов. Позволяет планировать усилия команды на создание дополнительных тестовых сценариев и эффективно распределять ресурсы.

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

4. Документация и отчётность. Предоставляет объективные данные для отчётности перед руководством и заказчиками о состоянии тестирования. Стоит помнить, что достичь полного покрытия сразу бывает сложно, поэтому важно заранее согласовывать цели и этапы достижения необходимого уровня покрытия. Затем регулярно предоставлять отчёты о прохождении этих этапов и динамике развития проекта.

Покрытие тестовых сценариев автотестами

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

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

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

Формула покрытия тестовых сценариев:

где:

•  — Test Scenario Automation Rate (доля автоматизации);

• — количество тестовых сценариев, покрытых автотестами;

•  — общее количество имеющихся тестовых сценариев.

Зачем нужна эта метрика?

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

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

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

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

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

Длительность нахождения задачи в тестировании

Эта метрика относится к ключевым показателям эффективности процесса тестирования. Она определяет, сколько времени задача проводит в статусе «Тестирование», начиная с момента передачи её команде тестировщиков и заканчивая моментом завершения прогонов. Этот показатель помогает оценить производительность команды, выявить узкие места в процессе и оптимизировать работу над проектом, например внедрив автоматизацию.

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

Зачем нужна эта метрика?

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

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

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

Время прохождения регресса

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

Зачем нужна эта метрика?

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

2. Ресурсоёмкость. Длительный регресс требует значительных человеческих и технических ресурсов, что увеличивает общие затраты на проект.

3. Клиентский опыт. Задержки с проведением регресса откладывают выпуск обновлений, что негативно отражается на восприятии продукта заказчиком.

Кажется, что эта метрика подходит не для всех проектов. Например, если релизный цикл строго регламентирован (скажем, раз в месяц или квартал), то внедрение этой метрики может показаться избыточным. Но даже небольшая экономия времени может открыть окно возможностей для дальнейшего развития проекта и ускорения релизного цикла. А в условиях коротких циклов и небольших релизов («маленькие задачи — маленькие релизы») она становится одной из ключевых. Её удобно использовать как ориентир для совершенствования работы команды. Например, в одном из моих проектов регресс занимал три дня и проводился вручную. Благодаря автоматизации и улучшению процессов тестирования его сократили до 40 минут и сделали практически полностью автоматизированным. Это позволило нам выпускать релизы в любое удобное время, как только готовы новые фичи от разработчиков.

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

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

Количество багов в продукте и их приоритет

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

Зачем нужна эта метрика?

• Позволяет понять масштаб проблемы. Если количество багов велико, это может свидетельствовать о низком качестве продукта или недостаточном уровне тестирования.

• Приоритет багов помогает расставить приоритеты. Более приоритетные баги, способные серьёзно повлиять на работу продукта, требуют немедленного внимания и исправления.

Динамика по багам

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

Зачем нужна эта метрика?

• Помогает увидеть тенденции. Растёт ли количество багов и их вес или уменьшается со временем.

• Показывает эффективность работы команды. Снижение количества открытых багов может говорить о хорошем прогрессе в исправлении ошибок.

• Указывает на потенциальные проблемы. Резкий рост количества багов может сигнализировать о снижении качества кода или увеличении сложности продукта.

Количество инцидентов в проде и их приоритет

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

Зачем нужна эта метрика?

• Отражает фактическое воздействие на пользователей. Даже если при тестировании выявлено много багов, главное — минимизировать инциденты в проде.

• Помогает оценить надёжность продукта. Чем меньше инцидентов, тем более надёжным воспринимается пользователями продукт.

Плотность дефектов по стендам

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

Зачем нужна эта метрика?

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

2. Оптимизация процессов. Высокая плотность дефектов на определённом стенде может сигнализировать о необходимости пересмотреть процессы развёртывания или тестирования.

3. Приоритизация исправлений. Сосредотачиваемся на тех стендах, где замечено больше всего багов.

4. Анализ качества релиза. Позволяет оценить готовность продукта перед выпуском в эксплуатацию.

Заключение

Я постарался максимально сжато охватить ключевые метрики, которые вы можете и должны внедрить в проекте. Приведённый в статье джентльменский набор метрик позволит быстро и качественно настроить мониторинги состояний процессов тестирования. Конечно в каждом проекте есть свои особенности, на которые следует обращать внимание, и что‑то добавлять или убирать. Но главное, всегда нужно помнить и разъяснять другим, зачем нужны метрики. Что они не враг, а самый лучший друг любого инженера, и без них выстроить прозрачные, удобные, а главное, масштабируемые процессы никогда не получиться.

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

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

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