Система Quality Score: как оценивать внешнее качество продукта

Всем привет! Меня зовут Александр, я Head of QA в Авито. Я расскажу, как мы разработали и внедрили собственную композитную метрику качества, которую назвали Quality Score. 

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

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

Что подразумевается под словом «качество»

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

Как выбирали самые важные метрики для оценки

За годы работы в Авито накопилось множество метрик, которые отражают качество работы. Кроме этого каждую функциональность разрабатывает самостоятельная команда. Стандартизировать все процессы, связанные с QA, в них пока что невозможно, но мы все равно постарались найти универсальное решение.

На вход в задачу у меня было куча разных показателей, например: 

• количество заводимых багов;

• обращения в службу поддержки;

• время деградаций каждого микросервиса;

• процент крэшей на мобильных приложениях;

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

Основной задачей было понять насколько Авито выглядит качественным для конечных пользователей. Человеку будет абсолютно всё равно, какой процент покрытия юнит-тестами back-end сервиса, если он не может посмотреть номер телефона или написать продавцу. По этой причине в первую очередь я отмёл все метрики, связанные с внутренним качеством. 

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

Какие метрики попали в систему оценки

Баги, про которые пишут в поддержку

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

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

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

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

Чтобы отвязаться от абсолютных значений, мы решили взять соблюдение SLA на время реакции и исправления багов. У нас принята шкала приоритета багов P0-P4, где P0 — самый высокий.

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

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

Crash-free users

Для мобильных приложений у нас есть целевые показатели по crash-free на уровне всей компании. Для того чтобы контролировать уровень крэшей мы разработали механику Crash Budget. 

На самом деле она заслуживает отдельной статьи, поэтому здесь я опишу кратко. Crash Budget — это допустимый процент крэшей для конкретной команды, появляющийся в их коде. Если команда выходит за рамки своего крэш-бюджета, это ещё не значит, что мы не достигаем своих целей по crash-free на уровне всего приложения. Но вот если эта команда очень долго превышает бюджет, то срабатывает теория разбитых окон: другие подразделения снижают планку по качеству и в приложении начинают накапливаться крэши. В этом случае общее качество в рамках всего приложения падает и целевые показатели в опасности. Для метрики качества мы выбрали количество дней за месяц, когда команда превышала свой бюджет на крэши.

Время инцидентов

Если пользователь заходит на сайт и получает 500 ошибку — всё пропало. В инциденте нам важно время его устранения и у нас есть отдельный процесс работы с ними. Если инцидент зарегистрирован нашими системами и оценен как critical или major, то мы учитываем его в нашей композитной метрике качества.

Как оценивали уровень качества с помощью выбранных метрик

Для большей точности метрики, отвечающие за crash-free и баги, о которых сообщают в техподдержку, мы разделили на подкатегории:   

• Время инцидента

• % багов всех приоритетов, на которые команда отреагировала в установленные SLA

• % багов приоритета P0-P2, которые команда пофиксила в установленные SLA

• Количество дней, когда команда не превышала свой Crash Budget по iOS

• Количество дней, когда команда не превышала свой Crash Budget по Android

Далее мы задали определённые трешхолды для каждой из метрик и сказали, что за каждую область можно получить максимум 1 балл. Если всё плохо, то это 0 баллов, за промежуточное состояние выдаем 0,5 балла. Например, если на 60% багов команда отреагировала вовремя, то мы выдаем ей 0,5 балла. Все баллы по пяти метрикам мы складываем и получаем финальный Quality Score. В максимуме можно набрать 5 баллов. 

Рассмотрим подсчет на конкретных примерах:

Команда 1 за июль:

• Не имела крупных инцидентов за месяц => 1 балл

• Процент реакций в рамках SLA на новые баги был 90% => 1 балл

• Имеет 25% просроченных багов по SLA на фикс => 0,5 балла

• Не превышала количество дней по Crash Budget iOS => 1 балл

• Не превышала количество дней по Crash Budget Android => 1 балл

Итого Quality Score Команды 1 — 4,5 /5 

Команда 2 за июль:

• Имела один крупный инцидент длинной больше 15 минут => 0 балла

• Процент реакций в рамках SLA на новые баги был 90% => 1 балл

• Имеет 50% просроченных багов по SLA на фикс => 0 балла

• Не превышала количество дней по Crash Budget iOS => 1 балл

• Не превышала количество дней по Crash Budget Android => 1 балл

Итого Quality Score Команды 2 — 3 /5

Как тестировали и корректировали систему

Для обкатки я и команда QA Center of Excellence провел масштабное исследование. Мы построили аналитику и посчитали Quality Score для всех команд разработки Технического департамента Авито. На основе полученных результатов определили анти-топ команд с самым низким баллом в Quality Score. 

Затем в эти отстающие команды «высадили» QA-экспертов, чтобы помочь им повысить качество и провалидировать те данные, которые нам показывает аналитика. Вот какие результаты мы получили: 

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

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

Когда вы вводите новую абстракцию, а Quality Score — это абстрактная сущность, то одна из важнейших задач — нужно чтобы в неё поверили. Для этого вы должны хорошо проверить качество данных. А после нужно внедрить систему во всей компании и сделать ее привычным инструментом для работы.

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

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

Недостаточно просто создать, провалидировать и рассказать про метрику, важно её регулярно отслеживать и ставить по ней цели. Мы добавили в операционные ревью руководителей Технического Департамента отчёты и отсмотр метрики, чтобы следить за ее развитием. Некоторые руководители взяли годовые цели, чтобы поддерживать Quality Score в их командах на должном уровне. Так же систему использует наш кластер Quality для того, чтобы понять на чем фокусировать своё внимание.

Что в итоге

• Для каждой компании наполнение Quality Score будет разным, в зависимости от внутренних процессов и текущих фокусов;

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

• Метрики внутри Quality Score должны быть «экшенабл» — команда должна точно понимать, что нужно сделать, чтобы повлиять на показатель. В противном случае получится просто шейминг сотрудников без возможности изменить ситуацию. Вместе с созданием метрики качества обязательно должна быть ее валидация в реальных условиях;

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

Предыдущая статья: Как мониторить здоровье вашей Gradle-сборки