В рамках обеспечения качества можно и нужно использовать различные метрики и индикаторы качества продукта и процесса разработки.
Метрики можно разделить на группы по параметрам, на основе которых они рассчитываются, по этапам жизненного цикла разработки, на которых они используются, по целям и задачам, а также по заинтересованным сторонам, для которых они предназначены.
Этот список можно продолжать и продолжать.
В этой статье я решил собрать и рассмотреть самые основные, на мой взгляд, группы критериев и мер процесса обеспечения качества.
И в каждой группе я перечислю только самые важные и показательные, опять же на мой взгляд, метрики, а также разберу, зачем они нужны, в каких ситуациях они полезны и как их использовать.
Какими должны быть показатели?
Сама метрика в контексте программного обеспечения — это числовое выражение какого-либо свойства, качества самого продукта или процесса его разработки.Другими словами, это то, с помощью чего мы можем измерять, сравнивать и оценивать программное обеспечение.
Теперь лишь пара комментариев по поводу значений и свойств метрик:
- Основная цель любой метрики — улучшение процесса разработки и самого программного продукта.
Метрика позволяет нам увидеть, в какой точке на пути к нашим целям мы находимся в данный момент, приближаемся ли мы к ним или удаляемся от них и достигаются ли критерии успеха.
- Метрики не должны существовать ради самого процесса измерения.
Необходимо использовать только те метрики, которые действительно имеют практическое значение и будут влиять на дальнейшее развитие продукта или оптимизацию процесса.
Отсюда вытекает простое правило: сначала нужно определить области для изменения/улучшения, а затем решить, как их оценивать.
Основные группы метрик для QA
Теоретически практически для каждого, даже самого незначительного действия, этапа или статуса процесса обеспечения качества можно придумать свою характеристику, формулу или показатель.Вы можете учесть каждый артефакт, все переходы дефектов по статусам и посчитать количество тестов в наборе.
Однако самый главный вопрос, который вы должны сразу задать себе, когда хотите что-то измерить: «Зачем нужна эта информация, как ее можно использоватьЭ» При формировании набора метрик следует исходить из целей, планов по улучшению процессов и продукта.
Итак, в этой статье мы не будем рассматривать привычные количественные показатели хода тестирования, которые используются в большинстве отчетов и статусов.
Вместо этого давайте посмотрим, какие области, артефакты и области развития с точки зрения обеспечения качества нам следует измерять и контролировать, чтобы оценить качество проделанной работы.
Анализ и оптимизация этих точек крайне важны для эффективного взаимодействия со стейкхолдерами ( https://doitsmartly.ru/all-articles/sw-testing/120-stakeholders-for-qa.html ) и разработка программного обеспечения в целом: 1. Требования к разрабатываемому программному обеспечению.
Мы обязательно должны понимать, что мы разрабатываем и тестируем, и степень этого понимания надо уметь оценить.
Потенциальные риски или упущенные проблемы на уровне спецификации могут привести к самым серьезным и дорогостоящим ошибкам.
2. Качество разрабатываемого продукта.
Здесь все очевидно: нужно уметь оценивать качество разработки и ПО, чтобы делать прогнозы и оценивать риски.
Важно понимать, насколько качественный и надежный продукт, исходя не только из наличия или отсутствия найденных ошибок, но и прогнозируя, много ли потенциальных проблем.
3. Возможности команды контроля качества.
Здесь тоже все просто: чтобы управлять процессом тестирования, планировать работу и прогнозировать сроки, нужно всегда иметь не только текущий статус задач, но и знать возможности команды QA. 4. Качество работы команды тестирования.
Помимо качества самого продукта, вам необходимо измерить эффективность самого процесса контроля качества и команды тестирования.
Чтобы постоянно оптимизировать и улучшать качество работы, нам необходимо знать, где мы находимся сейчас, что позволяет нам двигаться вперед, а что тормозит нас назад. 5. Обратная связь и удовлетворенность продукцией.
Последнее направление, но, конечно, не по важности, а на основе отзывов заинтересованных сторон процесса, потребителей наших услуг и пользователей продукта.
Важно иметь возможность измерить общую удовлетворенность продуктом, выявить тенденции и сделать соответствующие выводы.
Правильно подобранные метрики для этой группы позволят своевременно выявить возможные проблемы и оперативно применить обратную связь для улучшения процессов.
Далее мы рассмотрим, какие именно метрики входят в каждую группу, и посмотрим, как именно их можно оценить.
Для каждой группы я приведу несколько примеров возможных метрик и опишу их смысл.
Эти и некоторые другие показатели процесса QA более подробно рассмотрены в моей статье «Самые важные метрики QA» ( https://doitsmartly.ru/all-articles/sw-testing/133-the-most-important-metrics-in-qa.html ).
Группа 1 – Требования к разрабатываемому программному обеспечению
Эта группа метрик позволит нам оценить, насколько хорошо мы проработали требования (userstory) к программному обеспечению, выявить уязвимости и наиболее сложные, потенциально проблемные функции программного обеспечения, а также понять, где требуется особый контроль.1. Требования к тестовому покрытию «Общее количество тестов» / «Общее количество требований» Цель метрики — выявить слабые места в тестовом покрытии и выявить риски.
- Эта метрика будет работать только в том случае, если требования хорошо разложены на эквивалентные.
В противном случае он превратится в индикатор наличия или отсутствия тестов по каждому из требований.
- Для требований, коэффициент которых равен или близок к 0, следует рассмотреть возможность добавления тестов.
, «Количество требований, связанных с требованием № n» / «Общее количество требований -1») Метрика рассчитывается как количество связей каждого требования с другими требованиями.
В этом случае используется среднее значение по всем требованиям.
Цель метрики: предоставить основу для оценки сроков тестирования и учета возможных рисков.
Зная степень взаимного влияния требований друг на друга, можно, например, планировать дополнительное время и кейсы для сквозного тестирования, работать над регрессионными проверками, смотреть в сторону интеграции и т. д.
- По своему опыту могу отметить, что допустимая степень связности не превышает 0,2-0,3. В противном случае уточнение одного из требований приведет к цепочке доработок, а значит, и к возможным ошибкам в значительной части продукта.
Метрика также дает представление о том, насколько легко можно масштабировать функциональность системы и добавлять новые функции.
- Для этой метрики коэффициент должен быть не менее 0,5. При этом мы вводим в 2 раза больше новых функций, чем перерабатываем существующие.
В противном случае команда больше сосредоточена на переработке ранее выпущенных функций, а не на создании новой ценности для бизнеса.
Группа 2 – Качество разрабатываемого продукта
Эта группа метрик позволяет оценивать и сравнивать от релиза к релизу как качество ПО, так и качество самой разработки.1. Плотность дефектов «Количество дефектов в отдельном модуле» / «Общее количество дефектов в ПО» Он рассчитывается как доля дефектов от общего количества дефектов на отдельный модуль в пределах итерации или релиза.
Цель метрики: выделить, какая часть ПО является наиболее проблемной.
Эта информация поможет при оценке и планировании работы с данным модулем, а также при анализе рисков.
- Эта метрика поможет обратить наше внимание на проблемный модуль\систему\функционал, где доля дефектов выше средней.
- Например, если коэффициент регрессии больше 0,5, это означает, что мы тратим более половины времени на восстановление ранее работающих функций программного обеспечения.
Эту ситуацию необходимо исправить.
- Чем ближе значение коэффициента к 0, тем меньше повторяются старые ошибки.
- При этом, если значение больше 0,2-0,3, это может свидетельствовать либо о технической сложности модуля, либо о проблемах в архитектуре, либо о некачественном исправлении ошибок.
Группа 3 – Возможности и эффективность команды контроля качества
Основная цель этой группы показателей — выразить в цифрах, на что способна команда тестирования.Эти показатели можно и нужно регулярно рассчитывать и сравнивать, анализировать тенденции, наблюдая, как на работу команды влияют те или иные изменения.
1. Скорость работы команды контроля качества «Количество сюжетных точек за N итераций)» / «N» Рассчитывается как отношение реализованных Story Points\требований\пользовательских историй за несколько итераций\спринтов к количеству выбранных итераций.
Цель метрики — численное выражение возможностей и скорости работы команды для дальнейшего планирования объёмов работ и анализа тенденций развития.
Метрика позволяет отслеживать скорость работы QA и наблюдать, какие внутренние или внешние воздействия на команду влияют на эту скорость.
2. Средний срок службы дефекта «Общее время исправления обнаруженных дефектов» / «Количество дефектов» Общее время, в течение которого дефекты, обнаруженные в рамках итерации или выпуска, были открыты, равняется сумме дефектов.
Цель метрики — показать, сколько времени в среднем требуется на работу с одним дефектом: его регистрацию, исправление и воспроизведение.
Этот показатель позволит оценить время, необходимое для тестирования, и выделить области ПО, с которыми возникают наибольшие трудности.
- Время жизни дефекта — это все время от его регистрации до закрытия за вычетом всех возможных перерывов в работе.
Показывая дефекты с наибольшим временем исправления, метрика позволит вам выявить особенно сложные и проблемные модули или «слабое звено» в команде разработчиков.
Группа 4 – Качество работы команды тестирования
Цель этого набора метрик — оценить, насколько хорошо тестировщики выполняют свои задачи, и определить уровень компетенций и зрелости команды QA. Имея такой набор показателей, вы можете сравнить команду с той же командой в разные периоды времени или с другими, внешними группами тестирования.1. Эффективность тестов и наборов тестов «Количество обнаруженных ошибок» / «Количество случаев в тестовом наборе» Цель метрики — показать, сколько ошибок в среднем могут обнаружить наши кейсы.
Эта метрика отражает качество тестового дизайна и помогает отслеживать тенденцию его изменений.
- Показатель уничтожения тестов позволяет отслеживать эффективность каждого тестового набора и то, как она меняется с течением времени.
Это позволит своевременно пополнять их «свежими» тестами.
- Конечно, приемлемый процент пропущенных ошибок будет зависеть от многих факторов, однако если он > 0,1, то проблема явно имеется, ведь в этом случае каждый десятый дефект попадал в продукт и приводил к программным сбоям у пользователей.
Цель метрики: во-первых, повысить точность планирования, во-вторых, контролировать и управлять работой команды.
- Целевые мероприятия могут включать в себя: анализ, проектирование, оценки, тестирование, рабочие встречи и многое другое; нецелевые действия могут включать простои из-за блокировщиков, проблемы со связью, недоступность ресурсов и т. д.
- Конечно, эта метрика никогда не будет равна 1. Практика показывает, что для эффективных команд ее значение может составлять 0,5-0,6.
- Степень точности оценки может определяться для всей команды или отдельных тестировщиков, для всей системы или отдельных программных модулей.
Группа 5 — Обратная связь и удовлетворенность пользователей
И, наконец, группа метрик, показывающих, насколько продукт был принят конечными пользователями, насколько он оправдал их ожидания.При этом в рамках оценки взаимодействия с пользователем нам важны не только отзывы о самом ПО.
Еще одна значимая задача этой группы метрик — показать, удовлетворены ли пользователи процессом взаимодействия с ИТ-командой в целом и QA в частности.
1. Удовлетворенность пользователей ИТ-услугами Проводится регулярное исследование удовлетворенности пользователей ИТ-услугами и выставляются баллы.
Цель метрики — показать, доверяют ли пользователи ИТ-команде, понимают ли они, как и почему организована ее работа, и насколько эта работа соответствует ожиданиям.
- Метрика может служить индикатором того, что необходимо сосредоточиться на оптимизации процесса или сделать его более понятным и прозрачным для пользователей.
- Показатель удовлетворенности можно рассчитать по результатам опроса после поставки программного обеспечения.
Для этого вам необходимо собрать все оценки и посчитать средний балл.
Цель метрики — определить, насколько разрабатываемый продукт соответствует ожиданиям пользователей, в правильном ли направлении мы движемся, правильно ли определяем важность функций и выбираем варианты решения.
- Для расчета этой метрики мы также проводим опрос пользователей и рассчитываем средний балл.
Регулярно рассчитывая этот показатель, вы можете отслеживать динамику удовлетворенности пользователей.
Цель метрики: определить степень участия внешних стейкхолдеров (бизнеса, инфраструктуры, пользователей, поддержки и т. д.) в работе над продуктом.
Имея на руках такую метрику, вы сможете сориентироваться, где вам нужно получить обратную связь, чтобы однажды не столкнуться с проблемами и недоразумениями.
Павел Новиков, Менеджер программы https://doitsmartly.ru/ Теги: #qa #qatesting #qa Automation #тестирование ИТ-систем
-
Какие Этапы Следует Включить В Договор?
19 Oct, 24 -
Согласны Ли Мы На Некачественный Код?
19 Oct, 24 -
Будет Ли Дождь?
19 Oct, 24 -
Баннер На Myspace Заразил Миллион Человек
19 Oct, 24
