С 14 по 27 июня пройдет онлайн-конференция для тимлидов Podlodka Teamlead Crew!

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

# Описание

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

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

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

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

Для команды:

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

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

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

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

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

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

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

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

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

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

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

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

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

# Практика

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

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

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

# Zero Bug Policy

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

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

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

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

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

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

# Консультации

# Теория

# Статьи