Метрики в тестировании: какие выбрать и что делать, когда они становятся KPI?

Метрики в тестировании
Метрики в тестировании

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

Вопрос касательно метрик: откуда берется градация, что есть отлично, хорошо и недопустимо? Например, есть метрика crash free users. Есть ли какие-то стандарты для разных категорий приложений?  Как установить то пороговое значение, просадка ниже которого для нас будет инцидентом и потребует незамедлительных действий? Домен – игровые мобильные приложения. 

При этом СТО говорит что-то в духе: «Наши приложения должны быть лучшими и вообще не падать»:)

Отвечает Людмила Лихогляд

Тест-менеджер,

11 лет в тестировании

Ответ: Метрики делятся на объективные и субъективные. Отлично, хорошо и недопустимо – субъективные, но ваше желание понятно – посчитать хочется всегда. А тем более нам, тестировщикам, привыкшим, что все должно соответствовать требованиям.

Какие есть варианты:

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

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

3. Существуют общепринятые стандарты качества.

Обратный момент: если принять значение  99% для нас как нормальное, то всегда будет вопрос: а можно ли лучше, а не занизили ли планку? Может, у кого-то был опыт разруливания таких кейсов?

Критерии  должны быть достижимы, не завышены, чтобы не демотивировать команду. Что плохого, если вместо 99% получите 100?  Стремиться к лучшему – прекрасно. И критерии всегда можно, даже нужно пересматривать и изменять, так как и команда, и продукт развиваются, и нельзя все оценивать по устаревшим шаблонам.

Еще вопрос про метрики + KPI. как быть с желанием людей «хакнуть» метрики, когда они становятся KPI? Принять как данность? Бороться с этим? другое решение?

Смотря что понимать под «хакнуть».  Если прокачать свои скиллы, оптимизировать процессы и повысить результаты в пару раз – прекрасно, поблагодарить, пряником угостить 🙂

Если, для примера, ведем статистику по количеству заведенных дефектов на тестировщика, и Вася Пупкин завел 100500 багов на каждый чих, из которых только три мажора, остальные – миноры, и висеть они в системе будут лет 40, так как чинить подобное не будут, то зачем нам такая метрика? Отказываемся!

А если просто подтасовка или изменение результата – тут уж надо серьезно поговорить с человеком, выявить причины, мотивы и подумать, насколько можно доверять этому сотруднику и стоит ли доверять? Тут точно «принять как данность» нельзя.

Так что все зависит от конкретной ситуации. Казнить нельзя помиловать!

Как понять, не мало ли метрик я решил внедрить?

Для первого внедрения предлагаю ограничиться 3-5 метриками, получить первые результаты, проанализировать и потом внедрять что-то новое. Возможно, некоторые метрики не приживутся и вы от них решите отказаться – это нормальная практика.

Курсы для руководителей тест-команд от «Лаборатории Качества»

Подробнее о метриках и том, как руководить командой, рассказываем на наших курсах:

  1. Для тех, кто только собирается стать тест-менеджером, а также с опытом 1-2 года:

«Школа тест-менеджеров V-2.0»

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

Отзыв нашего выпускника:

  • Чтобы понять, необходим ли вам этот курс, пройдите этот тест
  • Первый вебинар курса доступен на YouTube!

2. Курс «Аудит и оптимизация QA-процессов» будет полезен для:

  • руководителей отделов тестирования,
  • QA-менеджеров,
  • тест-лидов.

С помощью выработанных нами алгоритмов за 6 недель вы научитесь:

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

Посмотрите первый вебинар курса: