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

Группа 1 - Требования к разрабатываемому ПО

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

1. Тестовое покрытие требования

Иными словами, это количество тестов на 1 требование.

Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.

• Конечно, данная метрика будет работать, только если требования хорошо декомпозированы и более или менее равнозначные. Разумеется это не всегда возможно, но если получается сделать требования достаточно атомарными, то данная метрика покажет отклонение покрытия каждого требования от среднего уровня. Чем больше значение отличается от 1, тем меньше\больше тестов написано для одного требования, чем обычно.
• Важнее всего обратить внимание на требования, для которых коэффициент будет равен или близок к 0. Для них нужно рассмотреть возможность добавления тестов.
• Если требования не атомарные, то данная метрика позволит убедиться только в том, что для каждого требования есть хотя бы 1 тест. Для этого коэффициент всегда должен быть больше 1.

2. Степень взаимосвязанности требований

Метрика вычисляется как среднее количество связей каждого требования с остальными требованиями.

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

• Значение этой метрики будет находиться от 0 до 1. 1 означает, что каждое требование связано с каждым, а 0 – что взаимосвязей нет.
• Тут сложно вводить какие-то ограничения для значений данного коэффициента, многое зависит от специфики функционала, архитектуры, технологий. Однако, по своему опыту могу сказать, что хорошо, когда степень связанности не превышает 0,2-0,3. В противном случае доработка в рамках одного из требований будет вести к цепочке изменений, а значит и возможных ошибок, в значительной части продукта.

3. Коэффициент стабильности требований

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

• Разумеется, полностью изолированного функционала не существует, но количество новых требований должно преобладать над изменяемыми а коэффициент желательно должен быть меньше 0,5. В этом случае мы внедряем новых фич в 2 раза больше, чем переделываем существующих.
• Если коэффициент выше 0,5, особенно если больше 1, то это скорее всего значит, что ранее мы сделали то, что оказалось ненужным. Команда фокусируется не на создании новых ценностей для бизнеса, а на переделывании ранее выпущенных фич.
• Также метрика дает представление о том, насколько легко масштабируется функционал системы, добавляются новые возможности.

Группа 2 - Качество разрабатываемого продукта

Как следует из названия, эта группа метрик демонстрирует качество ПО, а также и качество самой разработки.

1. Плотность дефектов

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

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

• Причины большого количества дефектов к каком-то одном конкретном модуле (коэффициент больше 0,3) могут быть различны: некачественные требования, квалификация разработчика, техническая сложность и т.д. В любом случае данная метрика сразу обратит наше внимание на проблемную зону.

2. Коэффициент регрессии

Назначение метрики: показать, на что уходят усилия команды: занимаемся ли мы больше созданием и отладкой новых фич или основную часть времени вынуждены латать уже существующие части ПО

• Чем ближе коэффициент к 0, тем меньше было внесено ошибок в существующий функционал при реализации новых требований. Если значение больше 0,5, то мы больше половины времени тратим на восстановление работавших ранее функций ПО

3. Коэффициент повторно открытых дефектов

Назначение метрики: дать оценку качеству разработки и исправления дефектов, а также сложности продукта или отдельного модуля

• Эту метрику можно рассчитывать для всего ПО, отдельного модуля или функциональности. Чем полученное значение ближе к 0, тем меньше при разработке повторяются старые ошибки.
• Если коэффициент получился больше 0,2-0,3, это может говорить либо о технической сложности модуля и высокой связанности требований в нем, либо о корявой архитектуре, либо о том, что предыдущий фикс был сделан некачественно.

4. Средняя стоимость исправления дефекта

Отношение суммы затрат понесенных командой при работе со всеми дефектами (например, в рамках релиза) к общему числу дефектов.

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

• Каких-либо правильных значений тут конечно нет, все будет определяться спецификой конкретной ситуации

5. Количество дефектов в коде конкретного разработчика

Назначение метрики: подсветить возможные сложности в команде разработки, кому из специалистов не хватает опыта, знаний или времени, нужна помощь.

• Если, например, 50% всех дефектов приходиться на 1 разработчика, а всего в команде их 5, то тут явно есть проблема. Из этого не следует, что данный программист плохо работает, но сигнализирует обязательно разобраться в причинах подобной ситуации.
• Метрика помимо прочего может быть индикатором особенно сложного для разработки и поддержки модуля\функционала\системы.

Группа 3 – Возможности и эффективность команды QA

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

1. Скорость работы (velocity) команды QA

Рассчитывается как отношение реализованных story points (или требований, или user stories) за несколько, например, 4-5 итераций (Sprint) к количеству выбранных итераций.

Назначение метрики: численно выразить возможности, скорость работы команды для дальнейшего планирования объема работ и анализа трендов развития

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

2. Среднее время жизни дефекта

Общее время, в течение которого были открытыми дефекты, найденные в рамках итерации или релиза к сумме дефектов.

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

• Обычно время жизни дефекта, это все время от его создания (статус Created) до закрытия (Closed) за вычетом всех возможных Postponed и Hold. Любой баг-трекер позволяет рассчитать и выгрузить данную информацию для отдельного спринта или релиза.
• Также среднее время жизни дефекта можно рассчитывать для различных модулей и функций ПО, или, что самое интересное, отдельно для каждого из тестировщиков и разработчиков из команды. Так есть шанс выявить особенно сложные модули или слабое звено в команде ПО.

Группа 4 - Качество работы команды тестирования

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

1. Эффективность тестов и тестовых наборов

Назначение метрики: показать как много ошибок в среднем позволяют обнаружить наши кейсы. Эта метрика отражает качество тест дизайна и помогает следить за тенденцией его изменения.

• Лучше всего рассчитывать данную метрику для всех наборов тестов: для отдельных групп функциональных проверок, регрессионного набора, Smoke тестирования и т.д.
• Данный показатель «убойности» тестов позволяет мониторить эффективность каждого из наборов, как она меняется с течением времени и дополнять их «свежими» тестами.

2. Коэффициент ошибок, пропущенных на продуктив

Кол-во ошибок обнаруженных после выпуска релиза \ общее кол-во ошибок в ПО обнаруженных в процессе тестирования и после выпуска

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

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

3. Реальное время работы команды QA

Отношение времени потраченного командой непосредственно на QA активности к общему кололичеству часов.

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

• Целевые активности, это анализ, дизайн, оценки, тестирование, рабочие встречи и многое другое. Возможные побочные вещи - это простой из-за блокеров, проблемы в коммуникациях, недоступность ресурсов и т.п.
• Естественно, данный коэффициент никогда не будет равен 1. Практика показывает, что для эффективных команд он может составлять 0,5-0,6.

4. Точность оценки времени по областям\видам\типам работ

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

• Степень точности оценки можно определить для всей команды или отдельных тестировщиков, для всей системы или отдельных модулей ПО.

5. Доля неподтвержденных (отклоненных) дефектов

Назначение метрики: показать сколько дефектов были заведены «вхолостую».

• Если доля дефектов, которые были отклонены превышает 20%, то в команде может наблюдаться рассинхронизация в понимании, что является дефектом, а что нет

Группа 5 - Обратная связь и удовлетворенность пользователей

И в заключение, группа метрик, показывающая, как продукт был принят конечными пользователями, насколько он соответствовал их ожиданиям. Но важна не только обратная связь о ПО: еще одна важная задача этой группы метрик - показать, удовлетворены ли пользователи процессом взаимодействия с командой ИТ в целом и QA в частности.

1. Удовлетворенность пользователей ИТ сервисом

Регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.

Назначение метрики: показать, доверяют ли пользователи команде ИТ, понимают ли, как и почему организована ее работа, насколько эта работа оправдывает ожидания.

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

2. Удовлетворенность пользователей продуктом

Регулярный опрос пользователей о том, насколько они удовлетворены продуктом.

Назначение метрики: определить, насколько разрабатываемый продукт соответствует ожиданиям пользователей, в том ли направлении мы движемся, правильно ли определяем важность фич и выбираем варианты решений.

• Для расчета этой метрики также проводим опрос пользователей и вычисляем средний балл. Рассчитывая такой показатель на регулярной основе (например, после каждого релиза) можно следить за трендом удовлетворенности пользователей.

3. Вовлеченность стейкхолдеров

Количество инициатив и предложений по улучшению процесса и продукта, поступивших в течение итерации (релиза) со стороны стейкхолдеров

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

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