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

Метрика тестирования (test metric) - мера, которая количественно описывает свойство тестирования или тестируемого продукта: ход выполнения, число и серьёзность дефектов, покрытие, затраты. Метрики вычисляют из данных, которые создаёт тестирование (результатов тестовых прогонов, отчётов о дефектах, связей с требованиями), и используют для мониторинга тестирования, проверки критериев выхода и принятия решений о релизе.

Силлабус ISTQB Foundation Level (версия 4.0.1, раздел 5.3.1) делит метрики тестирования на категории и называет типичные примеры в каждой. Международный стандарт документации тестирования ISO/IEC/IEEE 29119-3 (текущая редакция 2021 года) включает показатели в отчёт о состоянии тестирования и отчёт о завершении тестирования, но не предписывает, какие именно использовать. Выбор метрик, их определения и пороговые значения задают организация и проект.

Зачем нужны метрики тестирования

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

Силлабус ISTQB связывает метрики с мониторингом и контролем тестирования. Мониторинг сравнивает фактическое состояние тестирования с планом, контроль принимает меры при расхождении. Метрики - средство сравнения: «выполнено 120 из 300 запланированных тест-кейсов, осталось три дня» - факт, на котором можно основать решение, «тестирование идёт хорошо» - нет.

Метрика отвечает на определённый вопрос. Вопросы, которые чаще всего задают во время тестирования:

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

Категории метрик

Силлабус ISTQB называет семь категорий метрик:

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

Доля пройденных тестов

Доля пройденных тестов (pass rate) - доля пройденных тест-кейсов. Её вычисляют для тестового прогона, набора прогонов или релиза:

pass rate = passed / denominator x 100%

Значение зависит от знаменателя, и используют три: все запланированные тест-кейсы прогона, выполненные тест-кейсы или тест-кейсы, которые дошли до вердикта (пройден или не пройден). Для прогона из 200 запланированных тест-кейсов, из которых 150 пройдены, 10 не пройдены, 15 заблокированы и 25 ещё не выполнялись:

Один и тот же прогон даёт 75, 86 или 94 процента. Долю пройденных тестов без знаменателя интерпретировать нельзя.

Где доля пройденных тестов вводит в заблуждение:

• Одинаковый вес. Все тест-кейсы считаются одинаково. Прогон, где проходят 199 косметических проверок и не проходит проверка оплаты, даёт 99,5 процента.
• Зависимость от числа тестов. Добавление множества простых тест-кейсов, которые всегда проходят, поднимает долю без изменения продукта.
• Невыполненные тесты. Если заблокированные и невыполненные тест-кейсы исключить из знаменателя, прогон, в котором половину тестов не удалось выполнить, всё равно может показать высокую долю.
• Повторные выполнения. Если автотесты перезапускают, пока они не пройдут, и учитывают только последнюю попытку, доля скрывает нестабильные тесты и плавающие дефекты.

Доля пройденных тестов информативна вместе с числом непройденных и заблокированных тест-кейсов и списком непройденных тест-кейсов с высоким приоритетом.

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

Плотность дефектов (defect density), в формулировке глоссария ISTQB, - число дефектов на единицу размера рабочего продукта:

defect density = number of defects / size

Размер измеряют в единицах, подходящих рабочему продукту: тысячах строк кода (KLOC), функциональных точках, числе требований, страницах спецификации. Для двух компонентов:

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

Где плотность дефектов вводит в заблуждение:

• Она считает найденные дефекты, а не существующие. У компонента, который тестировали меньше, найдено меньше дефектов, и плотность ниже. Низкая плотность может означать высокое качество, а может - мало тестирования.
• Она зависит от правил подсчёта. Учитываются ли отклонённые отчёты, дубликаты и дефекты всех уровней серьёзности - от этого меняется число. Правила фиксируют до сравнения.
• Она зависит от меры размера. Строки кода различаются между языками и стилями; одна и та же функциональность может занимать 2 KLOC на одном языке и 6 KLOC на другом.
• Она не учитывает серьёзность. Десять косметических дефектов и десять дефектов с потерей данных дают одинаковую плотность.

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

Дефекты в эксплуатации

Долю дефектов, которые тестирование не нашло до релиза, измеряет процент обнаружения дефектов (defect detection percentage, DDP). Глоссарий ISTQB определяет его как число дефектов, найденных уровнем тестирования, делённое на число дефектов, найденных этим уровнем и любыми другими способами после него:

DDP = defects found by testing / (defects found by testing + defects found later) x 100%

Дополняющее значение - долю дефектов, найденных после релиза, - часто называют утечкой дефектов (defect leakage) или пропущенными дефектами (escaped defects). Для релиза, в котором тестирование нашло 85 дефектов, а пользователи за первые 90 дней сообщили ещё о 15:

DDP = 85 / (85 + 15) x 100% = 85%
defects found in production = 15 / 100 x 100% = 15%

Где эта метрика вводит в заблуждение:

• Значение меняется со временем. Дефекты после релиза продолжают приходить месяцами. DDP, посчитанный через неделю после релиза, выше того же DDP через полгода. Окно («первые 90 дней») - часть определения.
• Нужно определение «того же» дефекта. Сообщение пользователя, которое оказалось известным дефектом, отложенным до релиза, - не пропущенный дефект. Без этого правила осознанные решения считаются провалами тестирования.
• Серьёзность важнее числа. Пятнадцать косметических дефектов в эксплуатации и один дефект, из-за которого с клиентов списывают деньги дважды, дают совсем разную картину релиза. DDP часто считают отдельно для серьёзных дефектов.
• Она зависит от того, как сообщают пользователи. Продукт с небольшим числом активных пользователей или без канала для сообщений показывает мало дефектов в эксплуатации независимо от качества.

DDP измеряет тестирование в целом, а не отдельных тестировщиков. Он зависит и от качества кода, который дошёл до тестирования, и от того, что входило в объём тестирования.

Время на исправление

Время на исправление (time to fix) дефекта - время от регистрации дефекта до его устранения. Для набора дефектов его вычисляют как среднее или медиану. Что значит «устранён», определяют явно: исправление влито в код, исправление подтверждено тестированием или отчёт закрыт.

Среднее и медиана расходятся, когда есть выбросы. Для десяти дефектов, исправленных за 1, 1, 2, 2, 2, 3, 3, 4, 5 и 47 дней:

mean   = (1 + 1 + 2 + 2 + 2 + 3 + 3 + 4 + 5 + 47) / 10 = 7 days
median = (2 + 3) / 2 = 2.5 days

Один дефект, который ждал 47 дней, сдвигает среднее примерно с 2,6 дня (для остальных девяти) до 7 дней. Медиана описывает типичный случай, среднее чувствительно к долгим ожиданиям, и оба информативны вместе со списком дефектов, которые заняли больше всего времени.

Где эта метрика вводит в заблуждение:

• Отложенные и переоткрытые дефекты. Дефект, намеренно отложенный до следующего релиза, накапливает время, хотя с ним никто не работает. Переоткрытый дефект можно считать от первой регистрации или от переоткрытия. Правила фиксируют заранее.
• Серьёзность. Критические дефекты обычно исправляют первыми. Среднее по всем уровням серьёзности смешивает совсем разные очереди. Метрику считают отдельно по серьёзности или приоритету.
• Дробление. Закрыть отчёт и открыть новый на оставшуюся часть проблемы - значит сократить измеряемое время, не ускорив исправление.

Время на исправление дефекта, найденного при тестировании, - другая метрика, чем время восстановления после сбоя в эксплуатации. Программа DevOps Research and Assessment (DORA) измеряет последнее как время восстановления после неудачного развёртывания (failed deployment recovery time); с 2023 года это название заменяет прежнее «среднее время восстановления» (mean time to recover).

Как метрики вводят в заблуждение

Примеры выше объединяют общие закономерности.

Метрика становится целью. Экономист Чарльз Гудхарт в 1975 году описал, как статистический показатель перестаёт быть надёжным, когда его используют как цель управления. Антрополог Мэрилин Стратерн в 1997 году обобщила это наблюдение на меры вообще: мера, которая становится целью, перестаёт быть хорошей мерой. В тестировании цель «доля пройденных тестов выше 95 процентов» подталкивает убирать непроходящие тесты из прогонов, цель «мало дефектов в эксплуатации» - относить дефекты из эксплуатации к запросам на изменение.

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

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

Абсолютные значения вместо динамики. Плотность 3 дефекта на KLOC сама по себе говорит мало. Тот же компонент, у которого плотность выросла с 1,5 до 3 между релизами, говорит больше. Многие метрики информативны как ряд по релизам, а не как одно значение.

Метрики тестирования и метрики поставки

Метрики тестирования описывают тестирование и продукт, каким его увидело тестирование. Метрики поставки описывают, как изменения попадают в эксплуатацию. Программа DORA, которая изучает эффективность поставки программного обеспечения, с 2024 года использует пять таких метрик: время выполнения изменения (change lead time), частоту развёртываний (deployment frequency), время восстановления после неудачного развёртывания (failed deployment recovery time), долю неудачных изменений (change fail rate) и долю развёртываний для исправлений (deployment rework rate).

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

Термины

Источники

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1, ISTQB, 2024(откроется в новой вкладке) (на английском)
• Глоссарий ISTQB(откроется в новой вкладке) (на английском)
• ISO/IEC/IEEE 29119-3:2021, Software testing, Part 3: Test documentation(откроется в новой вкладке) (на английском)
• A history of DORA's software delivery metrics, DORA(откроется в новой вкладке) (на английском)
• «Improving ratings»: audit in the British University system, M. Strathern, European Review, 1997(откроется в новой вкладке) (на английском)