В помощь IT-команде — «Регламент создания баг-репортов» или «Как сделать задачу ясной для тебя из отпуска»

Предыстория

Данный регламент я написал на основании опыта работы лидом в IT компании с веб-приложением. Пункты из него прошли проверку практикой. Изначальные версии были (естественно) основаны на best practice из интернета, agile и опыта предыдущих и текущих руководителей.

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

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

Данный регламент не ориентируется на какую-то определенную систему трекинга задач. Использование возможно как для JIRA, Kaiten, GitLab, Trello, так и для excel-таблицы.

Общая информация

Ключевые принципы создания баг-репорта:

• представьте что баг будет рассматривать человек, практически не связанный с разрабатываемым ПО (например: PM, скрам-мастер, разработчик из другой команды или вы, после отпуска); чем подробнее, четче и лаконичнее описан баг — тем лучше

• баг-репорт может стать неактуальным через некоторое время — это является нормой, но проверять его все равно придется (возможно через год-два)

• консультируйтесь с коллегами во вопросам вне своей компетенции, чтобы информация была полной, но не чрезмерной (много воды не даст найти источник)

При создании баг-репорта необходимо указать следующие пункты:

1. Название

2. Приоритет

3. Окружение

4. Шаги воспроизведения

5. Ожидаемый результат

6. Фактический результат

7. Дополнительная информация

8. Связи

Также вариативно к баг-репорту можно приложить дополнительную информацию в виде скриншотов (с указанием проблемы), видео, переписок, ссылок на другие задачи и др.

Пункты баг-репорта

Название

Этот пункт должен отражать в 3-5 словах общую проблему функциональность. Главный критерий названия — ясность для читающего.

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

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

P.S. Это крайне важный пункт. Умение корректно указывать название крайне ценно.

Приоритет

Это важность бага и его фикса для продукта.

Стандартно используется несколько критериев для оценки приоритета:

1. Влияние на ключевой сценарий

   • блокирование (↑) или не блокирование (↓)

   • видимость для пользователя (↑) или баг (условно) не видим (↓)

2. Периодичность воспроизведения

   • общая вероятность воспроизведения (выше шанс — выше приоритет)

   • постоянность воспроизведения (непостоянные ↓)

3. Другие факторы
   

   • важность для заказчика

   • срок сдачи задачи

   • важность для взаимодействующего отдела

   • и др.

Условно приоритеты могут быть:

1. Блокирующий (сдачу фичи или сценарий пользователя) — сделать срочно

2. Критический (визуальные баги) — сделать в первую очередь

3. Средний приоритет — сделать во вторую очередь

4. Низкий — сделать когда будут свободны руки или никогда

В зависимости от критериев даже визуальный баг может быть с низким приоритетом, а рефакторинг (изменение, невидимое пользователю) — критическим. Приоритет может быть изменен с течением времени. Первичная оценка делается на совокупности критериев и условных приоритетов (см. в скобочках приоритетов).

Окружение

Это совокупность ПО (с указанием версий) в котором воспроизводится баг. Данная информация воспроизведения и анализа.

Обязательными пунктами являются:

1. Версия frontend

2. Версия backend

3. Браузер(ы) + версия браузера

4. Стенд (или ветка git)

Шаги воспроизведения

Это use case — сценарий для воспроизведения бага. Данная информация необходима для воспроизведения и анализа. Чем подробнее указаны шаги — тем лучше. Допускается использование скринов с нанесенными указателями.

Требования к пункту:

• шаги формируются в виде перечисляемого списка

• шаги указываются с ключевой точки (логина/прихода на сайт и т.п.)

• шаги указываются максимально точно и подробно; лучше больше информации, чем меньше

P.S. При желании/необходимости использования скринов в шагах рекомендую использовать сноски и помечать скрины (пример: в тексте — «скрин 2», на картинке подписать сверху «2»). Это позволит значительно улучшить читаемость.

Ожидаемый результат (ОР)

Это результат, который должен наблюдаться в системе в условной норме.

Требования:

• скриншот с открытой консолью браузера на вкладке network (сеть)

• скриншот с открытой консолью браузера на вкладке console

• вкладки должны быть промотаны вниз

Если для ОР используется скрин дизайна из figma, то консоль не требуется.

P.S. Вкладку network можно скомбинировать с вкладкой console (клавиша esc в chromium при открытой вкладке network).

Рекомендации:

• указывать результат одной фразой или ненумерованным списком

• указывать ссылку на источник истины (это может быть задача, документация или человек)

Фактический результат (ФР)

Это реальный результат работы системы после выполнения указанных шагов.

Рекомендации и требования те же, что и в ОР.

Дополнительная информация

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

Отдельно можно указывать свои догадки по поводу бага. Это может быть крайне полезно в будущем при анализе бэклога или исправлении.

Связи

Это ссылки на задачи, проблемы, людей, документацию и др. с пометкой причины создания связи (если это позволяет функциональность).