Как составить грамотный баг-репорт: советы для новичков

Что такое Баг-репорт

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

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

В зависимости от вида проблемы отчет может включать ​​информацию об операционной системе, технических характеристиках системы, типе устройства и даже снимки экрана.

Зачем составлять отчеты, если была найдена ошибка? Давайте представим реальную жизнь, если разработчики решали бы задачи и устраняли проблемы в общем чате (например, в телеграм). Поступившая проблема легко могла бы потеряться в этом чате, а специалисты не взялись бы за ее решение, так как упустили бы или подумали на другого. Чтобы этого избежать, существует баг-репорт, где понятно прописывается проблема и назначается ответственный, кто будет ее решать.

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

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

1. Заголовок репорта следует писать четко и кратко. “Как корабль назовешь, так он и поплывет”. Здесь примерно такая же история. Постарайтесь сформулировать проблему в одном или двух предложениях, чтобы тестировщик могу ее сразу понять.
2. Предоставьте пошаговое объяснение бага: подробно опишите проблему: что нужно сделать, чтобы прийти к ней, и приложите все значимые снимки экрана. Но не нужно указывать все возможные промежуточные действия, как например, “нажмите кнопку включения компьютера”. 
3. Визуализируйте. Из предыдущего пункта вытекает еще правило: лучше всего прикладывать вложения (картинки, скриншоты) проблемы, особенно если это касается дизайна. Скриншоты должны показывать, где именно возникли ошибки, чтобы читатели могли легко воспроизвести их без предварительного доступа.
4. Определите обходные пути. Если возможно, предложите другие способы решения проблемы, которые сработали бы для вас.
5. Опишите свою среду: включите ​​информацию об используемом устройстве, версии ПО или браузере.
6. Объясните ожидаемые и фактические результаты: что должно произойти и что произошло на самом деле.
7. Укажите серьезность. Отметьте, насколько дефект влияет на процессы и работу. 

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

Шаблон баг-репорта

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

Итого у вас должен получиться такой пример репорта (представим, что этот отчет написал начинающий джун):

• Название:

Ошибка во времени загрузки страницы

• Описание:

При попытке загрузить N сайт страница загружается необычно долго (более 10 секунд)

• Действия по воспроизведению:

1. Откройте браузер N

2. Перейдите на сайт N

3. Обратите внимание на долгое время загрузки страницы

• Ожидаемый результат:

Страница должна загрузиться в течение нескольких секунд

• Фактический результат:

Страница загружается более 10 секунд

• Информация об ОС/браузере/устройстве:

Chrome версии 67 в Windows 10

Виды багов

Все ошибки можно разделить на разные типы: 

• Синтаксические. Баги, вызванные неправильным синтаксисом, например отсутствие знаков препинания, неправильное написание ключевых слов.
• Логические. Дефекты в базовой логике программы, вызванные неправильными предположениями или неправильной обработкой.
• Функциональные. Когда продукт не выполняет предназначенную для него функцию. Например, если вы не можете загрузить изображения или текст на странице своего профиля.
• Ошибки совместимости. Проблемы, когда программа не работает с определенной платформой, устройством или другим программным обеспечением.
• Ошибки производительности. Вызванные тем, что программа работает слишком медленно или использует слишком много памяти или дискового пространства.
• Ошибки безопасности. Проблемы, при которых программа уязвима для атаки или утечки конфиденциальных данных.
• Визуальные. Когда изображение вашего продукта выглядит иначе или имеет какие-то дефекты (например, плохое качество).

Тип бага – это полезная информация в баг-репорте. Проще разбираться в проблеме, если ты знаешь, о чем она.

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

Важность приоритета ошибок в том, что вы можете лучше управлять своими ресурсами и сосредоточиться на наиболее важных. Существует 3 уровня приоритета:

• Высокий означает, что вы должны исправить проблему немедленно, потому что она влияет на другие функции или делает их бесполезными для пользователей.
• Средний уровень означает, что вам следует исправить баг после критических ошибок (высокий уровень), потому что они также могут вызвать большие проблемы в будущих релизах, если их не исправить. 
• Ошибки низкого уровня – это те, которые не влияют на другие части вашего продукта, но могут беспокоить пользователей, поэтому их следует исправлять только в крайнем случае, когда у вас не осталось других задач!

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

Выделяют 5 уровней серьезности:

• Тривиальный: этот уровень бага не очень серьезен и может не влиять на функциональность системы или продукта.
• Незначительный: Ошибка может вызвать  неудобства для пользователя, но не снижает общую производительность системы.
• Серьезный: Баг существенно влияет на работу пользователей и может привести к проблемам с производительностью или потере данных.
• Критический: Проблема чрезвычайно серьезна и может стать причиной полного сбоя системы.
• Блокирующий: Настолько серьезный уровень, когда приложение/сайт не работает совсем

Жизненный цикл багов

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

1. Открыт. Первый шаг в жизненном цикле ошибки – ее идентификация и сообщение о дефекте. Обычно это делает пользователь ПО, который сообщает о проблеме через систему обратной связи или поддержки. 
2. Оценка. На этом этапе баг проверяется и приоритизируется в зависимости от серьезности и воздействия. Затем проблема анализируется, чтобы лучше понять проблему и наметить шаги к ее реализации.
3. Разработка исправления. Это включает в себя кодирование и тестирование, чтобы убедиться, что проблема решена.
4. Проверка и отклонение. Далее решение тестируется и проверяется, чтобы убедиться, что оно работает. Если исправление не решает проблему, оно отклоняется и отправляется обратно разработчику для дальнейшей работы.
5. Выпуск и устранение. После всех тестов, решение выпускается, и ошибка помечается как исправленная. В зависимости от системы пользователю может потребоваться установить исправление, или система автоматически обновится вместе с исправлением.
6. Закрытие. Последний шаг происходит после исправления ​​и подтверждения, что баг устранен. Это означает конец пути ошибки.