Как подобрать 2-3 объективные метрики для проекта, которые просто собирать?

Коллеги, добрый день!

С вами рубрика ответов на вопросы руководителей тест-команд, обучающихся у нас на курсах.

Вопрос от слушателя:

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

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

Другой пример из практики – у меня под аудит попадали 6 разных проектов с разными командами и процессами. Срок жизни проекта около года. На начальном этапе Jira – это просто помойка, никто не хочет правильно проставлять статусы, никто не следит за списанием времени. В итоге метрики не могут показать правильный результат, потому что исходные данные всегда не актуальны. Поэтому я наоборот стал отталкиваться от тех метрик которые проще собирать, например, число багов, которые заводят тестировщики. Но это слишком косвенные показатели, а я хотел серебряную пулю) Есть ли 2-3 метрики, которые очень просто собирать и которые будут более менее объективными? Чтобы начинать с них аудит проектов, а потом уже расширять по мере улучшения процессов на проектах.

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

Руководствуясь правилом «если сбор сложен, не используй метрику»,  я  по сути должен вообще отказаться от сбора метрик.

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

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

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

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

А зачем вам привязывать пропуски к релизам? Почему бы не провести анализ причин всплеска? Так вы узнаете лучше, как пользователи применяют ПО, и продумаете меры по предотвращению таких ежемесячных пиков.

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

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

…а я хотел серебряную пулю) Есть ли 2-3 метрики, которые очень просто собирать и которые будут более менее объективными? Чтобы начинать с них аудит проектов, а потом уже расширять по мере улучшения процессов на проектах.

Универсальных метрик, к сожалению, (а может быть и к счастью ????) – нет. Все проекты уникальны, и подходы также будут уникальны. И у каждого проекта, причем даже внутри проекта, для разных этапов своя серебряная пуля!

Поэтому при подборе метрик советую прежде всего продумать, с какой целью вы планируете это сделать? Какие проблемы и как это поможет решить? Будет ли польза от затраченных усилий? И только потом думать о метриках. В тоже время спешить внедрить всего побольше и побыстрее – не стоит. Выберите вначале парочку метрик, поработайте с ними, оцените результат. Есть профит – отлично, нет профита – не конец света! Думаем дальше, подбираем другие варианты!

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

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

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

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

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

Мы открыли первый вебинар этого курса

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


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

За 6 недель, применяя выработанные нами алгоритмы, научитесь:

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

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