В подборке данных статей мы с вами поговорим:
- узнаете, что такое метрики в тестировании и какие они бывают;
- познакомитесь с метриками покрытия кода;
- узнаете, на основании каких критериев принимаются решения в тестировании;
- поймёте, какие отчёты могут использоваться на проектах для анализа результатов тестирования.
В тестировании очень важно контролировать и оценивать текущую ситуацию. Для этого нужны определённые расчётные показатели, которые устанавливаются ещё до начала тестирования. Эти показатели могут быть описаны в тест-плане или в другом документе, который используется в качестве тестовой документации на проекте.
Виды метрик
Понятие «метрика» чаще всего используется в тестировании для определения таких показателей.
Метрики — это числовые характеристики показателя качества. Они позволяют получить численное значение некоторого свойства ПО или его спецификаций. Также метрики служат показателем текущего достижения поставленных целей.
Метрики могут быть двух видов:
- Прямые — их определяют без вычислений. К ним относятся, например, количество разработанных тест-кейсов, количество найденных дефектов, время прохождения тест-кейсов.
- Расчётные — вычисляются по специальным формулам, которые включают прямые метрики. Они показывают, например, процентное отношение выполненных или невыполненных тест-кейсов ко всем имеющимся, процент успешного прохождения тест-кейсов, плотность распределения дефектов, эффективность устранения дефектов, распределение дефектов по важности и срочности.
Для определения расчётных метрик важно учитывать статус тест-кейсов (passed, failed, blocked), который отражает успешность их выполнения. На основе этих статусов можно вычислить множество метрик.
Выбор конкретных метрик зависит от проекта и тестируемого продукта. Каждая команда тестирования самостоятельно решает, какие метрики использовать. Это решение основывается на целях и специфике проекта, а также на степени формализованности процесса тестирования.
1. Процент выполнения тест-кейсов показывает, насколько эффективно идёт процесс тестирования. Эта метрика рассчитывается как отношение количества выполненных тест-кейсов к общему количеству запланированных тест-кейсов, умноженное на 100 %.
Эта ключевая метрика позволяет отслеживать прогресс тестирования, сравнивать его с планом и при необходимости корректировать работу тестировщиков.
2. Процент успешных тест-кейсов показывает, насколько качественно было протестировано приложение. Эта метрика рассчитывается как отношение количества успешно выполненных тест-кейсов к общему количеству выполненных тест-кейсов, умноженное на 100 %.
Эта метрика позволяет оценить качество приложения. Если доля неуспешных или заблокированных тест-кейсов высокая, это может свидетельствовать о некачественном коде. В этом случае может потребоваться внесение изменений в процесс разработки, внедрение каких-либо инструментов, практики взаимных проверок.
3. Общее количество найденных дефектов — это число всех дефектов, обнаруженных за всё время тестирования.
Эту метрику можно представить с разбивкой по степени важности, срочности или по модулям, где были найдены дефекты.
4. Текущее количество дефектов — это число дефектов, обнаруженных в текущем билде, итерации или спринте.
Эта метрика позволяет всем участникам проекта быть в курсе текущей ситуации с качеством продукта, а также анализировать изменения: улучшается или ухудшается код, процесс разработки и качество тест-кейсов.
5. Общее устранение дефектов — это процентный показатель устранения дефектов определённого уровня важности за всё время существования проекта. Он показывает, сколько всего дефектов было исправлено за время разработки и тестирования.
6. Текущее устранение дефектов — это процентный показатель устранения в текущем билде или итерации дефектов определённого уровня важности, обнаруженных в предыдущем билде или итерации.
Иными словами, когда выходит новая версия продукта или стартует новая итерация, нужно различать дефекты, обнаруженные в предыдущей версии, и дефекты, обнаруженные в актуальной версии.
7. Плотность дефектов — это количество дефектов на единицу размера: на весь продукт, спринт, функцию или объём исходного кода.
Этот показатель помогает выделить наиболее уязвимые модули и участки кода, в которых плотность дефектов выше, чем в других частях продукта.
8. Коэффициент ретеста дефектов показывает, какую часть времени в тестировании занимает перепроверка исправленных дефектов.
Проверка того, что дефект исправлен, требует времени. Важно, чтобы большая часть рабочего времени тестировщиков не уходила на ретесты вместо проверки новой функциональности.
- 1 вариант — количество закрытых дефектов / количество новых дефектов (в новом функционале);
- 2 вариант — затраченное время на ретест / затраченное время на тестирование нового функционала.
Если времени на перепроверку исправленных дефектов уходит больше, чем на тестирование новой функциональности, это может свидетельствовать о большом количестве дефектов. В таком случае необходимо принять меры для улучшения качества кода.
9. Коэффициент регрессии:
- 1 вариант — количество дефектов в старом функционале / количество дефектов в новом функционале;
- 2 вариант — количество тест-кейсов в статусе failed / количество тест-кейсов в регрессионном наборе.
Важно отслеживать, сколько дефектов появляется в уже протестированном функционале при добавлении новых функций. Это может указывать на низкое качество разработки и необходимость принятия мер для улучшения процесса разработки.
10. Стоп-фактор — это решение о приостановке тестирования. При этом учитываются текущее значение метрик, выполнение и успешное прохождение тест-кейсов.
Если процент успешно выполненных тест-кейсов низок — а какой процент считать низким, каждый проект определяет самостоятельно — тестирование может быть приостановлено до исправления дефектов.
Например, если из 100 запланированных к выполнению в итерации тест-кейсов было выполнено 40, из которых 29 оказались неудачными, менеджер проекта может решить приостановить тестирование до устранения наиболее критичных дефектов. Продолжение тестирования без их исправления приведёт только к увеличению количества дефектов, на исправление которых у разработчиков не будет времени.
Далее мы рассмотрим метрики, связанные с тестовым покрытием, поэтому сначала разберёмся с этим понятием.
Покрытие (или тестовое покрытие) — это процентное выражение степени, в которой исследуемый элемент (требование или строка кода) затронут соответствующим набором тест-кейсов.
Тестовое покрытие — одна из метрик оценки качества тестирования. Оно показывает плотность покрытия тестами требований или программного кода. Тестовое покрытие обычно выражается в процентах.
Термины «покрытие» и «тестовое покрытие» могут использоваться как синонимы.
Метрики, связанные с покрытием:
- Метрики покрытия кода модульными тест-кейсами позволяют определить, какой процент кода покрывается тестами. Это может быть количество строк, ветвей, путей или условий.
- Метрика покрытия требований означает, что требование считается покрытым, если на него ссылается хотя бы один тест-кейс.
- Метрика плотности покрытия требований учитывает, сколько тест-кейсов ссылается на несколько требований.
В следующей статье вы узнаете о Метриках покрытия кода.
Если у вас есть вопросы или вы просто хотите стать частью команды тестировщиков, то переходи в ТГ канал, где можем пообщаться с единомышленниками и найти много интересных и полезных знаний!Также если вам нужна индивидуальная консультация, менторство и помощь в создании проекта пишите в ТГ канал!