Что такое метрики в тестировании

Выбор правильных метрик тестирования программного обеспечения

Метрика тестирования программного обеспечения — это критерий для отслеживания эффективности усилий по обеспечению качества. Сначала вы устанавливаете показатели успеха на этапе планирования. Затем сравниваете их с полученной метрикой после завершения процесса.

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

В статье Алекса Хусара (Alex Husar) будут обсуждаться пять метрик тестирования программного обеспечения, которые могут помочь специалистам по контролю качества в оценке их успеха.

Характеристики «хорошей» метрики тестирования

Давайте поговорим о функциях, которые метрика должна иметь в идеале.

Соответствие бизнес-целям

Критические KPI должны отражать основную миссию и цель бизнеса; например, ежемесячный рост выручки или количество новых пользователей. Каждая компания выбирает свои показатели на основе того, чего они намерены достичь с помощью своего продукта. Хотя может показаться привлекательным преуспеть во всех тестах, сосредоточение внимания на неправильных целях может быть обманчивым. Это может повлиять на работу приложения и всю сложную систему, такую как headless commerce architecture.

Позволяет расти

Каждая метрика должна допускать возможность улучшения. Что, если вы достигли 100-процентного уровня успеха? Целью может быть сохранение этого показателя на этом уровне или его дальнейшее улучшение.

Поощряет разработку стратегии

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

Отслеживаемая и понятная

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

Если ваша система доставки не дает тех результатов, на которые вы рассчитываете, и вы хотели бы изучить проверенную дорожную карту для оптимизации рабочих процессов с целью повышения их предсказуемости, мы будем рады приветствовать вас на нашем курсе «Flow Metrics: управление потоковым производством на основе данных»!

Три совета по выбору и измерению метрик тестирования программного обеспечения

1. Начните с вопросов

Ваши вопросы должны охватывать три темы:

1. Что вы измеряете
2. Стратегии и инструменты для его измерения
3. Причины для отслеживания

Чтобы избежать анализа бесполезных метрик, обратите внимание на процесс определения метрик. Иногда небольшое количество ошибок в бэклоге означает, что ваша команда QA (quality assurance) выполняет свою работу. Однако, когда вы разделите эти ошибки на проблемы с высоким/средним/низким приоритетом, вы сможете лучше увидеть общее качество программы и внести необходимые коррективы.

2. Не пренебрегайте автоматизацией при расчете метрик QA

Автоматизация экономит время на ручной сбор данных и помогает обеспечить постоянную актуальность ваших показателей. Предположим, вы используете Jira. Настройте запрос Jira Query Language (JQL) на вашей странице Confluence, если вам нужны данные о критических ошибках каждый спринт. Они будут часто обновляться. Или вы можете использовать другие инструменты, основываясь на предпочитаемой системе управления тестированием/отслеживания задач.

3. Собирайте комментарии и постепенно улучшайте метрики

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

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

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

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

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

2. Метрики процесса

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

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

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

3. Метрики покрытия

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

В эту группу входят такие метрики, как:

• Процент покрытия требований
• Покрытие модульных тестов
• Покрытие ручных или исследовательских тестов
• Тестовые случаи по категориям требований
• Покрытие тестов пользовательского интерфейса
• Покрытие интеграционных и API тестов

4. Метрики качества кода

Оценка качества кода означает разделение ценности кода на две категории: Хороший и плохой. Единого понятия качества не существует, потому что практически каждый разработчик сам определяет, что такое хороший код. Как вы можете оценить качество кода? Такие инструменты, как SonarQube, позволяют определить, сколько технического долга имеется в системе. Вам необходимо классифицировать проблемы и уязвимости, упорядочить их по приоритетности и выбрать, на чем вы собираетесь сосредоточиться.

5. Метрики ошибок или инцидентов

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

Что можно извлечь из отчетов о происшествиях? Эти результаты могут включать в себя:

• Общее количество ошибок
• Открытые дефекты
• Закрытые дефекты
• Время закрытия каждого отчета об инциденте
• Изменения с момента последнего релиза

Если ваша система доставки не дает тех результатов, на которые вы рассчитываете, и вы хотели бы изучить проверенную дорожную карту для оптимизации рабочих процессов с целью повышения их предсказуемости, мы будем рады приветствовать вас на нашем курсе «Flow Metrics: управление потоковым производством на основе данных»!

Правила измерения метрик тестирования программного обеспечения

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

1. Соотносите свои метрики с целями проекта, процесса и продукта. Помните, что одного показателя недостаточно для полного представления о качестве программного обеспечения.
2. Отслеживайте прогресс (или регресс) в течение времени. Оптимизируйте процесс сбора данных с помощью автоматизации, храните данные в ресурсах для совместной работы, таких как Wiki/Confluence, и регулярно анализируйте результаты.
3. Сообщайте статистику заказчику и команде, чтобы продемонстрировать свой прогресс. Отчеты должны быть простыми для понимания, поэтому делайте их полезными и удобными для пользователя.
4. Проверяйте достоверность метрик. Об отслеживании неактуальных метрик и отображении неточных данных не может быть и речи.

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

Как вы можете контролировать свою деятельность по тестированию? Вам необходимо определить соответствующие метрики тестирования программного обеспечения. Выбрать правильные метрики тестирования может быть непросто. Часто команды выбирают метрики, которые не синхронизированы с общим бизнесом.

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

Также по теме:

• 3 совета по улучшению управления лицензиями программного обеспечения
• Цепочки поставки программного обеспечения
• Простые уловки, как ускорить процесс разработки программного обеспечения
• Автоматизация тестирования: что можно, а что не нужно
• Медленное движение «влево» в автоматизации тестирования

Портал TMGuru:

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

В процессе разработки программного обеспечения метрики используются:

• Для контроля над процессом разработки в целом, а в тестировании в частности
• Для оценки прогресса выполнения работ по тестированию ПО
• Для последующего планирования процессов.

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

Виды метрик

Измеримые (представленные в виде цифр, процентных соотношений) и субъективные (оценки отдельных людей, выраженные мнением «хорошо» / «плохо», «удалось» / «не удалось»). Данные метрики характеризуются значительной неточностью, поскольку цифры при неправильном применении могут быть отдалены от реальности и не выражать в полной мере актуальную картину, а оценки отличаются чрезмерным субъективизмом.

Финальные (получаемые после релиза продукта) и косвенные (прогнозируемые до релиза).

Процессные и результатные.

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

количеству ошибок — общее количество (например, для сравнения различных версий продукта) или же их распределение по приоритетам (способствует пониманию, в каких модулях содержится наибольшее количество ошибок, а также в каких наиболее критичные из них)

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

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

скорости тестирования одной сборки, полного тестового цикла, скорости внесения критических ошибок программного продукта в баг-трекинговую систему

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

Метрики могут быть представлены:

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

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

Доклады с конференций по данной теме, доступные для просмотра:

• Способы оценки эффективности тестирования
• Метрики в тестировании. Практические советы
• Waterfall revisited: практические метрики тестирования
• Количественное управление процессом тестирования
• Простые метрики тестирования на практике

Метрики тестирования, которые вы точно должны внедрить в процесс

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

Для чего нужно снимать метрики

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

В процессе тестирования метрики используются:

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

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

Какие метрики чаще всего упоминаются в статьях по тестированию

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

Passed/Failed Test Cases. Используется для оценки отношения удачно пройденных тестов к завершившимся с ошибками. Метрика помогает оценить успешность прохождения тестов.

Not Run Test Cases. Демонстрирует количество тестов, которые нужно выполнить для данного проекта. Метрика помогает определить причины невыполнения тестов и способы их устранения.

Open/Closed Bugs. Формируется из отношения открытых багов к закрытым. Метрика оценивает скорость устранения багов, а также позволяет выявить причины, по которым ошибки остались незакрытыми.

Reopened/Closed Bugs. Рассчитывает соотношение переоткрытых багов к закрытым. Метрика демонстрирует эффективность закрытия бага разработчиками и поможет выявить причины, по которым исправление ошибок находится на низком уровне.

Bugs by Severity/Priority. Общее количество багов по серьёзности/приоритету. Метрика показывает качество предоставляемого кода на тестирование.

Какие метрики необходимо снимать дополнительно?

Кроме стандартных метрик, в «Иннотех» используется ещё и ряд дополнительных. Они позволяют получить объективную картину процесса.

Покрытие тестовыми сценариями и чек-листами

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

Для оценки покрытия можно использовать матрицу трассировки требований.

Процент написанных тестовых сценариев и чек-листов

За основу можно взять общее количество фичей, матрицу трассировки, user story. Следует также оценивать плотность покрытия требований. Для этого стоит применять атомарность — каждая функциональность должна быть разбита на максимально атомарные фичи, которые также следует покрывать тестовой документацией.

Процент выполненных работ по подготовке тестовой среды, тестовых данных

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

Метрика необходима для оценки критерия готовности начала тестирования. Необходимо отталкиваться от количества необходимых тестовых данных и отслеживать прогресс путём отношения готовности к необходимой норме.

Метрики выполнения тестов

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

Как правило, это реализуется RMS-системами, также можно отслеживать количество пройденных кейсов в excel-таблицах.

Метрики дефектов

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

Необходимо собирать эту метрику в разрезах регрессов и текущего состояния проекта. Можно отслеживать по упавшим тест кейсам, либо вести дополнительную статистику в excel-таблицах.

Информация о статусе задач, специалистов, загруженности и трудозатратах

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

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

Финансовая информация

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

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

Реализуется путём учёта финансовых расходов команды, а также планирования будущих трат.

Заключение

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

О том, как снимать метрики, можно написать целую статью. Экономя время, вкратце резюмирую:

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

• тестирование
• тестирование по
• тестирование веб-приложений
• тестирование мобильных приложений
• тестирование приложений
• тестирование сайтов
• метрики
• метрики производительности
• метрики процесса
• метрики тестирования

• Блог компании Иннотех
• Тестирование IT-систем
• Тестирование веб-сервисов
• Тестирование мобильных приложений

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

Что такое метрика тестирования программного обеспечения?

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

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

Метрики тестирования программного обеспечения — Повышает эффективность и результативность процесса тестирования программного обеспечения.

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

Пример измерения теста программного обеспечения : общее количество дефектов

В этом уроке вы узнаете

• Что такое метрика тестирования программного обеспечения?
• Почему метрики теста важны?
• Типы тестовых метрик
• Метрики ручного теста
• Тест метрики жизненного цикла
• Как рассчитать тестовую метрику
• Пример тестовой метрики
• Тест метрики Глоссарий

Почему метрики теста важны?

"We cannot improve what we cannot measure" and Test Metrics helps us to do exactly the same.

• Принять решение для следующего этапа деятельности
• Доказательство претензии или прогноза
• Понять тип необходимого улучшения
• Примите решение или процесс или изменение технологии

Типы тестовых метрик

• Метрики процесса: его можно использовать для повышения эффективности процесса SDLC (жизненный цикл разработки программного обеспечения).
• Метрики продукта: это касается качества программного продукта

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

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

• Зафиксируйте целевую аудиторию для метрической подготовки
• Определите цель для метрик
• Ввести все соответствующие показатели на основе потребностей проекта
• Проанализируйте аспект затрат и выгод каждой метрики и фазы образа жизни проекта, на которой он приводит к максимальной производительности

Метрики ручного теста

В программной инженерии, ручные тестовые метрики делятся на два класса

Базовые метрики — это необработанные данные, собранные Test Analyst во время разработки и выполнения тестовых примеров (количество выполненных тестов, количество тестовых случаев ). При этом рассчитанные показатели выводятся из данных, собранных в базовых показателях. За расчетными показателями обычно следует менеджер тестов для целей составления отчетов о тестировании ( % Complete,% Test Coverage ).

В зависимости от проекта или бизнес-модели, некоторые важные показатели

• Метрики производительности выполнения тест-кейсов
• Метрики производительности подготовки тестового примера
• Метрика дефекта
• Дефекты по приоритету
• Дефекты по степени тяжести
• Коэффициент проскальзывания дефекта

Тест метрики жизненного цикла

Различные этапы жизненного цикла метрики

Шаги на каждом этапе

• Анализ

• Идентификация метрик
• Определить идентифицированные метрики QA

• сообщаться

• Объясните потребность в метрике заинтересованной стороне и команде тестирования
• Проинформируйте команду тестирования о точках данных, которые необходимо собрать для обработки метрики.

• оценка

• Захват и проверка данных
• Расчет значения метрики с использованием полученных данных

• отчет

• Разработайте отчет с эффективным заключением
• Разошлите отчет заинтересованному лицу и соответствующему представителю.
• Получите отзывы от заинтересованных сторон

Как рассчитать тестовую метрику

• Тестирование процесса отслеживания прогресса

• Количество тестовых случаев, запланированных к выполнению в день

• Фактическое выполнение теста в день будет зафиксировано менеджером теста в конце дня

• Фактические тесты, выполненные за день

• Выполнение тестового примера ниже установленной цели, нам нужно выяснить причину и предложить меры по улучшению

Пример тестовой метрики

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

Для получения статуса выполнения тестовых случаев в процентах мы используем формулу.

Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100

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

Тест метрики Глоссарий

• Коэффициент трудоемкости переработки = (фактические усилия по переработке, потраченные на этом этапе / общие фактические усилия, потраченные на этом этапе) X 100
• Creep Requirement = (Общее количество добавленных требований / Нет начальных требований) X100
• Разница в графике = (фактические усилия — предполагаемые усилия) / предполагаемые усилия) X 100
• Стоимость обнаружения дефекта в тестировании = (Общее количество усилий, потраченных на тестирование / дефектов, обнаруженных в тестировании)
• Проскальзывание расписания = (Фактическая дата окончания — Предполагаемая дата окончания) / (Запланированная дата окончания — Запланированная дата начала) X 100
• Р оценочный тестовых случаев Процент = (Количество пройденных тестов / Общее число тестов выполняется) X 100
• Процент неудачных тестов = (Количество неудачных тестов / Общее количество выполненных тестов) X 100
• Процент заблокированных тестов = (количество заблокированных тестов / общее количество выполненных тестов) X 100
• Процент фиксированных дефектов = (фиксированные дефекты / сообщенные дефекты) X 100
• Процент принятых дефектов = (дефекты, принятые командой разработчиков / общее количество дефектов, о которых сообщено) X 100
• Процент отложенных дефектов = (Отложенные дефекты для будущих выпусков / Всего зарегистрированных дефектов) X 100
• Процент критических дефектов = (Критические дефекты / Всего зарегистрированных дефектов) X 100
• Среднее время, затраченное командой разработчиков на исправление дефектов = (Общее время, необходимое для исправления ошибок / Количество ошибок)
• Количество выполненных тестов за период времени = Количество выполненных тестов / Общее время
• Эффективность дизайна теста = Количество разработанных тестов / Общее время
• Эффективность обзора теста = количество проверенных тестов / общее время
• Ошибка нахождения или Количество дефектов в час испытаний = Общее количество дефектов / Общее количество часов испытаний