Баг-репорт (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) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.
Как правильно писать баг-репорт
Баг-репорт относится к технической документации, поэтому он не должен содержать лишних оборотов — только факты, изложенные простым языком.
На что стоит обратить внимание при описании дефекта?
Выявить причину возникновения. Например, если на сайте не получается восстановить пароль, то проблема может быть как в бэкенде, так и во фронтенде. Задача тестировщика — разобраться в ней, так как от этого зависит, кому из разработчиков отдавать баг на исправление.
Провести проверку на разных устройствах. Если проблема есть в десктоп-версии, то она может возникнуть и на мобильных устройствах, поэтому стоит проверить.
Провести проверку в разных версиях ПО. Баг может не воспроизводиться в старой версии ПО, но появится в новой.
Описать несоответствие ожидаемому результату. Чтобы сопоставить то, как работает программа сейчас, с ожидаемым результатом, начинающим специалистам лучше свериться с технической документацией и техническим заданием, где подробно описано, как все работает в идеале.
0 комментариев