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

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

Эксперт

Фёдор Зволинский

Инженер в крупной российской компании, эксперт по QA в Skillbox.

Содержание

• Что такое баг и баг-репорт
• Какие дефекты в ПО бывают
• Как оценить серьёзность бага и приоритет исправления
• Какой у него жизненный цикл
• Как правильно оформить баг-репорт
• Как он выглядит в жизни
• Какие правила составления баг-репорта стоит запомнить

Что такое баг и баг-репорт

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

Поэтому можно сформулировать второе определение: баг — это несоответствие разработанного ПО требованиям к нему.

Ищут баги тестировщики и QA-инженеры. Делают они это не только после релиза программы, когда уже есть активные пользователи, а на всех этапах её разработки.

Читайте также:

Что такое альфа- и бета‑версии?

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

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

Виды багов

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

Функциональные дефекты

Возникают тогда, когда приложение или сайт не выполняют своих задач. Например, при нажатии кнопки Сохранить текст в онлайн-редакторе текст не сохраняется.

Разновидность функциональных дефектов — логические. Это баги, которые приводят к неправильной работе программы с точки зрения логики: в графе Месяц при указании даты рождения можно выбрать число больше 12 или в форме регистрации на сайте написать почтовый ящик без @.

Нефункциональные дефекты

Это баги, которые напрямую не связаны с функциональностью ПО, но влияют на его работоспособность или удобство для пользователя.

UI-баги. Элементы в приложении отрисованы неправильно: размер и цвет кнопки в интерфейсе отличается от макета, изображения с искажёнными пропорциями и так далее.

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

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

Дефекты переносимости и кросс-платформенности. Программы и приложения должны стабильно работать на разных операционных системах, браузерах и так далее.

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

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

Исторически для дефектов указывали две характеристики — серьёзность и приоритетность. Каждая из них определяла важность конкретного бага. Сейчас параметры объединили в один — приоритетность (priority). Но полезно знать их оба, так как они встречаются в технической литературе.

Уровни серьёзности багов

Тривиальный уровень (trivial). Такие ошибки не влияют на работу программы или приложения. Например, это опечатки в тексте на странице сайта или не центральное расположение надписи на кнопке.

Незначительный уровень (minor). Баги, которые пользователь не замечает, так как они не влияют на функциональность: неудачно расположенная кнопка, затрудняющая навигацию, и так далее.

Серьёзный уровень (major). Пользователь видит дефект, но он не мешает ему работать с приложением или программой. Например, он не может перейти на какую-либо страницу сайта из основного меню, но она открывается с другой страницы.

Критический уровень (critical). Ограничена работа важной части программы, но пользоваться ПО можно: нельзя выбрать дату рождения при регистрации и пользователь регистрируется со значением формы по умолчанию или не применяется промокод на скидку в онлайн-магазине, но товар можно купить по обычной цене.

Блокирующий уровень (blocker). ПО не работает. Например, сайт выдаёт ошибку 404 или приложение не открывается.

Приоритетность багов

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

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

Средний уровень приоритетности. Баг следует поставить в план работы, но спешка не требуется.

Высокий уровень приоритетности. Необходимо немедленно исправить дефект, так как приложение или программа не работают.

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

Команды тестирования и разработки документируют работу над багами. Для этого используют системы управления проектами, в которых удобно заводить и вести баг-репорты: «Яндекс Трекер», YouTrack, Trac или Jira.

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

Открыт. Тестировщик обнаружил баг и внёс его в систему в соответствии с принятым шаблоном оформления.

В работе. Исполнитель получил отчёт о дефекте и принял в работу.

Исправлен. Разработчик отметил, что провёл работу по исправлению бага и продукт может быть отправлен на проверочное тестирование.

Закрыт. Повторное тестирование подтвердило исправление бага. Тикет с ним закрывается. Если проблема сохраняется, то задача переоткрывается и возвращается исполнителю.

Кроме статуса для бага может быть указан ответ разработчика (resolution). Например, Перенесён (Later), то есть отложен на более поздний срок из-за изменения приоритетности, Отклонён (Incorrect / Cannot reproduce), если баг-репорт оформлен неправильно, например не указаны шаги к воспроизведению ошибки и другие, принятые в команде.

Структура оформления баг-репорта

В каждой компании существует своя структура оформления баг-репортов. Но в большинстве шаблонов есть общие пункты:

Баг-репорт оформляет тестировщик или QA-инженер. Если разработчик самостоятельно выявляет баг, то сам заполняет его или передаёт в отдел тестирования для воспроизведения дефекта и подробного описания.

Пример баг-репорта

Посмотрим, как баг-репорт выглядит в реальности. За основу возьмём наш шаблон:

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

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

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

Но такая практика приводит к сохранению уже существующих багов и низкой эффективности их закрытия. Поэтому тестировщики и QA-инженеры должны придерживаться строгих правил оформления баг-репорта.

Максимально подробно описывать дефект. Никогда не описывайте баг одним предложением. Представьте, что работать с ним будет разработчик, который до этого не открывал программу или приложение. Поэтому чётко и ясно описывайте проблему и указывайте на последовательность действий, приводящих к появлению дефекта.

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

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

Прикладывайте дополнительные материалы. Для багов, которые видны сразу, без воспроизведения определённых действий, — скриншоты, для багов, которые появляются в процессе работы, — скринкасты, а для багов API — логи и так далее. Разработчик проанализирует их и сможет быстрее понять, в чём состоит дефект работы ПО.