Основные показатели процесса QA

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

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



    Какими должны быть метрики?


    Сама по себе метрика в контексте ПО — это численное выражение какого-либо свойства, качества самого продукта или процесса его разработки. Иными словами, это то, с помощью чего мы можем измерить, сравнить и оценить ПО.

    Теперь буквально пара комментариев по поводу значений и свойств метрик:

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

    Основные группы метрик для QA


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

    Итак, в этой статье мы не будем рассматривать обычные количественные показатели прогресса тестирования, которые используются в большинстве отчетов и статусов. Вместо этого разберем, какие сферы, артефакты и области разработки с точки зрения Quality Assurance мы должны измерять и контролировать для оценки качества выполнения работы. Анализ и оптимизация этих точек крайне важнны для эффективного взаимодействия со стейкхолдерами (https://doitsmartly.ru/all-articles/sw-testing/120-stakeholders-for-qa.html) и разработки ПО в целом:

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

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

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

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

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

    Далее рассмотрим, какие именно метрики входят в каждую группу, разберем, как именно их можно оценить. Для каждой группы я приведу несколько примеров возможных метрик и опишу их значение. Более подробно эти и некоторые другие индикаторы QA процесса разобраны в моей статье «Самые важные метрики QA» (https://doitsmartly.ru/all-articles/sw-testing/133-the-most-important-metrics-in-qa.html).

    Группа 1 — Требования к разрабатываемому ПО


    Эта группа метрик позволит оценить, насколько мы проработали требования (user story) к ПО, определить уязвимые места и наиболее сложные, потенциально проблемные фичи ПО, понять, где требуется особый контроль.

    1. Тестовое покрытие требования
    «Общее количество тестов» / «Общее количество требований»

    Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.

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

    2. Степень взаимосвязанности требований
    AVERAGE («Количество требований, связанных с требованием №1» / «Общее количество требований -1» ,…, «Количество требований, связанных с требованием №n» / «Общее количество требований -1»)

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

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

    • По своему опыту могу отметить, что приемлемая степень связанности не превышает 0,2-0,3. В ином случае доработка одного из требований будет вести к цепочке переработок, а значит и возможных ошибок в значительной части продукта.

    3. Коэффициент стабильности требований
    «Количество изменений в существующих требованиях» / «Общее количество требований, реализованных за итерацию, включая новые»

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

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

    Группа 2 — Качество разрабатываемого продукта


    Данная группа метрик позволяет оценить и сравнить от релиза к релизу как качество ПО, так и качество самой разработки.

    1. Плотность дефектов
    «Количество дефектов в отдельном модуле» / «Общее количество дефектов в ПО»

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

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

    2. Коэффициент регрессии
    «Количество дефектов в старом функционале» / «Общее количество дефектов, включая новый функционал»

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

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

    3. Коэффициент повторно открытых дефектов
    «Количество повторно обнаруженных дефектов» / «Общее количество ошибок, включая ранее исправленные и новые»

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

    • Чем ближе значение коэффициента к 0, тем меньше повторяются старые ошибки.
    • При этом, если значение больше 0,2-0,3, это может говорить либо о технической сложности модуля, либо о проблемах в архитектуре, либо о некачественном исправлении ошибок.

    Группа 3 – Возможности и эффективность команды QA


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

    1. Скорость работы (velocity) команды QA
    «Количество story points за N итераций)» / «N»

    Рассчитывается как отношение реализованных story points \ требований \ user stories за несколько итераций \ sprints к количеству выбранных итераций.
    Назначение метрики: численно выразить возможности, скорость работы команды для дальнейшего планирования объема работ и анализа трендов развития. Метрика позволяет следить за скоростью работы QA, наблюдать за тем, какие внутренние или внешние воздействия на команду влияют на эту скорость.

    2. Среднее время жизни дефекта
    «Суммарное время исправления найденных дефектов» / «Количество дефектов»

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

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

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

    Группа 4 — Качество работы команды тестирования


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

    1. Эффективность тестов и тестовых наборов
    «Количество обнаруженных ошибок» / «Количество кейсов в тестовом наборе»

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

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

    2. Коэффициент ошибок, пропущенных на продуктив
    «Количество ошибок, обнаруженных после выпуска релиза» / «Общее количество ошибок, обнаруженных до и после релиза»

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

    • Конечно, допустимый процент пропущенных ошибок будет зависеть от многих факторов, однако, если он >0,1, то тут явно есть проблема, ведь в таком случае каждый десятый дефект попал на продуктив и привел к сбоям ПО у пользователей.

    3. Реальное время работы команды QA
    «Время, потраченное на целевые QA активности» / «Общее количество рабочих часов команды»

    Отношение времени, потраченного командой непосредственно на целевые QA активности, к общему количеству часов.

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

    • К целевым активностям могут относиться: анализ, дизайн, оценки, тестирование, рабочие встречи и многое другое, к нецелевым — простой из-за блокеров, проблемы в коммуникациях, недоступность ресурсов и т.п.
    • Конечно, данная метрика никогда не будет равна 1. Практика показывает, что для эффективных команд ее значение может составлять 0,5-0,6.

    4. Точность оценки времени по областям\видам\типам работ
    «Оценочное время работы» / «Фактическое время работы»

    Назначение метрики: позволяет использовать поправочный коэффициент для последующих оценок.

    • Степень точности оценки можно определить для всей команды или отдельных тестировщиков, для всей системы или отдельных модулей ПО.

    Группа 5 — Обратная связь и удовлетворенность пользователей


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

    1. Удовлетворенность пользователей ИТ сервисом
    Проводится регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.

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

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

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

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

    3. Вовлеченность стейкхолдеров
    Количество инициатив и предложений по улучшению процесса и продукта, поступивших в течение итерации (релиза) со стороны стейкхолдеров.

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

    Павел Новиков,
    Program Manager
    https://doitsmartly.ru/
    Luxoft 111,79
    Компания
    Поделиться публикацией
    Комментарии 1

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

    Самое читаемое