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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Метки
css (1)html (1)ISTQB FL (6)IT (1)Java для тестировщиков (1)Jedi Point (16)JSON (1)kaizen (2)Pairwise Testing (1)QA (25)QualityLab (1)REST API (1)selenium (1)SOAP UI (1)softskills тестировщика (7)SQA Days-25 (1)Sql в тестировании (7)TestSuites (1)XML (1)xpath (1)Анна Палей (1)Исследовательское тестирование (4)История успеха (18)Курс тестирования для начинающих (23)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)Обучение тестированию (19)ПОИНТ (59)Роман Буданов (3)Сессионное тестирование (1)ТЗ (1)Таблица решений (1)Тест-анализ (3)Тест-дизайн (6)Тест-кейс (1)Тест-стратегия (1)Тест-туры (1)Тестирование usability (6)Тестирование ПО (17)Тестирование игр (5)Тестирование мобильных приложений (6)Тест менеджмент (5)Чек-лист в тестировании по (5)Чит-лист в тестировании (2)автоматизация тестирования (2)автотесты (1)английский для тестировщиков (6)аудит проекта (8)баг (3)багнапродакшене (1)введение в тестирование (1)виды тестировния (2)войти в айти (2)выгорание (1)граничные значения (1)декомпозиция (1)инструменты тестирования по (6)интервью с выпускником (4)как надо тестировать (2)как стать тестировщиком (2)комбинаторика в тестировании (1)мануальное тестирование (1)метрики тестирования (3)начать карьеру в IT (10)начинающий тестировщик (13)негативное тестирование (2)ограничения (1)оптимизация QA-процессов (1)организация тестирования (1)персонажи (1)планирование тестирования (1)профессия тестировщик (3)резюме (1)ручное тестирование (1)сертификация ISTQB FL (5)скринкаст (1)смена работы (6)сопроводительное письмо (1)тест-кейс (1)тест-менеджмент (4)тестирование безопасности (1)тестирование веб (5)тестовая стратегия (1)удаленная работа (2)управление требованиями (6)фреймворк тестирования (1)школа тест-менеджера (5)
С 14.12 по 2.03, ОНЛАЙН Зарегистрироваться