bug-report.md

Баг-репорт

Хороший баг-репорт позволяет:

1. Воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. Понять, в чем проблема и какова ее важность.

Как написать хороший баг-репорт?

Для начала надо подготовиться. Если вы обнаружили баг, не стоит моментально бежать в баг-трекер и писать «ничего не работает!». Воспроизведите ошибку. Воспроизвелась? Отлично. Не воспроизвелась? Значит, что-то вы не учли. Вспоминайте, что делали.

Снова воспроизвелась? Ура! А теперь минимизируйте количество шагов для воспроизведения, удостоверьтесь, что нет ничего лишнего.
Если используются какие-то входные данные, удостоверьтесь, что и они не содержат лишнего (действительно ли весь этот здоровенный кусок текста роняет редактор, а не один символ из него?).

Затем заводим баг в системе баг-трекинга:

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

Пример плохого заголовка: «Все виснет, когда я вставляю текст из буфера обмена»
Пример «более хорошего» заголовка: «Редактор зависает при вставке текста, содержащего символ N, из буфера обмена по Ctrl+V»

Старайтесь не писать фразы типа «я кликаю на ссылку», «я нажимаю кнопку» и им подобные. И заголовок, и описания шагов — это руководство к действию для тех, кто будет исправлять проблему, поэтому лучше формулировать как «кликнуть на ссылку», «нажать на кнопку».

В Описании приводим шаги воспроизведения.

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

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

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

Но вставлять скриншоты в каждый баг-репорт совершенно не обязательно: пожалуйста, не плодите лишних сущностей. Если он ничем не поможет в воспроизведении проблемы — не тратьте время на его изготовление.

Кстати, про видео воспроизведения ошибки: оно может помочь разве что для подтверждения, что проблема действительно есть, просто воспроизвести ее сложно.

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

Приоритет бага

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

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

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

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

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

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

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

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

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