Это мой первый пост здесь, и начать хочу с того, в чём у меня больше всего практики, с выстраивания процессов в QA. Меня зовут Никита, я QA Lead. Расскажу, как мы перестали копить баги и перешли от «веса» бэклога к SLA на исправление. Этот процесс я запускал в двух разных компаниях, и оба раза он прижился.

Знакомая ситуация: баги заводятся, но до них не доходят руки. Продуктовые задачи всегда важнее, ошибки уезжают в низкий приоритет, бэклог растёт. Так было и в нашем направлении, где работало около 10 продуктовых команд. Я участвовал во внедрении процесса как QA Lead. Ставил задачи, настраивал процесс, проводил встречи с командами, контролировал заполнение метрик и работал с сопротивлением. Расскажу, как это было.

Этап 1. Увидеть реальную картину: вес бага Мы ввели вес bug-репорта из четырёх параметров: приоритет, модуль или экран, где находится баг, влияние на продукт. После разметки стало видно, какой вес у каждой команды и у направления в целом и где качество просело сильнее всего. Дальше мы ставили цель на сезон, например снизить вес вдвое. Главный инструмент баг-спринты: неделя, когда команда разбирает максимум накопленных ошибок. За три сезона общий вес направления снизился примерно на 70%.

Этап 2. Не дать бэклогу вырасти снова: Zero Bug Policy

Первый этап помог разгрести накопленное, но не мешал копить заново. Поэтому дальше мы перешли на Zero Bug Policy: каждый новый баг сразу попадает в спринт и получает срок. Каждая задача проходит два SLA подряд. SLA на принятие решения: 1–2 дня. Команда утром на дейли разбирает свежие баги (обычно 1–2, иногда ни одного) и сразу их планирует.

SLA на исправление, по приоритету: Блокер — 8 часов Критический — 3 дня Высокий — 1 спринт Средний — 2 спринта Низкий — 3 спринта

Приоритет считается автоматически из шести параметров: где нашли баг, где он сейчас, экран или модуль, платформа, влияние на пользователя и кто нашёл. Баги заводятся через форму, а если поле пропущено, напоминает бот.

Сопротивление

Добровольно переходить на «принудительную починку» никто не хотел: копить баги было привычнее. Поэтому мы долго и аккуратно готовили почву: объясняли, зачем это нужно, и заранее обсуждали метрику с командами. Стартовали с пилота на 2–3 командах. Когда у них появились результаты, показали их всем и официально запустили процесс на уровне направления, с общими метриками на комитете.

Результат

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

— попадание в SLA выросло примерно с 50% до 85%+ — новые баги разбираются за 1–2 дня, а не висят неделями — бэклог перестал расти: вес держится на стабильно низком уровне

Главный вывод

Качество — не зона ответственности одного QA. Пока баги «принадлежат» тестировщикам, они проигрывают продуктовым задачам. Когда сроки исправления видят все, включая продакт-оунеров, и это влияет на оценку команды, баги перестают быть чужой проблемой.

А как работаете с багами вы: вес, SLA, zero bug policy или что-то своё?