Метрики тестирования – Анализ ключевых показателей производительности — часть 2, про анализ метрик пользовательских, бизнесовых и приложения

Содержание

Основные показатели процесса QA / Luxoft corporate blog / Habr

В рамках 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/

Метрики в тестировании - Портал TMGuru

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

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

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

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

Виды метрик

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

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

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

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

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

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

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

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

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

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

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

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

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

Про Тестинг - Обеспечение качества

Раздел: Обеспечение Качества > Метрики - создание, использование и анализ

Согласно международному стандарту ISO 14598:

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

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

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

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

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

  1. Метрики по тестовым случаям (Test Cases)
  2. Метрики по багам / дефектам
  3. Метрики по задачам

Давайте более детально разберем каждую из них:

Метрики по тест кейсам

НазваниеОписание
Passed/Failed Test Cases

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

Not Run Test Cases

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


Метрики по багам

НазваниеОписание
Open/Closed Bugs

Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)

Reopened/Closed Bugs

Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)

Rejected/Opened Bugs

Метрика показывает отношение количества отклоненных багов к открытым

Bugs by Severity

Количество багов по серьезности

Bugs by Priority

Количество багов по приоритету

Хотим отметить, что метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имея требования к количеству открытых багов, после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели.

Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.

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

  1. Требования к функции можно трактовать по разному
  2. Тестировщик не точно описал проблему
  3. Некачественное поверхностное решение проблемы (фикс бага)

Второй пример покажет для чего необходима метрика "Rejected/Opened Bugs":
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:

  1. Требования к функции можно трактовать по разному
  2. Тестировщик не точно описал проблему
  3. Разработчик не желает исправлять допущенную им ошибку или не считает, что это на самом деле ошибка. (Эта проблема является прямым следствием 2-ой, возникшей из-за не точного описания)

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

Метрики по задачам

НазваниеОписание
Deployment tasks

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

Still Opened Tasks

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

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

* * *

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

Автор: Алексей Булат

Наверх

«Календарь тестировщика» за апрель. Метрики на службе у QA / Контур corporate blog / Habr

Апрельская статья из цикла «Календарь тестировщика» посвящена метрикам. Кирилл Раткин, тестировщик Контур.Экстерна, расскажет как повысить эффективность тестирования с их помощью и не уйти в крайности.

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

Как вы можете охарактеризовать свои рабочие процессы и практики? Они хорошие? Плохие? Насколько? Почему вы так решили?

Не удержусь и процитирую слова лорда Кельвина:


«Если вы можете измерить то, о чем говорите, и выразить это в цифрах – значит, вы что-то об этом предмете знаете. Но если вы не можете выразить это количественно, ваши знания крайне ограничены и неудовлетворительны».

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

Я видел две крайности:


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

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

Метрики нужны для:


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

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


Собираясь вводить метрики в автотесты, вы должны понимать, для чего это вам.

Специфика наших автотестов:


  • Наличие гуевых пользовательских сценариев.
  • Интеграционные проверки с тестовыми стендами сторонних сервисов.
  • Кроссбраузерность.
  • Конфигурирование CI и тестовых виртуалок.
  • Предоставление наших продуктовых АТ другим сервисным командам.

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


Метрики дежурного по автотестам

Мы начали обращать внимание не только на стабильность теста и время прогона, но и на:


  • время красного прогона
    Показывает как долго тест падает. Прогоны, которые долго падают, держат очередь на виртуалках. Иногда WebDriver кидает исключения, и такие тесты могли висеть часами. Такие ситуации решаются уровнем выше и для всех тестов, а вот от некорректных таймаутов и ожидалок можно избавиться лишь потрогав конкретный тест. Мы в обязательном порядке разбираемся с прогонами, у которых эта метрика более 20 минут.
  • эффективность теста по времени
    Сколько агент тратит на реальный прогон, а не на нестабильность. Эта метрика про шумящие тесты. Мы хотели понимать сколько времени уходит на зеленые и красные прогоны, и посчитать соотношение. Тесты с низкой эффективностью стоят первыми в очереди на рефакторинг.
  • относительное потерянное время
    Эта метрика показывает сколько минут теряется на каждый прогон этого теста из-за нестабильности. В нашей команде она считается второй по важности после стабильности.

Плюс, учли ряд специфичных для нас особенностей:


  • Уникальным ключом для нас служило не имя теста, а пара тест — браузер.
    Один и тот же UI-тест ведет себя по-разному в быстрых и медленных браузерах, разных JS-интерпретаторах и т.д. Поэтому тестировщик правит не Test1, а Test1 в Browser1.
  • Некоторые агенты с вроде бы идентичным окружением (ОС, браузер и т.д.) отличались друг от друга по стабильности прохождения тестов.
    Есть сложности с генерацией абсолютно идентичных окружений. Плюс виртуалки не закрыты от разработчиков или тестеров, которые хотят «что-то подебажить». Поэтому пока не решены эти проблемы, приходится делать выборки по прогону тестов в разрезе каждого агента. Если какой-то тест проходит на конкретном агенте заметно хуже, то это триггерит дежурного на более тесное общение с данной виртуалкой.

Поиск испорченных виртуальных машин

Большинство команд могут собирать метрики с помощью CI. Нам этого не хватило — слишком хитро мы настроили свои категории и запускалки. Пришлось написать небольшую оберточку, которая в TearDown’е отправляла в БД мету билда со всеми показателями.

Наши цели:


  1. Оценка ситуации
  2. Информация для адресного реагирования

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

Раз в две недели на летучке с дежурным мы:


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

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


Еще одной большой задачей является оценка покрытия. Еще ни один вариант расчета этого показателя не устраивал меня полностью. А как покрытие считаете вы? Делитесь в комментариях.

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

Кто-то считает покрытие кода. Но здесь не учитывается с какими параметрами мы вызываем тот или иной метод. Действительно, зайдя в метод, который делит А на В с какими-нибудь «безопасными» аргументами, мы не можем сказать, что метод покрыт и протестирован. А если деление на ноль? А если переполнение? Также не учитывается критичность непокрытого кода, а поэтому неясна мотивация это покрытие увеличивать.

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

Дальше принцип простой:


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

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


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

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


Сбор метрик релизного цикла на базе YouTrack

Из всего этого мы сумели:


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

Сейчас у нас соотношение пишущих разработчиков к выпускающим их тестировщикам в районе 3 (± 0.1), комфортным считается 2.5. С учетом проводимой автоматизации релизного цикла мы хотим выйти на соотношение 3.5 и 3.

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

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


Типичным антипаттерном являются «метрики ради метрик». Как я уже отмечал выше, метрики — это лишь инструмент, который помогает количественно оценить, насколько хорошо вы достигаете целей.

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

Всегда помните, что сбор метрик требует от вас определенных усилий и времени. Цените его и подходите к этой практике с умом!

Нам очень интересно, а какие метрики используете вы, а от каких, наоборот, отказались. Пишите в комментариях!

Список статей календаря:
Попробуй другой подход
Разумное парное тестирование
Обратная связь: как это бывает
Оптимизируй тесты
Прочти книгу
Тестирование аналитики
Тестировщик должен поймать баг, прочитать Канера и организовать движуху
Нагрузи сервис
Метрики на службе у QA
Протестируй безопасность
Узнай своего клиента
Разбери бэклог

code coverage для тестировщиков / Habr

Как известно из книги «Путеводитель для путешествующих автостопом по галактике», ответ на главный вопрос жизни, вселенной и всего такого — 42. Процент покрытия кода по линиям на одном из моих проектов — 81, дает ли эта цифра ответ на главный вопрос тестирования «cколько тестов достаточно для определения качества продукта»?

В течении своей работы в айти-сфере и тестировании я видела мало команд и проектов, где тестировщики реально используют code coverage в своей работе. Связано это на мой взгляд с двумя вещами:

1. Тем, что тестируем мы прежде всего требования;
2. Далеко не все понимают, как считать и использовать покрытие.

Интересующимся предлагаю свой взгляд на эти 2 пункта.

Требования vs код

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

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

Что значит невозможно выполнить операцию?

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

Это значило, как минимум, следующие случаи:
1. Соединение с сервером БД не может быть установлено;
2. Соединение с сервером БД установлено, выполнение запроса вызвало оракловую ошибку;
3. Соединение с сервером БД было установлено, запрос начал выполняться и завис — тут был баг. Приложение ждало ответа примерно минут 5, потом в логи летел эксепшн и больше оно эти данные записать не пыталось.

Пара остальных не стоило внимания по разным причинам.

В примере требования формально проверено было и 1-м кейсом, но баг был найден после анализа покрытия кода. Можно поспорить, что это пример не о пользе code coverage, а о пользе взаимодействия внутри команды (у разработчика детали имплементации можно было бы узнать заранее или дать ему кейсы на ревью), на самом деле я всегда так делаю но не о всем догадаешься спросить, часто внимание к каким-то вещам привлекают непокрытые блоки кода.

Пример 2

В другой системе, которуя я тестировала, при потере консистентности данных приложение должно было выкидывать соответствующий эксепшн, бросать нотификацию мониторингу и ждать, когда придут люди и спасут его. Тесты покрывали разные случаи возникновения таких ситуаций, все обрабатывалось нормально.
Мы посмотрели код, нужный кусок был покрыт хорошо, но я увидела в другом классе непокрытую область кода, в которой бросался тот же самый event о потери консистентности. При каких условиях — неизвестно, т.к. разработчики его быстро выпилили. Оказалось он был скопипасчен из старого проекта, но никто об этом не помнил. Где это могло стрельнуть- неизвестно, но без анализа кода мы бы это не нашли.

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

Покрытие = 80. А качество?

Количество не означает качество. Оценка покрытия кода напрямую не связана с качеством продукта, но связана опосредованно.
На одном отчетном совещании я заявила, что покрытие кода у нас увеличилось до 82% по линиям и 51% по условиям, после чего руководством мне был задан вопрос: «А что это значит? Это хорошо или плохо?» Закономерный вопрос, действительно: сколько надо, чтобы было хорошо?

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

К вопросу об «это нормально»: качественная оценка непокрытого кода и ведет в моем понимании к адекватному использованию code coverege. Смотреть важно то, что вы не покрыли, а не сколько. Если это java-код и методы toString(), equals() или ветви с exception, которые сложно воспроизвести интеграционно, ну так и ладно, пусть будет 80% покрытия реальной бизнес-логики. «Лишний» код многие инструменты умеют фильтровать и не считать.
Если сомнения в белых пятнах все-таки остаются, возможно посчитать общее покрытие интеграционными тестами и юнит — разработчики наверняка учли многое что труднодоступно для интеграционных тестов.

Однако есть одно «но». Что, если покрытие кода низкое? 20%, 30%? Где-то я читала забавный факт, что покрытие 50% и меньше (по линиям и условиям, как мне помнится) означает тот уровень тестового покрытия, при котором результат работы приложения будет такой же, как и при отсутствии тестирования вообще. Т.е. там могут быть баги, может не быть багов, с тем же успехом вы могли его и не тестировать. Другое объяснение — много мертвого кода, что маловероятно.

А у нас нет автотестов

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

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

Разберем по порядку, куда конкретно нужно будет потратить ресурсы, если вы решите попробовать считать code coverage:

  1. Выбор тула, подходящего под ваше приложение
  2. Инструментирование билдов (в том числе конфигурация code coverage тула и фильтация «ненужного» для оценки кода)
  3. Построение отчета о покрытии после прогона тестов
  4. Анализ покрытия

Пункты 1 и 2 можно отдать разработчикам, могие из них знакомы-слышали-встречались с общеизвестными тулами и тем более смогут построить собственный билд. Построение отчетов, как правило, делается одной командой в командной строке или автоматически, если вы используете CI (у меня это делал jenkins, он же публиковал отчет).
Самое затратное — это четвертый пункт. Основная трудность тут в том, что для адекватной оценки надо уметь читать код, либо садиться рядом с разработчиком, чтобы он объяснял, что значит этот кусок, и как это воспроизвести. Это требует определенной квалификации от тест-инженера и рабочего времени 1 или 2 человек.

Стоит ли оно того — решать команде и ее руководителям. В проектах, где требования слабо формализованы, либо баги возникают необъяснимым для тестеров образом, возможно это может помочь хотя бы понять направление куда копать.
Еще одна категория — проекты, которые предполагают очень hight-level black box тестирование. Это прежде всего тестирование через UI или внешний API систем, внутри которых содержится куча логики, работающей по своим законам, т.е. извне вы не можете ее затронуть или ей управлять, а значит не можете нормально протестировать. Анализ покрытия в таких проектах создаст аргументированную необходимость переходить к более «низким» уровням тестирования: модульным, покомпонентным, тестированию на заглушках и т.п.
Хорошо работает накопленное покрытие кода в цифрах: на графиках можно увидеть моменты, когда вливается новый код, а тесты еще не подоспели; если уровень покрытия был высоким, потом стал снижаться, но предыдущего уровня так и не достиг — где-то может быть хорошее белое пятно недошедших до тестирования требований, и т.д.

Пожалуй, это все, что я хотела сказать на сегодня.

Напоследок limitations и out of scope

  1. Я постаралась описать в общих словах подход к этом вопросу, не вдаваясь во многие технические подробности. Говоря о «покрытии» 80% я говорю о неком общем или усредненном покрытии, не имея в виду конкретных метрик — покрытия линий, условий и проч. Выбор конкретных метрик — это отдельный интересный вопрос.
  2. Мой опыт в основном связан с java-кодом и инструментами для него, я не работала в этом ключе с другими технологиями, знаю, что есть тулы для C++, но пока попробовать их в деле не удалось.
  3. Серьезный анализ покрытия стоит проводить на стабильных билдах и стабильно работающих тестах, иначе сложно будет сказать что явилось причиной пропусков- упавшие тесты, критичные баги или действительно что-то пропущено

Несколько полезных метрик для оценки тестирования — Лаборатория Качества

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

 

Зачем что-либо измерять?

 

Есть проект. Ваш любимый, родной, которому вы желаете расти и процветать.
Но как вы оцените его процветание, если нет критериев этого самого процветания?
Как вы сможете оперативно среагировать на проблемы до того, как они стали неисправимыми, если не будете использовать «датчик грядущей Ж»?
Как вы поймёте, что именно следует улучшать, если вам неизвестен источник проблем?

 

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

 

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

 

А если не приходят, значит метрику можно смело выбросить 😉

 

История 1: Кто впустил его сюда??

 

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

 

Задача #1 для меня стала очевидной: оценка % пропущенных ошибок: а правда ли, что тестировщики что-то пропускают? Для этого мы ввели в баг-трекере поле «сообщил клиент», пометили таким образом старые баги и посчитали. Процент составил чуть больше 5%, причём далеко не все из них были критическими.

 

Много это или мало? По моему опыту это достаточно хороший процент. Откуда тогда мнение, что тестировщики много пропускают?

 

Мы ввели ещё одно поле: «воспроизводится на релизной версии». Каждый раз, регистрируя новую ошибку с тестового стенда, тестировщики проверяли, есть ли она в последней пользовательской версии: возможно, пользователи просто не сообщают конкретные ошибки? Результат за первый месяц — около 40% ошибок, зарегистрированных в баг-трекер, воспроизводятся в релизной версии.

 

Получается, пропускаем мы действительно много, но пользователи не сообщают о конкретных ошибках, а вот мнение «ваш софт — отстой!» у них явно формируется. Таким образом мы сформировали метрики-датчики: что не так:

 

  • % пропущенных в релизную версию ошибок
  • % ошибок, сообщённых пользователем

 

Ставим цель (а иначе зачем что-то вообще мерять?)! Хотим не больше 10% ошибок, попавших в релизную версию. Но как это обеспечить? Непомерно расширять ресурсы? Увеличивать сроки?

 

Для ответа на этот вопрос нам нужно копать дальше, и искать новые метрики, которые дадут ответ на этот вопрос.

 

В данном случае, мы для всех пропущенных ошибок добавили ещё одно поле: «Причина пропуска». И на выбор указываем, почему не завели эту багу раньше:

 

  • неизвестное требование (не знали или не поняли, что это было нужно)
  • не учли тест (не додумались тестировать это ТАК)
  • не протестировали (тест был, его проверили, но потом функционал сломался, а повторно эту область не проверяли)

 

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

 

Брейншторминг «как решить эту загадку» привёл к различным решениям: еженедельное обсуждение пропущенных дефектов в группе тестирования, согласование тестов с аналитиками и разработчиками, прямое общение с пользователями для исследования их окружений и условий и т.д. Внедряя потихоньку эти новые процедуры, мы снизили всего за 2 месяца % пропущенных ошибок до 20%. НЕ расширяя команду, НЕ увеличивая сроки.

 

До 10% мы пока что не дошли, но в июле было 14% — мы уже совсем близки к цели, и судя по уверениям внедренцев, клиенты уже заметили изменения в качестве. Неплохо, да?

 

История 2: Откуда дровишки?

 

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

 

Естественно, я начала с попыток измерить свои субъективные ощущения «медленно». Как это понять? С чем сравнить? KLOC в месяц? Фич в итерацию? Средние срывы сроков относительно плана? Естественно, первые 2 метрики ничего полезного не принесут, поэтому я стала смотреть % срывов сроков по фичам (итерации у нас не имеют фиксированного набора фич, поэтому серьёзно припоздниться не могут — что за 2 недели успели сделать и протестировать, то и выкладываем). Но фичи!

 

Оказалось, что по ним мы срываем сроки в среднем в 1,5-2 раза! Я не буду рассказывать, чего мне стоило добыть эту информацию из редмайна, но вот, она есть. И я хочу копать дальше, используя принцип «пяти «почему»». Почему так? Мы плохо планируем? Я слишком быстро хочу результат? Или низкая квалификация? На что уходит время?

 

Я стала анализировать: в среднем на 1 небольшую фичу приходится от 15 до 40 багов, а время на их фикс уходит больше, чем на разработку самой фичи. Почему? Много это или мало? Разработчики жалуются, что очень много просьб на изменение уже разработанного функционала — правда ли это или субъективная ошибочная оценка?

 

Копаем дальше. Я ввожу в бедный несчастный разбухший от дополнительных полей баг-трекер поле: «Причина появления ошибки». Не пропуска, как в Истории #1, а именно ПОЯВЛЕНИЯ. Это поле заполняет разработчик в момент коммита, когда он уже точно знает, что и как он исправлял. И варианты ответа следующие:

 

  • Код (вот взяли и накосячили)
  • Непонимание требований («ах я ж не понял, что именно это было нужно!»)
  • Изменение требований (product owner посмотрел на результат и сказал «э не, на самом деле нужно по-другому, а не так, как я изначально просил»)

 

Ошибок в коде у нас оказалось около 30%. Изменений требований — меньше 5% (разработчики удивились, но признали — это ведь они указывают причину!). А почти 70% ошибок оказались вызваны непониманием требований. В нашем случае, когда багфикс занимает больше разработки, это ПОЛОВИНА ВРЕМЕНИ, ЗАТРАЧИВАЕМОГО НА РАЗРАБОТКУ ФИЧИ.

 

Что делать?

 

Вариантов решения проблемы мы нашли много, начиная от найма технического писателя, который будет вызнавать требования у product owner’а и документировать подробно всё то, что мы описываем в пару строк и заканчивая product owner’ом, переведённым в секретари, круглые сутки документирующим новые фичи. Ни один из этих вариантов нам не понравился, слишком они бюрократичны для команды из 4 разработчиков, сидящих в одном кабинете. Поэтому мы сделали следующее:

 

  • Product owner вкратце, как и всегда, описывает новую фичу
  • Разработчик, когда доходит до неё, тщательно обдумывает способ реализации, как это будет выглядеть, что с этой фичей ему вообще делать
  • После этого разработчик и РО садятся вместе, и разработчик подробно рассказывает свои мысли на тему светлого будущего разрабатываемой фичи
  • Разработчик ни при каких условиях не начинает работу над новой фичей, не пройдя вышеописанный алгоритм действий и не согласовав своё видение с РО
  • Тестировщик чаще всего участвует в этом процессе, заранее подсказывая сложные моменты, которые он будет тестировать

 

Теперь у нас есть около 3-7 таких ~часовых «болталок» в неделю, на которые отрывается 2-3 человека. Количество заводимых багов снизилось, из них ошибок кода стало больше 50% — поэтому нашей следующей задачей будет внедрение code review, т.к. теперь у нас новая «главная проблема».

 

Но от метрики-анализатора мы вернулись к метрике-датчику и поняли, что ни разу с весны не сорвали сроки по фиче больше чем на 50%, хотя до этого среднее значение срыва было от 50% до 100%, а иногда и больше.

 

И это только начало! 😉

 

История 3: Кто тормозит разработчиков?

 

Ещё одна история касается моего совсем недавнего опыта в сторонней компании. Настоящий-пренастоящий Agile, еженедельные итерации… И еженедельные срывы сроков!

 

Причина, заявленная руководством компании: «Разработчики допускают слишком много багов».

 

Я начала анализировать, как это происходит. Я просто участвовала в процессе и наблюдала со стороны, как это очень здорово описано в книге Имаи «Гемба Кайдзен». И вот что я увидела: Релизы по четвергам, пятница подготовительный к новой итерации день. Во вторник-среду появляется сборка на тестирование. В среду-четверг заводятся дефекты. В пятницу, вместо подготовки к новой итерации, разработчики экстренно исправляют баги и так каждую неделю.

 

Я попросила в таск-трекере, где дублируются фичи с доски, проставлять статусы по фиче: фича принята в разработку, фича отдана на тестирование, фича протестирована и отправлена на доработку, фича протестирована и принята в релиз.

 

И как вы думаете, какой средний срок между «фича отдана на тестирование» и «фича протестирована и отправлена на доработку»? 1,5 дня!

 

Причём иногда — с ЕДИНСТВЕННЫМ блокирующим дефектом.

Разработчики в этой компании жаловались на тормозных тестировщиков, но тестировщики и руководство были против разработчиков: «вы сами должны тестировать и не отдавать сырой продукт». Но ведь кесарю кесарево!

 

Итак, метрика есть, 1,5 дня недопустимо много, хотим сократить минимум втрое — это должно ускорить релизы на день. Как это сделать? Опять брейншторм, опять куча идей, 90% участников процесса настаивают что «разработчики должны тестировать сами».

 

Но в итоге мы решили попробовать по-другому: как только фича, по мнению разработчика, готова, тестировщик садится с ним за один компьютер, берёт блокнот с ручкой и начинает проверять, комментировать, выписывать замеченные косяки в блокнот, не тратя время на баг-трекинг. Больше половины багов разработчики в таком режиме исправляют на лету! Ведь фича только написана, всё ещё держится в голове!

 

Срок с 1,5 до 0,5 дней мы сократили очень быстро, но на практике мы достигли другого, более серьёзного изменения: % переведённых в статус «отправлено на доработку» фич снизился с почти 80 до почти 20! То есть в 4 раза! То есть 80% фич теперь сразу принимался после переведения в статус «тестирование», потому что незадолго до перевода в этот статус проходило тестирование «на лету», так сильно сокращающее и время регистрации ошибок, и стоимость их исправления.

 

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

 

Бинго!

 

Выводы

 

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

 

Вы всё ещё не готовы использовать метрики с пользой?

 

Тогда мы идём к вам! 🙂

А не фигню ли я опять делаю? Как и зачем внедрять метрики качества

Привет, Хабр! Когда-то мы использовали метрику «Вроде бы стало лучше» для оценки качества наших релизов. Но потом мы решили довериться чему-то более надёжному. В этой статье я расскажу о том, как искал гайд по метрикам, не нашёл и создал свой.



Бывает ли у вас такое, что вы делаете вроде бы полезную работу для проекта, но не понимаете, приносит ли это пользу? Вот и мы когда-то писали автотесты, но не могли объективно сказать, стали ли лучше релизы монолита и других сервисов, в которых ведётся активная разработка.

В поисках метрик


Я посмотрел в интернете и почему-то не нашёл статей или готовых гайдов о том, как выбирать правильные метрики, как их собирать и что с ними дальше делать. Но пока искал информацию, нашёл полезные видео и статьи, которые помогли мне справиться с этой непростой задачей. Ссылки на них будут появляться в статье.

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

За секунду до создания системы измерения качестваДо того, как мы решили создать систему метрик качества, мы уже на постоянной основе измеряли:
  • Время, потраченное на релиз монолита (с момента создания релизной ветки до мержа этой ветки в мастер).
  • Количество откатов релиза монолита на мастер из-за багов.
  • Время нахождения в Stop the Line.
  • Количество запусков стейдж пайплайна монолита в TeamCity со всеми автотестами, пока он не стал зелёным.

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

Внедряем систему измерения качества за 11 шагов


Перед вами чек-лист из 11 шагов, который поможет внедрить всё и не упустить ничего.
Шаг 1. Определите цель своих измерений

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

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

Шаг 2. Определите целевые показатели

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

В моём случае с определением целевых показателей проблем не возникло, так как в нашей компании есть цели по качеству. Эти цели и стали основой будущих метрик. Наши цели:

  • Релиз монолита занимает не более 4-х часов.
  • 0 хотфиксов и откатов в монолите, сайте и мобильных приложениях.

Шаг 3. Определитесь с метриками

Подумайте, как вы поймёте, что движетесь к целевым показателям. 
На этом этапе работы мне помогла статья «Самые важные метрики QA». Для нашей системы я выбрал такие показатели
  • Время на релиз. Этот показатель измеряет время (в рабочих часах) между мержом ветки предыдущего релиза в мастер и мержом текущего релиза в мастер.

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

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

    Этапы метрики «Время на релиз»

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


Важно! Не берите сразу много метрик. Три-четыре для начала достаточно. Когда процесс наладится, сможете добавить ещё, если это потребуется.

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

Шаг 4. Определитесь с единицами измерения

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

С этим пунктом у нас возникли проблемы. Время релиза мы считали в часах, включая ночные часы, но за исключением выходных дней. При этом целевое значение было –  релиз за 4 часа. Довольно часто случались ситуации, когда мы создавали ветку release-xxx в 16:00 сегодняшнего дня, а заканчивали в 10:00 следующего дня. В нашей метрике считалось 18 часов, но по факту, активные действия проводились всего 3 часа, если не меньше.

Если бы мы продолжали считать таким образом, то никогда не достигли бы показателя «4 часа» по нашей метрике. Встав перед выбором, увеличить цель до 12 часов или брать в учёт только рабочие часы, мы выбрали второе.

Шаг 5. Анализ выбранных метрик на пригодность

В видео «Простые метрики тестирования на практике» спикер предложил крутой способ анализа метрик на пригодность.  Нужно  ответить на 9 вопросов по каждой метрике и принять решение. Анализ метрики «Время на релиз» на пригодность
  • Цель измерения. Этот показатель должен быть связан с бизнес-целью. Метрика «Время на релиз» связана с бизнес-целью  –  релиз за 4 часа. 
  • Для кого эта метрика предназначается. Кто будет смотреть на эту метрику? Продакт оунер, разработчики, менеджеры, тестировщики, скрам-мастера? 

    На эту метрику «Время на релиз» будет смотреть продакт оунер (потому что ему важно понимать, сколько релизов за спринт мы успеваем выкатить), разработчики (потому что они хотят понимать, когда их код будет на проде) и тестировщики (так как время на тестирование напрямую влияет на эту метрику).

  • На какой вопрос пользователя отвечает метрика. Сформулируйте вопросы, на которые получаете ответы с помощью этой метрики. Метрика «Время на релиз» отвечает на вопрос «Как часто мы релизимся?»
  • Сформулируйте идею метрики и её описание. Кратко, но понятно опишите метрику. Метрику «Время на релиз» я описал так: «Мы хотим релизиться как можно чаще, эта метрика покажет, насколько быстро мы релизимся. Время на релиз – это время в рабочих часах с 9:00 до 18:00, без учёта выходных и праздничных дней. Началом релиза считается  создание релизной ветки или мерж предыдущего релиза в мастер, окончанием релиза считается  вливание релизной ветки в мастер. Разбейте время на отдельные этапы, например: подготовка к релизу, прохождение автотестов, ручное тестирование, выкладка на прод»
  • Необходимые условия. Здесь перечислите условия или ограничения для сбора метрик. Кто, когда, откуда будет брать данные для метрик. В моём случае я знаю, где смотреть релизы всех частей. Монолит – мерж ветки release-ххх в мастер. Сайт – картохи в Kaiten.io на релизной доске. Приложения – пока не знаю, но буду выяснять"
  • Исходные измерения. Вот с этим пунктом я не разобрался и не знаю, как его описать. Кто понял или знает, о чём тут может идти речь, напишите в комментах.
  • Укажите формулу расчёта метрики. Для метрики «Время на релиз»: сколько времени в рабочих часах прошло с момента мержа предыдущего релиза в мастер до мержа текущего релиза в мастер (без учета выходных и праздников). В итоге получаем рабочие часы, которые потратили на релиз.
  • Критерии принятия решения. Определите, что вы будете делать, когда увидите изменения этой метрики. Опишите свою реакцию. Мой ответ по метрике «Время на релиз»: «Реагировать на метрику нужно поиском бутылочных горлышек и устранением этих узких мест»
  • Периодичность. Как часто будем собирать метрику. Нашу метрику мы собирались чекать еженедельно, но по факту делаем это чаще.


После такого нехитрого анализа сразу становится ясно, нужна ли вам эта метрика или нет. Появляется более глубокое понимание самой метрики и её ценности для компании и вас.
Шаг 6. Согласуйте метрики с заинтересованными лицами

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

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

Шаг 7. Визаулизируйте результаты

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

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

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

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


Визуализация отношения «проблемных релизов» к общему количеству релизов

Шаг 8. Соблюдайте периодичность сбора метрик

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

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


Шаг 10. Анализируйте и принимайте решения

Нужно смотреть на метрики, на их основании принимать решения. Можно использовать метрики, как дополнительный аргумент в пользу написания дополнительных тестов или фокусировке на техническом долге, а не на бизнес фичах и т.д.
Шаг 11. Автоматизируйте

Максимально автоматизируйте сбор метрик. Если вы используете популярные TaskMS и TestMS системы контроля версий, системы CI/CD, скорее всего, у них у всех есть открытое API, с помощью которого можно легко вытаскивать эту информацию. Если не умеете сами, просите помочь разработчиков. Возможно, для этого придется изменить некоторые процессы. Это нормально. И это малая цена за те преимущества, которое вы получите, начав собирать метрики.

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

Итоги и выводы


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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *