Привет! Меня зовут Андрей Романюк, я руковожу группой качества WEB в онлайн-кинотеатре Okko. В этой статье я расскажу о процессе, с помощью которого мы снизили количество багов, которые мы выкатываем в прод, когда мы о них уже знаем.(Естественно, мы всё равно их выкатываем, но таких багов в релизах стало намного меньше :) 

О чём поговорим:

• Истоки нашей проблемы,

• Как решили взвешивать баги,

• Какие результаты получили.

Поехали.

Истоки проблемы

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

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

Было? Было.

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

Но письма забудутся, а баги — останутся.

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

Как решили взвешивать баги

Для взвешивания багов мы добавили поле Count в Jira. Цифра в нём позволяет сравнить два одинаковых бага по приоритету, показывая степень влияния бага на пользователя. Чем больше цифра, тем сильнее влияние, а значит — тем скорее нужно пофиксить проблему.

Для взвешивания багов используем два критерия:

• Охват бага — в какой доле пользовательских сессий он появляется;

• Барьерность бага — насколько серьёзные неудобства баг доставит пользователю.

Получается формула:

Итоговый count бага = Охват * Барьерность * 10 000

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

Охват

Для оценки охвата используем таблицу, в которой собрали рассчитанные аналитиками частоты тех или иных событий. Для этого мы попросили CX-специалистов собрать все сценарии c которыми сталкиваются пользователи. Например:

• авторизация,

• открытие главной страницы, 

• открытие меню,

• просмотр фильма/сериала,

• и т.д.

Собрав сценарии, пришли к аналитикам — они посчитали процент пользователей, столкнувшихся с этими сценариями. Например:

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

• Открытие главной страницы — коэффициент 0,9, а значит со сценарием взаимодействует 90% пользователей. Они попадают на главную каждый раз, когда заходят в приложение — кроме тех случаев, когда на вебе используют прямую ссылку, и попадают сразу на контент, потому и не 100%.

Барьерность

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

Если баг блокирует приложение, роняет сайт, не даёт авторизоваться или запустить плейбэк, пользователю нет смысла пользоваться сайтом — ставим барьерность 100.

Между двумя этими цифрами, конечно, есть градация.

Пример расчёта count

Баг: Пользователь после авторизации на ТВ (на любой модели) видит пустую pop-up подсказку, которая висит в течение трёх секунд, а потом исчезает. Пользователь при этом авторизован, а сайт работает нормально.

Рассчитываем по формуле:

0.11 (авторизация) * 0,55 (Любой ТВ) * 1 (не мешает пользователю) * 10 000 = 605

605 — наш count этого бага.

Максимально возможный count — 1 000 000, в этом случае все пользователи попадают на баг с барьерностью 100.

Какие баги взвешиваем?

Баги, которые уже есть на проде

Это позволяет приоритезировать бэклог — оценив таким образом все баги, мы понимаем, что брать в багфикс быстрее. Кроме того, общая сумма count даёт понимание того, насколько забагован сервис. Сравнив суммы нескольких месяцев мы можем понять, насколько эффективно работаем: снижаем общую сумму count, она растёт с каждым релизом или стоит на месте.

Баги, которые потенциально уйдут в прод с фичей

Получаем оценку того, насколько увеличим количество багов в проде.

Приоритет на основе count

Задаём его, опираясь на конкретные значения count — это делает процесс более объективным.

Разбили приоритеты от lowest до blocker на конкретные цифры, где:

• lowest = count <10

• blocker = count ≥ 50 000

Оружие QA

Count багов позволяет нам доходчиво объяснять нашу позицию.

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

В письме указываем, что релиз готов и протестирован, в нём поедет фича вот с таким количеством багов и таким-то count. Еще — общий count всех багов релиза.

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

Результат

Объем багов с count выше 100 на проде резко сократился. Если count 90 или меньше, мы еще можем согласится на выпуск релиза. Если в релизе присутствуют баги с Count более 100, то по договоренности с PM такой релиз не едет в прод, а все баги с таким Count фиксятся. И только после фикса релиз отдаем пользователям.

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

Цифры в count объективно показывают влияние багов на пользователей и их охват. Это делает процесс взвешивания багов прозрачным для всех участников процесса — не только QA, но и продакты понимают, как забагованность фичи повлияет на прод и на конечного пользователя.

Автор статьи https://t.me/RAV_2549

Другие лайфхаки и хитрости основанные на опыте в работе с высоконагруженными системами на HighLoad++ 2025. Программа и другая полезная информация — на официальном сайте конференции.