Всем привет! Меня зовут Александр, я 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-сборки