Показатели контроля качества: определение, важность, типы и советы

10 сентября 2021 г.

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

Что такое метрики качества?

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

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

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

• Сколько времени может занять тестирование?

• Каковы бюджет и стоимость тестирования?

• Насколько серьезными являются дефекты продукта?

• Сколько недостатков обнаруживает команда?

• Сколько ошибок пропускают тесты?

• Сколько продуктов тестирует команда?

• Можно ли завершить тестирование до запуска продукта?

• Сколько функций команда добавляет к существующим продуктам?

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

Типы метрик контроля качества

Вот некоторые из основных категорий метрик QA, которые используют разработчики программного обеспечения:

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

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

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

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

• Покрытие требований: эта метрика позволяет увидеть, с какими требованиями тестирования связаны тесты. Вы можете разделить количество требований с тестовым покрытием на общее количество требований проекта и умножить результат на 100, чтобы получить этот процент.

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

Тестовое усилие

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

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

• Количество ошибок в тесте: эта метрика может помочь вам найти среднее количество ошибок, с которыми вы сталкиваетесь в тесте, а не количество дефектов в данном тесте. Чтобы найти эту метрику, вы можете разделить общее количество дефектов на общее количество тестов.

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

• Среднее время тестирования ремонта: это может помочь разработчикам понять, сколько времени они тратят на тестирование устранения дефектов. Вы можете найти это среднее значение, разделив общее количество ремонтов, которые тестирует ваша команда, на общее время, затраченное на тестирование ремонтов.

Регрессия

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

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

• Влияние изменений тестирования: это относится к общему количеству недостатков, которые команда разработчиков приписывает своим версиям. Тщательно определив, какие дефекты связаны с изменениями или дополнениями, команда разработчиков может составить список новых дефектов и отследить их общее количество.

Выполнение теста

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

Распределение дефектов

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

Обнаружение дефектов и восстановление

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

• Среднее время обнаружения дефектов: измеряет время, затрачиваемое проектом тестирования на обнаружение дефекта в продукте. Вы можете найти это среднее значение, разделив время, затрачиваемое на поиск дефектов, на общее количество дефектов, обнаруженных вашей командой.

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

Показатели тестовой команды

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

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

• Распределение тестовых наборов: это еще один показатель, который позволяет менеджерам правильно распределять работу. Это запись о том, сколько тестовых случаев каждый член команды получает в качестве задания.

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

Тестовые экономические показатели

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

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

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

• Стоимость отсутствия тестирования: этот показатель может помочь компаниям понять последствия отказа от тестирования своего продукта, включая любые затраты, которые они несут, чтобы доработать продукт в случае обнаружения недостатков. Это также может включать такие соображения, как потеря доверия клиентов, сбои продуктов, упущенная выгода и увеличение усилий по поддержке клиентов.

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

Советы по выбору показателей контроля качества

Примите во внимание следующие советы при выборе метрики для тестирования:

Назначьте разные показатели разным уровням

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

Настройте свои показатели в соответствии с методологией вашего проекта

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

Сопоставьте показатели с вашим стилем тестирования

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