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

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

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

Почему единые метрики качества — это важно

«Когда вы можете измерить то, о чем вы говорите, и выразить это в числах, вы знаете кое-что об этом; но если вы не можете измерить это и выразить в числах, ваше знание скудно и неудовлетворительно». Лорд Кельвин

Прежде чем запустить новый бизнес, внедрить новые технологии или подходы, мы всегда задаемся вопросом: «Зачем?» Какую выгоду получим, как много денег сможем заработать или сэкономить.

Так зачем компании тратить время и ресурсы на проработку и внедрение метрик качества?

Метрика программного обеспечения — численное значение свойства разрабатываемого программного обеспечения.

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

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

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

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

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

Шаг 1: сбор информации и анализ. Изучаем, что есть у разных команд

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

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

Потом мы проанализировали ответы на вопрос: «Как вы отличаете дефекты теста от дефектов прода?» — и обнаружили первую проблему.

Дефекты прода — дефекты, найденные на прод-среде после завершения тестирования и выката на продакшен.

Дефекты теста — дефекты, найденные на любой из тестовых сред.

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

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

• Type;

• TI Environment;

• Bug Environment;

• Bug Category.

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

Шаг 2: проработка метрик. Что будем измерять

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

Расскажу, что у нас получилось.

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

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

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

Увеличение количества дефектов не всегда говорит об ухудшении качества. Перед тем как делать выводы, нужно проверить количество задач и группу графиков «Соотношение задач и дефектов» и «Состав релизов». 

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

Большое количество отмененных дефектов на тесте может указывать:

• на недостаточное понимание бизнес-процессов командой тестирования;

• недостаточную проработку и прозрачность бизнес-требований.

Большое количество отмененных дефектов на проде может указывать:

• на низкое качество обучения пользователей, которые работают с системой;

• низкое качество обучения линий техподдержки.

Состав релизов показывает, какая часть релиза — дефекты тестирования и продакшена.

Большой объем дефектов тестирования может означать низкое качество разработки и/или требований, что негативно сказывается на скорости тестирования.

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

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

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

В командах, которые релизятся ежедневно, график плохо читается и малоприменим.

Соотношение дефектов и задач показывает, сколько в среднем дефектов заводится на одну задачу. 

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

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

Если коэффициент получился >0,1, значит, что каждый десятый дефект не был обнаружен во время тестирования и привел к проблемам в ПО на продакшене. Также может говорить о необходимости расширения регресса и недостаточном покрытии или отсутствии Unit- и нагрузочных тестов.

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

Преобладание дефектов Blocker и Critical на проде может говорить о следующем:

• команда плохо работает с приоритетами;

• бизнес-заказчики искусственно поднимают приоритет дефекта, чтобы «мою задачу сделали быстрее»; 

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

Преобладание дефектов Blocker и Critical на тесте может говорить о следующем:

• команда плохо работает с приоритетами;

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

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

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

Каждая команда выбирает для себя наиболее подходящие категории.

Время жизни дефектов, найденных на проде, по приоритетам показывает, насколько быстро происходит исправление дефектов на тесте и проде, в зависимости от их приоритетов.

Время жизни дефекта — время от заведения дефекта (create date), до его завершения (resolution date).

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

Графики помогают командам проанализировать насколько хорошо они выполняют свои SLA по времени исправления дефектов.

Примеры SLA:

• Blocker: 1—3;

• Critical: 1—3;

• Major: в рамках релиза;

• Minor: на усмотрение команды.

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

Задачи с большим количеством дефектов должны разбираться командой на ретро — вырабатываться шаги к снижению количества дефектов и повышению качества разработки.

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

Стабильно небольшое количество Acceptance Bug может, с одной стороны, говорить о действительно качественной разработке или аналитике, но с другой стороны, это может быть показателем «каши» в дефектах.

Шаг 3: реализация. Внутренний инструмент Team meter

Этот шаг можно только условно назвать третьим, потому что продумывать реализацию и выбирать инструмент мы начали значительно раньше. Незадолго до нашей активности с дашбордом качества в Тинькофф реализовали внутренний инструмент Team meter.

Team meter — это self-service платформа, которая помогает командам работать с метриками. «Из коробки» позволяет получить настроенные дашборды и метрики по процессам поставки. Team meter идеально подходил под наши цели, потому что уже автоматически собирал все необходимые данные из Jira. Для визуализации настроили интеграцию с Metabase.

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

Создать дашборд команды можно в несколько шагов:

1. Выбрать дашборд, который хотите построить.

2. Ответить на несколько простых вопросов.

3. Нажать «Отправить».

4. Дашборд создан.

Сейчас команды могут создать два дашборда: 

• дашборд качества с большим количеством графиков про тест и прод;

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

Вот так выглядят рабочие дашборды:

Шаг 4: внедрение в команды и популяризация

Внедрение — самый сложный шаг процесса. Расскажу почему.

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

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

Единые метрики не будут работать без единых подходов, а значит, нужно не просто внедрить новый инструмент и научить с ним работать, но и доказать командам необходимость корректировки их процессов работы в Jira.

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

Вот что мы сделали, чтобы внедрить новый инструмент с метриками в команды:

1. Написали статью, в которой отразили, как пользоваться инструментом, что нужно сделать, чтобы создать свой дашборд с метриками качества. Сделали рекомендации по использованию полей в Jira и рассказали про каждый график — зачем он нужен, как строится и как его анализировать.

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

3. Дали возможность каждой команде прийти в личку и получить консультацию по построению дашборда и внесению изменений в процессы работы с дефектами.

4. Организовали еженедельные посты на все сообщество QA в корпоративном мессенджере. Каждый пост рассказывал про одну метрику.

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

В итоге было создано 530 дашбордов качества, каждый месяц прибавляется еще по 10. Активны примерно 160 дашбордов ежемесячно. Базовых дашбордов создали 95, ежемесячно прибавляется по 20, и активными остаются около 65. 

Заключение

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

Небольшой гайд по процессу:

1. Метрики, которые мы выбрали для себя:

• созданные и закрытые дефекты

• отмененные дефекты

• состав релизов

• отношение заведенных дефектов к закрытым задачам

• коэффициент ошибок, пропущенных на прод

• распределение по приоритетам

• время жизни дефектов по приоритетам

• распределение дефектов по категориям

• распределение по компонентам

• количество аксептанс багов на задачу

• % пропускаемых на прод высокоприоритетных (Blocker+Critical) дефектов

2. Проблемы:

• Система должна быть измерима.

• Недостаточно придумать удобный инструмент, его нужно «продать» командам.

• Без драйвера (один человек или команда) провернуть реализацию и внедрение на всю компанию невозможно.

Дальнейшее развитие:

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

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