Как правильно составить Баг-репорт

Баг (от англ. Bug) – сленговое обозначение ошибки программы. Баги выявляются в результате тестирования. Для их устранения необходимо заявить о проблеме разработчику, а значит – составить баг-репорт.

Какова цель баг-репорта?

  1. Воспроизвести обнаруженную проблему.
  2. Понять, в чём именно проблема и насколько она важна.

Чтобы воспроизвести проблему, необходимо описать шаги, выполнив которые, можно её увидеть. Поэтому не стоит заводить баг сразу же, как только вы увидели ошибку. Нужно сначала повторить её. Не удаётся повторить – значит, возможно, пропущены важные шаги. Вспоминаем, что делали. Как только выявлен порядок действий, который приводит к ошибке, необходимо минимизировать количество шагов: убрать лишние, не влияющие на исход. Затем заводим баг в системе баг-трекинга:

Создание бага в системе

Кратко формулируем в Теме суть по принципу «Что? Где? Когда?»: что не правильно, где именно, при каком условии.

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

В Описании приводим шаги воспроизведения. Лишних не пишем, необходимых не пропускаем. Руководствуемся принципом “Что делали? Что получили? Что должны были получить?”

Описание бага

Если нужны исходные данные для воспроизведения – прикрепляем файлы. Если проблема визуального характера, то вставляем скриншот (для этого можно воспользоваться, к примеру, приложением Lightshot), а в качестве ожидаемого результата – ссылку на дизайн. На скриншоте нужно обязательно указать стрелочками/подписями, в чём проблема (желательно прямо на параллели со снимком дизайна):

Скриншот бага

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

Затем необходимо указать окружение, в котором появляется проблема: модель устройства, версия ОС, браузер. Если в нескольких – перечисляем все. Например: Win8 Chrome, MacOS 10.9 Safari, Sony Xperia Z Android 4.4.2 Chrome.

Приоритет бага зависит от конкретного проекта и его особенностей. Но в общем случае выставляется по важности:

  • Blocker – проблема блокирует функционал.
  • High – серьезные проблемы функционала, задевающие основной сценарий/главные фичи, которые нужно исправить в первую очередь.
  • Normal – стандартные баги функционала/ верстки.
  • Low – опечатки, мелкие баги верстки.

Назначить баг следует тому разработчику, который занимается соответствующим функционалом/версткой: тому, что выполнил часть, в которой обнаружен баг. В Версии указываем версию продукта, в которой обнаружена проблема. В Development Category тип: функционал, бэк, фронт, верстка и т.п. В Наблюдатели ставим менеджера проекта.

Параметры задачи

Чего делать нельзя:

1. Нельзя заводить несколько проблем в одном баге.

Одна проблема – один баг в баг-трекере. Если проблемы связаны, относятся к одному модулю – можно создавать их в виде связанных задач. Но ни в коем случае не в одной!

Связанные задачи

Чем плох баг-репорт с несколькими багами в одной задаче? Это значительно замедляет процесс их устранения. Ведь после фикса бага разработчик переназначает задачу на тестировщика для верификации. Таким образом, если у него несколько проблем в одной задаче – он не сможет отдать их на верификацию, пока не исправит все. Когда же каждый баг оформлен в отдельную задачу, тестировщик сможет приступить к верификации намного раньше. Таким образом, жизненный цикл бага (переоткрытие, закрытие) проходит быстрее, и софт быстрее продвигается к релизу.

2. Нельзя заводить как баг то, что не имеет отношение к Спецификации проекта.

Т.е. если поведение программы не прописано в Спецификации так, как по нашему мнению должно быть – это не баг. Не нужно отнимать у разработчиков время на работу, которая не согласована. Такие вещи можно завести как Feature, согласовав предварительно с менеджером проекта.