- Как измеряют тестирование
- Типы метрик
- В ручном тестировании
- Другие метрики
- Жизненный цикл
- Формула
- Практический пример
Метрики тестирования — это количественные показатели, характеризующие продвижение процессов тестирования ПО, уровень качества этих процессов, и производительность QA-команды.
Предназначение метрик тестирования: повысить эффективность и результативность процессов тестирования, а также способствовать оптимизации будущего тестирования путем получения точных данных о процессе продолжающегося тестирования.
Быстрый пример:
Как оценивают тестирование
Метрики тестирования играют опорную роль в определении качества и эффективности ПО. Разработчики и тестировщики используют метрики тестирования для повышения своей производительности. Метрики тестирования дают возможность:
- Определить, какие улучшения QA-процессов понадобятся для создания бездефектного и высококачественного программного продукта.
- Анализировать ход текущих этапов тестирования, а далее вносить изменения в график проекта и финансовые планы.
- Анализировать текущие технологии и процедуры, для их совершенствования.
Типы метрик
Метрики тестирования программного обеспечения можно поделить на три категории:
- Метрики процесса: Характеристики проекта и его прогресс оцениваются метриками процесса. Эти характеристики являются критически важными для улучшения процессов в SDLC (жизненном цикле разработки).
- Метрики продукта: Объем, дизайн, производительность, качество и сложность продукта определяются метриками продукта. Опираясь на эти характеристики, разработчики повышают качество разрабатываемого ими программного обеспечения.
- Метрики проекта: Метрики проекта используются для оценки общего качества проекта. Они используются для оценки ресурсов и результатов проекта, а также для определения затрат, производительности и недостатков.
Очень важно определять соответствующие метрики тестирования для QA-процесса. Несколько моментов, которые следует иметь в виду:
- Учитывать целевую аудиторию (для кого создается метрика).
- Уточнить цель, для которой создается метрика.
- Создавайте численные измерения, исходя из особенностей проекта.
- Учитывать финансовую выгоду, связанную с каждой метрикой.
- Сопоставляйте метрики с этапами цикла.
Преимущество автоматизации заключается в том, что она позволяет тестировщикам выполнять больше тестов за меньшее время, а также и в том, что она позволяет автоматически вычислять метрики, которые было бы сложно и накладно вычислять вручную в процессе.
Метрики ручного тестирования
Ручное тестирование выполняется поэтапно. При автоматизированном тестировании для выполнения тестов используются фреймворки, вспомогательные и специализированные инструменты. Как у ручного, так и у автоматизированного тестирования есть свои преимущества и недостатки. Ручное тестирование требует больших затрат времени, но оно позволяет тестировщикам работать со сложными кейсами. Существует два вида метрик ручного тестирования:
- Базовые метрики: Аналитики собирают данные в процессе написания и выполнения тест-кейсов, чтобы получить базовые метрики. После создания отчета о состоянии проекта, эти метрики направляются QA-лидам и проджект-менеджерам. Основная количественная оценка проекта производится с помощью соотношения двух метрик:
- Общее количество тест-кейсов
- Общее количество выполненных тест-кейсов.
- Рассчитываемые метрики: Данные из базовых метрик используются для вычисления рассчитываемых метрик. QA-лид собирает информацию и преобразует ее в более наглядную для отслеживания прогресса проекта на уровне проверенных частей приложения, на уровне отдельного тестировщика и пр. Это важный аспект SDLC-цикла, поскольку он позволяет разработчикам вовремя вносить изменения в разрабатываемое ПО.
Другие важные метрики
Ниже приведены другие метрики программного обеспечения:
- Метрики дефектов (Defect metrics): помогают разработчикам понять отдельные аспекты качества ПО: функциональность, производительность, стабильность, легкость инсталляции, удобство использования, совместимость и пр.
- Соблюдение плана (Schedule Adherence): Назначение метрики — оценка разницы во времени между ожидаемым и фактическим временем выполнения плана (расписания), то есть отставание.
- Серьезность дефектов (Defect Severity): Метрика серьезности дефектов позволяет разработчикам оценить, как дефект повлияет на качество ПО.
- Эффективность тест-кейсов (Test case efficiency): — показатель того, насколько эффективно тест-кейсы выявляют дефекты.
- Коэффициент обнаружения дефектов (Defects finding rate): Используется для определения частоты обнаружения дефектов за определенный период времени.
- Время устранения дефектов (Defect Fixing Time): время, необходимое для устранения дефектов.
- Тестовое покрытие (Test Coverage): Одна из главных метрик, если не самая главная, то по крайней мере самая часто упоминаемая. Она показывает, насколько требования «покрыты» тест-кейсами. Она также помогает оценить функциональность ПО и общее качество кода.
Отдельная статья, посвященная тестовому покрытию
- Причина дефектов (Defect causes): Для выяснения причин возникновения дефектов.
Жизненный цикл тестовых метрик
Приведенная ниже диаграмма иллюстрирует этапы жизненного цикла тестовых метрик.
Этапы жизненного цикла тестовых метрик:
- Анализ:
- Метрики должны быть подобраны, исходя из особенностей проекта.
- Далее утверждены.
- Коммуникация:
- Стейкхолдеры и QA-команда поинформированы о нужных метриках.
- Лид информирует команду о данных, которые будет нужно собрать для создания метрик.
- Оценка:
- Данные собираются и проверяются.
- Собранные данные формируются в метрики.
- Отчет:
- Создается отчетность для передачи руководству проекта, в который включаются созданные метрики.
- Этот отчет (репорт) распространяется среди руководителей и стейкхолдеров.
- Сбор фидбека.
Формула вычисления тестовых метрик
Для получения процентного статуса по выполнению созданных тест-кейсов применяется следующая формула:
Процент выполненных тест-кейсов = (Количество выполненных тест-кейсов / Общее количество написанных тест-кейсов) x 100
Аналогичным образом можно рассчитать и другие метрики: невыполненных тест-кейсов, прошедших и упавших тест-кейсов, блокированных по какой-то причине и т.д.
- Эффективность тест-кейсов (Test Case Effectiveness):
Эффективность тест-кейсов = (Количество обнаруженных дефектов / Количество выполненных тест-кейсов) x 100
- Процент прошедших тест-кейсов (Passed Test Cases Percentage) — показывает процентаж успешно выполненных тест-кейсов.
Процент прошедших тест-кейсов = (Общее количество прошедших тест-кейсов / Общее количество выполненных) x 100
- Процент упавших тест-кейсов (Failed Test Cases Percentage): показывает процент упавших/красных тест-кейсов.
Процент упавших тест-кейсов = (Общее количество упавших тест-кейсов / Общее количество выполненных) x 100
- Процент блокированных тест-кейсов (Blocked Test Cases Percentage): показывает процент заблокированных тест-кейсов.
Процент блокированных тест-кейсов = (Количество заблокированных тест-кейсов / Общее количество выполненных) x 100
- Процент исправленных дефектов (Fixed Defects Percentage): С помощью этого показателя команда видит процент исправленных дефектов.
Процент исправленных дефектов = (Общее количество исправленных дефектов / Количество заявленных дефектов) x 100
- Коэффициент трудоемкости (Rework Effort Ratio): коэффициент трудоемкости (подразумеваются доработки тест-кейсов).
Коэффициент трудоемкости = (Фактические усилия по доработке, затраченные на данном этапе / Общие фактические усилия, затраченные на данном этапе) x 100
- Процент принятых дефектов (Accepted Defects Percentage): измеряется процент дефектов, которые были приняты, от общего числа дефектов.
Процент принятых дефектов = (Дефекты, принятые dev-командой как достоверные / Общее количество дефектов, о которых было сообщено тестировщиками) x 100
- Процент отложенных дефектов (Defects Deferred Percentage): измеряется процент дефектов, исправление которых отложено на будущий релиз.
Процент отложенных дефектов = (Дефекты, отложенные на будущие релизы / Общее количество заявленных дефектов) x 100
Практический пример
Рассмотрим пример расчета тестовых метрик в проекте:
| Номер метрики | Метрика | Данные, полученные в ходе написания и выполнения тест-кейсов |
|---|---|---|
| 1 | Количество требований | 5 |
| 2 | Среднее количество написанных тест-кейсов на одно требование | 40 |
| 3 | Общее количество тест-кейсов, написанных для всех требований | 200 |
| 4 | Общее количество выполненных тест-кейсов | 164 |
| 5 | Количество зеленых тест-кейсов | 100 |
| 6 | Количество красных тест-кейсов | 60 |
| 7 | Количество заблокированных тест-кейсов | 4 |
| 8 | Количество невыполненных тест-кейсов | 36 |
| 9 | Общее количество выявленных дефектов | 20 |
| 10 | Дефекты, принятые дев-командой | 15 |
| 11 | Дефекты, отложенные на будущие релизы | 5 |
| 12 | Исправлено дефектов | 12 |
- Процент выполненных тест-кейсов = (Количество выполненных тест-кейсов / Общее количество написанных) x 100
= (164 / 200) x 100
= 82
- Эффективность тест-кейсов = (Количество обнаруженных дефектов / Количество выполненных тест-кейсов) x 100
= (20 / 164) x 100
= 12.2
- Процент упавших тест-кейсов = (Общее количество упавших тест-кейсов / Общее количество выполненных) x 100
= (60 / 164) * 100
= 36.59
- Процент заблокированных тест-кейсов = (Общее количество заблокированных тестов / Общее количество выполненных тестов) x 100
= (4 / 164) * 100
= 2.44
- Процент исправленных дефектов = (Общее количество исправленных дефектов / Количество заявленных дефектов) х 100
= (12 / 20) * 100
= 60
- Процент принятых дефектов = (Дефекты, принятые командой разработчиков как достоверные / Общее количество заявленных дефектов) x 100
= (15 / 20) * 100
= 75
- Процент отложенных дефектов = (Дефекты, отложенные для будущих релизов / Общее количество отложенных дефектов) x 100
= (5 / 20) * 100
= 25
