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

Предыстория

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

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

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

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

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

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

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

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

Название
Приоритет
Окружение
Шаги воспроизведения
Ожидаемый результат
Фактический результат
Дополнительная информация
Связи

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

Пункты бага

Название бага

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

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

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

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

Приоритет

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

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

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

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

Блокирующий (сдачу фичи или сценарий пользователя) — сделать срочно
Критический (визуальные баги) — сделать в первую очередь
Средний приоритет — сделать во вторую очередь
Низкий — сделать когда будут свободны руки или никогда

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

Окружение

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

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

Версия frontend
Версия backend
Браузер (ы) + версия браузера
Стенд (или ветка git)

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

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

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

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

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

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

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

Требования:

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

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

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

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

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

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

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

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

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

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

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

Связи

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