# Работа с багами

# Описание

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

# Почему ветка важна?

Баги в системе – это неправильное поведение системы. Слишком большое число критичных багов приводит к сильной деградации системы и в конечном счёте отражается на продуктовых метриках.

Что процесс даёт для разных ролей. Для лида: Контроль за состоянием системы. По динамике наполнения и разбора багов можно делать выводы как о проблемах в продукте, так и о работе команды разработчиков.

Для команды:

Понятный план действий при обнаружении бага.
Понимание, как неправильное поведение системы будет устраняться.

Для продукта и пользователей:

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

# Что будет, если её не делать?

Непонятно кто и когда будет его разбирать. Разное представление об этом можем вызывать конфликты в команде.
В процессе разработки системы неизбежно появляются новые баги. Без процесса происходит неконтролируемая деградация.

# На кого может быть делегирована?

На старших QA-специалистов в команде или компании. На Scrum-мастеров, продактов.

# Примеры поведения

# Примеры плохого поведения

Найденные баги никуда не заводятся и, как следствие, никогда не исправляются.
Как и куда заводить баги знают только QA-специалисты.
Все найденные баги должны исправляться немедленно.
Бэклог растёт значительно быстрее, чем разбирается.
Задачи от начальства автоматически получают максимальный приоритет вне зависимости от их реальной критичности.
В бэклоге много старых багов.

# Примеры хорошего поведения

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

# Способы прокачки

# Практика

У любой системы работы с багами есть несколько составляющих:

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

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

# Zero Bug Policy

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

Идея Zero Bug Policy в том, что баги не хранить. Фактически предлагается баги раскладывать на две группы:

Критичный, потому дёргаем стоп-кран и правим его в этом же спринте.
Не столь критичный, потому забываем о нём. Если каждый такой баг складировать, бэклог будет только расти.

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

Критика данного метода основывается на следующем:

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