Баг-репорт

Баг-репорт (bug report) — это технический документ, который подробно описывает ошибку в работе программы, приложения или другого ПО. Его составляет тестировщик, чтобы разработчикам было понятно, что работает неправильно, насколько дефект критичен и что нужно исправить.

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

Виды багов

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

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

• Логические. Баг, при котором что-то работает неправильно с точки зрения логики, — например, когда можно указать несуществующую дату (31 февраля) или поставить дату рождения из будущего (2077 год).

• Дефекты UX. Приложение или программа неудобны в использовании: при просмотре ленты новостей пользователя постоянно отбрасывает к началу, слишком близко расположены кнопки и вместо одной нажимается другая.

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

Структура баг-репорта

Поля варьируются в зависимости от правил конкретной компании, но чаще всего каждый документ содержит следующие пункты:

ID	Идентификационный номер, который присваивается конкретному багу
Краткое описание (также может называться Title или Summary)	Раздел, который кратко передает суть бага одним предложением. Отвечает на вопросы «Что?», «Где?», «При каких обстоятельствах?» Неправильно: «Проблемы с кнопкой» Правильно: «При нажатии на кнопку “Зарегистрироваться” на главной странице не открывается форма регистрации»
Проект	Название проекта, программы или приложения, в котором выявлен баг
Версия	Точная версия ПО, содержащая баг. Например, последняя версия iOS (операционной системы iPhone) — V 14.7.1
Серьезность бага	Параметр, который определяет влияние бага на работу программы по шкале от S0 до S4
Приоритет	Параметр, который определяет срочность исправления бага по шкале от P1 до PЗ
Статус	Определяется в зависимости от того, на какой стадии находится баг: открыт, в работе, исправлен, отклонен, отсрочен и т.д.
Автор	Создатель баг-репорта
Исполнитель	Разработчик, который будет устранять баг
Шаги к воспроизведению	Точная последовательность действий, которая приводит к тому, чтобы воспроизвести баг
Фактический результат	К чему приводит воспроизведение шагов, как сейчас работает программа
Ожидаемый результат	Как должна работать программа на самом деле и к чему должны приводить действия, описанные в пункте «Шаги к воспроизведению»
Дополнения	Ссылки, скриншоты, видео и другие материалы, которые помогут исполнителю лучше понять суть проблемы

Заголовок: При скролле исчезают станции в маршрутном листе

Описание: Если построить длинный маршрут, некоторые названия станций исчезают при скролле.

В заголовке не хватает деталей: например, что маршрут должен быть длинным. Поэтому можно добавить описание.

Серьезность и приоритет багов

Серьезность — это показатель влияния бага на работу программы, того, может ли она функционировать без исправления или баг ломает всю систему. Выделяют пять уровней серьезности багов:

• S0 Trivial (Тривиальный) — баг не влияет на работу программы, поэтому для его исправления могут не выделить отдельную задачу, а исправить попутно при исправлении других, похожих ошибок. Например, при заполнении анкеты в поле «Дата рождения» по умолчанию отображается не актуальный год, а 1999-й.

• S1 Minor (Незначительный) — баг почти не нарушает логику процессов, поэтому с ним программа может нормально работать. Например, неудобная навигация в интерфейсе.

• S2 Major (Серьезный) — баг создает неудобства в использовании, но еще не нарушает функционал программы.

• S3 Critical (Критический) — баг мешает приложению выполнять основные функции: калькулятор расходов неправильно считает бюджет или в текстовом редакторе невозможно вводить текст.

• S4 Blocker (Блокирующий) — ситуация, когда программа не работает в принципе: сайт выдает «ошибку 404» или не запускается приложение.

Приоритет — это срочность выполнения задачи. Всего выделяется три уровня приоритетов:

• P1 Высокий — исправляется в первую очередь, так как баг ломает работу приложения.

• P2 Средний — обязательный к исправлению баг после критического.

• P3 Низкий — не требует немедленного решения.

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

Статус бага в репорте определяется его «жизненным циклом», который состоит из четырех основных стадий:

• Открыт (Open) — тестировщик выявил баг и добавил в репорт.

• В работе (In Progress) — о баге сообщили исполнителю, и он занимается исправлением.

• Исправлен (Ready for check) — исполнитель закончил работу по исправлению бага и передал проект на повторную проверку тестировщику.

• Закрыт (Closed) — баг устранен и больше не воспроизводится.

Кроме основных есть еще несколько статусов:

• Отклонен (Rejected) — исправлению бага помешала ошибка в репорте, например неверный алгоритм в пункте «Шаги к воспроизведению».

• Отсрочен (Deferred) — баг признан неприоритетным и исправление переносится.

• Переоткрыт (Reopened) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

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

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

На что стоит обратить внимание при описании дефекта?

Выявить причину возникновения. Например, если на сайте не получается восстановить пароль, то проблема может быть как в бэкенде, так и во фронтенде. Задача тестировщика — разобраться в ней, так как от этого зависит, кому из разработчиков отдавать баг на исправление.

Провести проверку на разных устройствах. Если проблема есть в десктоп-версии, то она может возникнуть и на мобильных устройствах, поэтому стоит проверить.

Провести проверку в разных версиях ПО. Баг может не воспроизводиться в старой версии ПО, но появится в новой.

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