Миллиарды строк кода, сотни интеграций и бесчисленные микросервисы — таков современный ИТ-ландшафт крупнейших компаний страны. В периоды пиковых нагрузок даже минута простоя может обойтись бизнесу в десятки и сотни миллионов рублей и обернуться подрывом доверия клиентов. В этом свете тестирование ПО превращается из формального контрольного этапа в гарантию непрерывности работы сервисов. Вместе с новой ролью возникает и потребность в специальных метриках, способных объективно измерять качество продукта по множеству критериев.
Традиционно принято делить метрики тестирования на три категории: по процессу, по продукту и по проекту. Первые направлены на улучшение процесса тестирования, вторые отслеживают качество тестируемого продукта, третьи оценивают эффективность работы тестировщиков и используемых инструментов.
Также существует классификация метрик по методам их получения, которая делит их на базовые и рассчитываемые.
Базовые метрики, как правило, представлены в абсолютных значениях и целых числах. Они собираются тестировщиками на регулярной основе и помогают отслеживать основные показатели их работы. К базовым относятся такие метрики, как:
общее количество тест‑кейсов;
количество успешно пройденных и непройденных тест-кейсов;
заблокированные тест-кейсы;
общее количество обнаруженных дефектов;
количество принятых и отклоненных дефектов;
время, запланированное на тестирование;
время, потраченное на тестирование;
дефекты, обнаруженные после релиза.
Рассчитываемые метрики собираются на основе базовых метрик и проектного контекста. Они предназначены для более глубокого анализа ситуации и ответа на конкретные вопросы проектного управления. Пример рассчитываемых метрик:
покрытие тестами требований;
эффективность тестирования (соотношение между затраченными на тестирование ресурсами и количеством обнаруженных дефектов);
плотность дефектов (количество дефектов на количество строк кода).
Их использование особенно полезно для руководителей и менеджеров, которые принимают решения на основе собранных данных и стремятся улучшить процессы тестирования и разработки.
Метрики тестирования не могут быть просто числовыми показателями, они должны приносить командам практическую пользу для улучшения работы.
Примеры из практики
Рассмотрим несколько полезных метрик из нашей практики.
Данная метрика отражает отношение количества критических дефектов, найденных в приложении или продукте, к общему объему обнаруженных багов и позволяет оценить общую стабильность и надежность продукта.
Высокая плотность критических дефектов может указывать на низкое качество кода, что требует дополнительного внимания и рефакторинга. Эту метрику можно сравнивать со средними показателями в прошлых проектах или внутренними эталонами в компании, чтобы понять, соответствует ли качество кода ожидаемым показателям.
При этом плотность критических дефектов должна интерпретироваться с учетом контекста. Например, в небольших модулях с высокой сложностью может быть больше дефектов, чем в больших, но простых.
Это невероятно полезная и при этом требовательная к точности используемых для расчета данных метрика, которая измеряет среднее время, затраченное на тестирование исправления одного дефекта. Если этот показатель высок, это может указывать на проблемы в процессах тестирования или недостаток ресурсов. Знание среднего времени тестирования исправлений помогает лучше планировать время и ресурсы, необходимые для выпуска новых версий продукта.
Данная метрика помогает демонстрировать прогресс выполнения тестов вышестоящему руководству.
А этот показатель в «тепловой карте» тестирования используется, как основа для цветовой индикации при определении объема сокращенного регрессионного тестирования. Это нужно, например, если у нас на полноценный регресс-тест нет времени из-за сжатых сроков или недостатка ресурсов.
На самом деле можно не высчитывать саму метрику, а построить тепловую карту просто с помощью условного форматирования в Excel, как это сделано для списка тестов ниже:
Три варианта индикации соответствуют различной плотности выявленных дефектов: тесты из групп tc0000282, tc0000289 и особенно tc0000286 должны входить в регрессионное тестирование всегда, так как в прошлом именно эти тесты выявляли ошибки чаще всего.
Дополнительная цель — помочь команде определить, какие части программы стоит протестировать в первую очередь и сконцентрировать усилия на самых важных участках кода, чтобы убедиться в качестве их работы после внесения изменений.
Несколько полезных советов
Обязательно собирайте базовые метрики и сохраняйте их историю. Метрики полезны только тогда, когда мы видим их в динамике. Исторические данные позволяют отслеживать изменения и тенденции, что дает возможность принимать более обоснованные решения.
Определяйте ключевые рассчитываемые метрики: составьте список наиболее важных метрик, учитывая контекст вашего проекта. Не все метрики одинаково полезны для разных команд и проектов.
Не стремитесь использовать все возможные рассчитываемые метрики: сосредоточьтесь на тех, которые действительно помогают выполнять работу и принимать решения. Избыток данных может усложнить анализ и запутать команду.
Упрощайте: сложные метрики могут казаться более точными, но часто простые показатели оказываются более полезными и наглядными. Чем проще метрика, тем легче ее интерпретировать и использовать в повседневной работе.
Принимайте конкретные меры по результатам анализа метрик: метрики должны быть инструментами для принятия решений и отслеживания результатов. Если анализ показывает проблемы или области для улучшения, важно реагировать на эти данные и предпринимать конкретные шаги.
Не тратьте время на перекрестную проверку метрик: даже если в метриках есть небольшие ошибки (например, вы промахнулись с количеством найденных дефектов на 1-5 единиц из общих 40), это обычно не меняет общей картины. Главное — видеть общие тенденции и направления для улучшения.
Живой пример работы с метриками
Дано:
Существует проект, который длится уже около года, и в котором уже произошло несколько переносов Go-live на 1-2 недели вперед.
На проекте активно используют Scrum-подход, но по факту это «сломанный водопад»: по Agile работают только разработчики. Передача на приемочное пользовательское тестирование (UAT) осуществляется только после полной проверки и приемки на этапе системно-интеграционного тестирования (SIT). Запланировано 20 релизов, и исполнители для SIT и UAT разные.
Задача:
Для завершения UAT и готовности к Go-live необходимо пройти 99%+ приемочных тестов успешно. Однако команда UAT сталкивается с серьезными проблемами: 45% тестов не могут быть выполнены из-за отсутствия необходимого функционала, а еще 20% – из-за дефектов, найденных в предыдущих релизах. Причем количество дефектов постоянно растет. Что же делать?
Решение:
Шаг 1. Сбор базовых метрик
Сначала необходимо собрать базовые метрики количества дефектов на этапах SIT и UAT. Это поможет понять текущую ситуацию и выявить основные проблемные области. В Jira это Filter counters gadget для дашбордов. При отсутствии Jira выгружайте данные через Postman или подключайтесь к БД таск-трекера. В TMS используйте встроенные отчетные движки для анализа загрузки тестировщика, покрытия требований и эффективности тестов. Если данных не хватает, интерполируйте значения, которые были пропущены.
Шаг 2. Анализ метрики Created vs Resolved (CvR)
Построим график CvR (соотношение созданных заявок на исправление и исправленных дефектов) для обоих этапов (SIT и UAT). Эта метрика позволяет оценить динамику создания и устранения дефектов.
Шаг 3: Выбор дополнительных метрик
Используем следующую логику для выбора дополнительных метрик:
Если CvR для SIT расширяется или остается неизменным, анализируем процент критических дефектов. Если доля критических дефектов высока, это указывает на серьезные проблемы с качеством разработок. В этом случае нужно сфокусироваться на фиксации дефектов на этапе SIT, даже если это повредит прогрессу на UAT.
Если CvR для SIT сужается или CvR для UAT расширяется/остается неизменным, проводим более детальный анализ SIT, используя метрики Find Bug Rate (скорость нахождения дефектов) и Requirement Coverage (покрытие требований).
Это поможет понять, насколько эффективно идет тестирование на этапе SIT. Здесь в обоих случаях проблема была именно в SIT – и это правильно, потому что концепцию раннего тестирования и «сдвига влево» никто не отменял.
И в заключение
Очень важно понимать и правильно использовать метрики, и тогда они станут вашим незаменимым инструментом детекции проблемных зон. Собирать цифры ради цифр – это бесполезная бюрократия – серьёзный враг перспективного и эффективного руководителя.