- PVSM.RU - https://www.pvsm.ru -
Привет! Когда-то мы использовали метрику «Вроде бы стало лучше» для оценки качества наших релизов. Но потом мы решили довериться чему-то более надёжному. В этой статье я расскажу о том, как искал гайд по метрикам, не нашёл и создал свой.
Бывает ли у вас такое, что вы делаете вроде бы полезную работу для проекта, но не понимаете, приносит ли это пользу? Вот и мы когда-то писали автотесты, но не могли объективно сказать, стали ли лучше релизы монолита и других сервисов, в которых ведётся активная разработка.
Я посмотрел в интернете и почему-то не нашёл статей или готовых гайдов о том, как выбирать правильные метрики, как их собирать и что с ними дальше делать. Но пока искал информацию, нашёл полезные видео и статьи, которые помогли мне справиться с этой непростой задачей. Ссылки на них будут появляться в статье.
Надеюсь, что эта статья будет полезной для тех, кто задумался об измерении чего угодно на своем проекте, но не знает, с чего начать. В статье содержится личный опыт, информация из статей, видео и платных курсов.
Как можно увидеть, измеряли мы только то, что связанно с монолитом. Для остальных сервисов не измеряли ничего.
Перед вами чек-лист из 11 шагов, который поможет внедрить всё и не упустить ничего.
Поймите, для чего вы хотите начать измерять что-либо. Измерять просто так, ради измерений, не имеет смысла.
Мы, например, хотели знать, как движемся к целям по качеству, которые поставили себе ранее. Ещё мы хотели видеть динамику показателей после приложенных усилий. Сами по себе цифры текущего состояния ничего не значат. Это просто цифры. Но, наблюдая цифры в динамике, мы можем видеть влияние наших действий.
Вам нужно понять, к чему вы стремитесь. Сократить время тестирования? Сократить количество критичных багов в проде? Повысить тестовое покрытие?
В моём случае с определением целевых показателей проблем не возникло, так как в нашей компании есть цели по качеству. Эти цели и стали основой будущих метрик. Наши цели:
Подумайте, как вы поймёте, что движетесь к целевым показателям.
На этом этапе работы мне помогла статья «Самые важные метрики QA [2]».
Это время мы разбили на 4 этапа: подготовка стенда, озеленение стейдж пайплайна, ручное регрессионное тестирование, деплой на прод.
Мы разбили это время на этапы, чтобы детально видеть последствия наших действий и иметь возможность точно определить бутылочное горлышко в нашем процессе.
Этапы метрики «Время на релиз»
Важно! Не берите сразу много метрик. Три-четыре для начала достаточно. Когда процесс наладится, сможете добавить ещё, если это потребуется.
Много метрик сложно менеджерить. Растёт вероятность, что система не взлетит. А если процесс не взлетит с первого раза, то в следующий раз начинать будет сложнее, так как у вас и сотрудников за плечами будет негативный опыт.
Разные показатели можно считать в разных единицах измерения. Сразу нужно выбрать, чтобы у всех метрик была одна единица измерения, иначе можно столкнуться с непониманием и неправильным толкованием.
С этим пунктом у нас возникли проблемы. Время релиза мы считали в часах, включая ночные часы, но за исключением выходных дней. При этом целевое значение было – релиз за 4 часа. Довольно часто случались ситуации, когда мы создавали ветку release-xxx в 16:00 сегодняшнего дня, а заканчивали в 10:00 следующего дня. В нашей метрике считалось 18 часов, но по факту, активные действия проводились всего 3 часа, если не меньше.
Если бы мы продолжали считать таким образом, то никогда не достигли бы показателя «4 часа» по нашей метрике. Встав перед выбором, увеличить цель до 12 часов или брать в учёт только рабочие часы, мы выбрали второе.
В видео «Простые метрики тестирования на практике [3]» спикер предложил крутой способ анализа метрик на пригодность. Нужно ответить на 9 вопросов по каждой метрике и принять решение.
На эту метрику «Время на релиз» будет смотреть продакт оунер (потому что ему важно понимать, сколько релизов за спринт мы успеваем выкатить), разработчики (потому что они хотят понимать, когда их код будет на проде) и тестировщики (так как время на тестирование напрямую влияет на эту метрику).
После такого нехитрого анализа сразу становится ясно, нужна ли вам эта метрика или нет. Появляется более глубокое понимание самой метрики и её ценности для компании и вас.
Покажите выбранные метрики тем, кого они будут затрагивать. Обсудите ограничения, которые вы выяснили на этапе анализа, а также способы их устранения или хотя бы снижения. Особенно важно получить согласие и одобрение тех, кто эти метрики будет собирать и заполнять.
Свои метрики я обсуждал в 3 этапа: с тестировщиками, разработчиками и продакт оунерами. Только после того, как все дали явное согласие, что эти метрики показывают качество системы, я смог перейти к следующему шагу.
Люди не будут вчитываться в таблицы и смотреть динамику самостоятельно. Поэтому вам нужно позаботиться о наглядности.
Я сделал таблицу в Google Sheets, написал формулы и довольный хотел презентовать таблицу коллегам. Наш CTO предложил визуализировать эти метрики. Точнее сделать так, чтобы за 15 секунд было понятно текущее состояние системы: стало ли лучше по сравнению с прошлым спринтом или качество снизилось.
Совместными усилиями мы визуализировали показатели. Потом я попросил людей рассказать, что они увидели на этом графике. Судя по ответам, цели мы добились.
Вот как выглядит визуализация метрики «Качество релизов». Всё наглядно, сразу видно, как сейчас и как было, превышает ли количество проблем количество релизов, стало лучше или хуже по сравнению с предыдущими релизами. В идеальном графике, синяя линия должна стремиться к бесконечности, а красная должна стремиться к 0.
Визуализация отношения «проблемных релизов» к общему количеству релизов
Важно наладить процесс сбора метрик, поработать над периодичностью. Если процесса не будет, то ваш дашборд потеряет актуальность и умрёт. Важно, чтобы были заинтересованные лица, которые будут этим заниматься. Но если вы озаботились этим, значит заинтересованное лицо уже есть.
Какой бы ни был красивый ваш дашборд, люди не будут туда ходить и смотреть на метрики. Один раз все посмотрят, так как это что-то новенькое, но не на постоянной основе.
Нужно смотреть на метрики, на их основании принимать решения. Можно использовать метрики, как дополнительный аргумент в пользу написания дополнительных тестов или фокусировке на техническом долге, а не на бизнес фичах и т.д.
Максимально автоматизируйте сбор метрик. Если вы используете популярные TaskMS и TestMS системы контроля версий, системы CI/CD, скорее всего, у них у всех есть открытое API, с помощью которого можно легко вытаскивать эту информацию. Если не умеете сами, просите помочь разработчиков. Возможно, для этого придется изменить некоторые процессы. Это нормально. И это малая цена за те преимущества, которое вы получите, начав собирать метрики.
Например, у нас есть бот [4], которой помогает релизменам катить релиз и сокращает их рутинные действия.
Принимать решения, которые повлияют на качество продукта, основываясь на ваших внутренних чувствах – плохая затея. Чувства могут обмануть и подтолкнуть вас к неправильному решению. Поэтому просто заведите метрики и систему оценки качества.
Но помните, что заведение метрик – как заведение питомца. Кроме профита от общения с новым другом, вы получаете определённую ответственность и обязательства перед ним. Поэтому заводите метрики осознанно, с пониманием их необходимости и готовностью к преодолению сложностей, ожидающих вас на пути.
Автор: e-ivanchenko
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/330659
Ссылки в тексте:
[1] Stop the Line: https://habr.com/ru/company/dodopizzaio/blog/460191/
[2] Самые важные метрики QA: https://doitsmartly.ru/all-articles/sw-testing/133-the-most-important-metrics-in-qa.html
[3] Простые метрики тестирования на практике: https://www.youtube.com/watch?v=Yltn201VvNg&t=2293s
[4] у нас есть бот: https://habr.com/ru/company/dodopizzaio/blog/456806/
[5] Источник: https://habr.com/ru/post/468007/?utm_campaign=468007&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.