QA Метрики

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

Что такое метрика?

Метрика (Metric) — Это шкала измерений и метод, используемый для измерений [ISO 14598].

Чаще всего метрики показывают либо результат, либо прогноз чего-либо, основанных на каких-то данных нашего проекта.

А зачем они нужны?

Я думаю многие из вас сталкивались с ситуациями когда:

• Проект отстаёт от графика, но всем всё равно
• Мы поздно понимаем, что нам не хватает времени на тестирование
• Непонятно, когда нужно остановить тестирование и готов ли продукт к релизу
• Непонятно стал ли лучше наш продукт, чем раньше
• Заказчику непонятна эффективность тестирования

и многое-многое другое.

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

Часто говорят, что тестировщик ответственнен за качество продукта. Но как он может за что-то отвечать если он ничего не может сделать с этим продуктом?

Задача тестировщика — предоставить информацию о качестве продукта и о других аспектах нашего проекта, которые могут влиять на качество.

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

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

Определение метрик обычно происходит на этапе планирования тестирования и контроля.

Какие метрики можно выделить?

Метрики ради метрик на самом деле бесполезны. Поэтому очень важно выбрать правильные метрики.

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

Ниже мы рассмотрим то, какие различные варианты метрик.

• Метрики результатов (Result Metrics) обычно показывают абсолютные показатели какого-то завершенного процесса.
  • Например: Number of test cases passed, который показывает количество тест-кейсов, которые пройдены успешно.
• Метрики прогнозов (Predictive Metrics) обычно являются производными и предупреждают о неблагоприятном результате
  • Например: Passed test cases percentage, который показывает отношение количества тест-кейсов пройденных успешно к общему количеству пройденных тест-кейсов. Если этот процент будет уменьшаться, то мы будем предупреждены о возможном уменьшении качества.

Все QA метрики делятся на 4 группы: Product, Project, Process и People.

• Продуктовые метрики (Product metrics) — Метрики, которые показывают качество разрабатываемого продукта.
• Проектные метрики (Project metrics) — Метрики, которые показывают, то на сколько наш проект близок к релизу.
• Процессные метрики (Process metrics) — Метрики, которые показывают качество какого-то процесса.
• Персональные метрики (People metrics) — Метрики, которые показывают производительность отдельного человека или же команды.

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

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

Рассмотрим их немного подробнее.

Product metrics (Метрики продукта)

Название	Описание/Формула
Number of test cases passed	Количество тест кейсов пройденных успешно.
Passed test cases percentage	Процент тестов пройденных успешно. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Passed \ Tests}{Number \ Of \ Executed \ Tests} \times 100[/latex]
Number of test cases failed	Количество тест кейсов пройденных неуспешно.
Failed test cases percentage	Процент тестов пройденных неуспешно. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Failed \ Tests}{Number \ Of \ Executed \ Tests} \times 100[/latex]
Number of test cases failed	Количество тест кейсов, которые заблокированы дефектами.
Blocked test cases percentage	Процент тестов, которые заблокированы дефектами. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Blocked \ Tests}{Number \ Of \ Executed \ Tests} \times 100[/latex]
Number of defects found	Количество дефектов, найденных за какой-то период.
Number of opened defects	Количество открытых дефектов на данный момент.
Number of critical defects	Количество открытых дефектов с Severity = Critical Вместо Critical можно использовать и другие Severity. Например, вместе с Number of critical defects можно использовать метрику Number of major defects
Critical defects percentage	Процент открытых дефектов с Severity = Critical. Вместо Critical можно использовать и другие Severity. Например, вместе с Critical defects percentage можно использовать метрику Major defects percentage. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Critical \ Defects }{Number \ Of \ Opened \ Defects} \times 100[/latex]
Defect distribution	Показывает распределение дефектов по различным параметрам. Варианты могут быть следующие: Defect distribution by Severity Defect distribution by Priority Defect distribution by Type (functional, security, GUI and etc) Defect distribution by cause (data, coding logic, 3rd party system/tool, Environmental and etc) Defect distribution by feature/functional area Чаще всего эти метрики представлены в виде графика или таблицы.

Project metrics (Метрики проекта)

Название	Описание/Формула
Number of planned test hours	Количество часов запланированных на тестирование.
Number of actual test hours	Актуальное количество часов потраченное на тестирование.
Executed tests	Процент пройденных тестов. Чем больше процент, тем ближе мы к окончанию тестирования. [latex size=2 color=000000 background=ffffff] \frac{Number\ Of\ Test \ Run}{Number \ Of \ Tests \ To \ Be \ Run} \times 100[/latex]
Burndown chart	Это графическое представление того, сколько работы уже сделано и сколько еще остается сделать.

Process metrics (Метрики процесса)

Метрики для оценки эффективности процесса тестирования:

Название	Описание/Формула
Number of defects rejected	Количество дефектов, которые были отклонены по причине того, что описанное поведение является ожидаемым для программы.
Defect rejected (declined) percentage	Процент дефектов, которые были отклонены по причине того, что описанное поведение является ожидаемым для программы. [latex size=2 color=000000 background=ffffff] \frac{Defects\ Accepted \ As\ Valid}{Number \ Of \ Defects \ Found } \times 100[/latex]
Number of bugs found after shipping	Количество дефектов, которые были найдены пользователями после релиза.
Defect containment efficiency	Эффективность нахождения дефектов перед релизом. Считается после релиза. Показывает отношение дефектов, найденных командой тестирования к общему количеству найденных дефектов (пользователями\заказчиком +количество дефектов, найденных командой тестирования). Чем выше процент, тем меньше дефектов у нас в продакшене. Невалидные дефекты не учитываются в этой метрике. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Defects \ found}{ Number \ Of \ Defects \ found + Number of bugs found after shipping} \times 100 [/latex]
Defect leakage	Противоположная с Defect containment efficiency метрика. Показывает процент дефектов, которые находятся пользователем. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Defects \ found + Number of bugs found after shipping}{Number \ Of \ Defects \ found} \times 100 [/latex]
Requirements coverage (Test coverage)	Процент требований, которые покрыты тестами. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Requirements \ Covered}{Total \ Number \ Of \ Requirements} \times 100 [/latex]
Number of requirements without tests	Количество требований без тестов.
Requirements coverage (Test coverage) density	Плотность тестового покрытия. Показывает минимальное количество тестов, которое написано для одного требования.
Test design efficiency	Среднее время на создание одного тест-кейса, которое показывает на сколько эффективно мы создаём их: [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Test \ Cases \ Designed}{Total \ Time}[/latex]
Number of tests run per period	Среднее время на прохождение теста. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Tests \ Run\ Per \ Period}{Total \ Time}[/latex]
Bug find rate	Среднее время нахождения одного бага. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Defects \ found\ Per \ Period}{Total \ Time}[/latex]
Number of bugs per test	Отношение общего количества багов в продукте к общему количеству тестов. Если результат больше 1, то это означает, что наши тесты не находят дефекты. Соответственно этот элемент процесса тестирования работает неэффективно. [latex size=2 color=000000 background=ffffff] \frac{Total \ Number \ Of \ Defects }{Total \ Number \ Of \ Test \ Cases}[/latex]

Автоматизация тестирования:

Многие из вас слышали про такой показатель, как ROI (Return of Investments).
По сути ROI это:

[latex size=2 color=000000 background=ffffff] ROI = \frac{(Cost \ Of \ Manual \ Testing \textendash Cost \ Of \ Automated \ Testing)}{Cost \ Of \ Automated \ Testing}[/latex]

Но как именно оценить эффективность автоматизированного тестирования?

В этом нам помогут метрики, показывающие эффективность процесса автоматизации тестирования:

Название	Описание/Формула
Number of defects found by automated testing	Число дефектов, найденных автоматизацией.
Percentage of defects found by automated testing (Automation Script Effectiveness)	Процент дефектов, найденных автоматизацией. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Defects \ Found \ By \ Automated \ Testing}{Number \ Of \ Defects \ Found} \times 100 [/latex]
Automation execution time	Время потраченное на выполнение всех автоматических тестов.
Automation test coverage	Процент тестов, которые заавтоматизированы. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Automated \ Tests}{Total \ Number \ Of \ Tests} \times 100 [/latex]
Percentage of irrelevant results	Процент тестов, которые прошли неуспешно, но не являются багами в продукте. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Invalid \ Failed \ Tests}{Total \ Number \ Of \ Failed \ Tests} \times 100 [/latex]
Percentage of useful results	Процент тестов, которые прошли неуспешно в связи с дефектом в продукте. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Valid \ Failed \ Tests}{Total \ Number \ Of \ Failed \ Tests} \times 100 [/latex]

Метрики, показывающие эффективность процесса разработки:

Название	Описание/Формула
Reopen rate	Процент дефектов, которые были переоткрыты. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Reopened \ Defects}{Number \ Of \ Defects \ Resolved} \times 100 [/latex]
Defect Injection Rate	Среднее количество найденных дефектов на одно изменение (новый функционал, багфикс). [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Defects\ Found}{Number \ Of \ Changes}[/latex]
Defect removal efficiency (Created VS resolved)	Отношение всех валидных дефектов в нашем продукте ко всем исправленным дефектам. Показывает то, на сколько хорошо и быстро исправляются дефекты. Результат должен стремиться к 1. [latex size=2 color=000000 background=ffffff] \frac{Total \ Number \ Of \ Defects\ Found}{Total \ Number \ Of \ Resolved \ Defects}[/latex] Может быть выражен графиком:
Build Stability	Процент сборок, которые не смогли собраться в CI/CD. [latex size=2 color=000000 background=ffffff] \frac{Number \ Of \ Builds \ failures}{Total \ Number \ Of \ Builds} \times 100 [/latex]

People metrics (Персональные метрики)

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

Project metrics by person:

Executed tests by person — где измеряется процент выполненных тестов каждым тестировщиком.

Process metrics by person:

Defect rejected (declined) percentage by person — Процент дефектов, которые были внесены в баг трекер конкретным человеком и которые были отклонены по причине того, что описанное поведение является ожидаемым для программы.

Подводя итог

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

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

Сбор метрик без их анализа — это пустая трата времени.