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

За годы работы в тестировании я убедился: то, что невозможно измерить — невозможно улучшить. В статье я разберу ключевые QA-метрики и объясню, как TMS помогает сделать картину качества действительно прозрачной.

Базовый минимум: где начинается анализ

Одна из самых очевидных метрик — Test Case Pass Rate (процент успешно пройденных тест-кейсов). Но ее ценность проявляется только при одном условии: на проекте достигнуто достаточное тестовое покрытие. Если кейсами закрыты основные и дополнительные сценарии и покрыты явные и неявные требования, низкий Pass Rate становится прямым индикатором высокой «багоёмкости» сборки.

Следующий уровень: находим корень проблем

Чтобы понять, где именно болит, нужны более точные метрики.

Defect Density — плотность дефектов по модулям

Эта метрика помогает точечно определить проблемные участки продукта. В TMS функциональные блоки обычно размечаются тегами — фильтрация по ним моментально показывает, какие модули дают больше всего провальных кейсов.

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

Severity Index — показатель серьезности обнаруживаемых дефектов

Хотя существуют различные подходы к определению критичности дефектов, при наличии на проекте культуры постановки приоритетов тест-кейсам, кейсы с наивысшим приоритетом обычно покрывают наиболее значимые модули системы. Соответственно, дефект, обнаруженный в таком модуле, с высокой вероятностью будет иметь серьезный статус, что повысит общий показатель Severity Index относительно установленной нормы и укажет на рост потенциальных рисков для проекта.

Defects by Stage — дефекты по стадиям обнаружения

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

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

Периодически эту метрику также называют Defect Leakage / Escaped defects. Это процент тех дефектов, которые были запоздало обнаружены на более поздних стадиях: например, в проде или на стадии UAT. Высокий процент таковых, в особенности, если это криты и блокеры — это серьезный показатель проблем с процессами на проекте.

Важный момент: Severity Index и Defects by Stage основаны на данных из таск-трекеров. Но современные TMS (как, например, DoQA) позволяют заводить баги прямо из интерфейса прогона, автоматически проставляя нужные теги. Это экономит время и снижает вероятность потери той или иной информации.

Как здесь помогает TMS

Теперь же сфокусируемся на тех данных, которые мы получаем непосредственно из TMS. 

Количество Broken / Skipped тестов

Их значительное количество после прогона — тревожный звоночек. Чаще всего это говорит о том, что тестирование не поспевает за изменениями требований. Такой показатель косвенно отражает метрику Volatility of Requirements. При высоких значениях необходимо пересматривать процессы, чтобы тестовые прогоны оставались актуальными.

Совет из практики: в TMS DoQA, которую я использую на проекте, есть незаменимый раздел «История», который позволяет проверять, менялся ли состав кейсов после выгрузки прогона.

Тестовое покрытие

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

Мониторинг тестирования

Даже простой обзор прогонов уже дает понимание динамики: что тестировалось, с какими результатами, и насколько активно идет работа.

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

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

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

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

Три главные мысли напоследок

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

2. Не существует «волшебной таблетки» в виде одной идеальной метрики. Важен комплексный подход: от базового Test Case Pass Rate до таких тонких индикаторов, как количество Broken-тестов или динамика создания новых кейсов. Каждая метрика — как пазл в общей картине качества продукта.

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

   Начните с малого — выберите 2-3 метрики, наиболее релевантные вашему проекту, и используйте возможности TMS для их регулярного отслеживания. Уверен, вы быстро заметите, насколько более управляемым и предсказуемым станет процесс тестирования. 

   А какие метрики стали вашими помощниками? Буду рад, если поделитесь в комментариях.