Баг-репорт: полное руководство с примерами

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

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

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

Официальное определение баг-репорта в справочнике ISTQB (международного совета по QA) звучит так:

A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function.

Документ, сообщающий о любом изъяне в компоненте или системе, который может привести к их неспособности выполнять требуемые функции. 

Почему баг-репорты так важны? Они:

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

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

Основные виды багов

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

Функциональные баги

Ошибки, найденные при функциональном тестировании, обычно связаны с основной работой приложения. Например, кнопка не выполняет свою функцию, а приложение завершает работу при определенном действии. Либо вы заполняете поля формы, нажимаете «Отправить», но данные не уходят на сервер. 

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

Нефункциональные баги

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

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

Баги совместимости

Эти ошибки появляются, когда приложение работает по-разному в разных средах. Например, сайт корректно отображается в Chrome, но некорректно работает в Firefox: появляются дефекты в верстке или функционале.

Как составить баг-репорт: пошаговое руководство

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

На курсе «‎Основы тестирования» вы научитесь составлять баг-репорты на профессиональном уровне, чтобы говорить на языке, понятном всей команде.

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

Четкая и логичная структура позволяет разработчикам не тратить время на уточнения и сразу перейти к устранению проблемы. А для тестировщика это способ доказать свою внимательность и профессионализм.

Headline (Заголовок)

Заголовок — это первое, что видят разработчики. Его задача — сразу дать понять суть проблемы и помочь оценить ее важность. Хороший заголовок должен быть и информативным. Например: «Ошибка сохранения настроек при отключении интернета».

И конечно, он не должен содержать эмоциональных оценок или догадок. Например, не «Форма сломана», а «Форма не отправляет данные при нажатии кнопки “Отправить”».

Severity (Критичность)

Укажите, насколько ошибка влияет на работу продукта. Обычно используют следующие общепринятые стадии критичности.

• Critical: блокирует ключевые функции, например, не работает кнопка «Оплатить».
• Major: серьезно влияет на работу бизнес-модели приложения, но не блокирует ее, например, некорректно считается сумма заказа в корзине.
• Average: ошибки средней важности. Они не мешают основным задачам, но заметны в интерфейсе и не только.
• Minor: это незначительные дефекты, так сказать, косметические ошибки (опечатки, дефекты верстки).
• Enhancement: это скорее запросы на улучшение, а не баги. Например, тестировщик может порекомендовать добавить подсказки или изменить анимацию.

Определить критичность важно, чтобы QA-команда и разработчики могли правильно расставить приоритеты в работе над ошибками.

Следом иногда указывают приоритетность (Priority) найденного дефекта. Этот атрибут показывает, насколько срочно нужно исправить дефект.

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

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

Description (Описание)

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

Result (Фактический результат)

Здесь указывайте, что произошло в реальности. Например: «После нажатия кнопки “Сохранить” ничего не происходит, данные не сохраняются».

Expected Result (Ожидаемый результат)

Укажите, как приложение должно было себя вести. Например: «После нажатия кнопки “Сохранить” данные должны передаваться на сервер, а пользователь — увидеть сообщение “Настройки сохранены”».

Attachments (Приложения)

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

Советы по созданию качественного баг-репорта

• Будьте конкретными. Не пишите обобщения, например: «Сайт работает плохо». Опишите конкретную проблему.
• Используйте структурированный формат. Разделите баг-репорт на логические части, чтобы его было легче читать.
• Пишите по делу. Избегайте лишних деталей, которые не помогают понять суть ошибки.

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

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

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

Бывают примеры, когда баг репорт делают в Excel. Но на самом деле это редкая практика: совместно работать с таким отчетом очень неудобно.

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

Как мы говорили выше, для баг-репорта в Jira есть стандартный шаблон, который включает все ключевые элементы для описания дефекта. Это помогает структурировать информацию и четко описать проблему по понятной и привычной всем схеме.

Заполнение баг-репорта на примере

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

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

Часто встречающиеся ошибки при составлении баг-репортов

Из-за следующих ошибок разработчики могут отправить баг-репорт на уточнение.

• Нечеткое описание. Например: «Не работает форма регистрации». Такое сообщение не дает разработчику никаких подсказок.
• Нет описания шагов воспроизведения. Если разработчик не сможет повторить действия, он не поймет, что именно идет не так.
• Не указано окружение. Указывайте устройства, браузеры и ОС, в которых обнаружены дефекты.
• Несколько багов в одном репорте. Это путает разработчиков. Поэтому один баг=один отчет.

Рекомендации по использованию баг-репортов

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

Как отслеживать статус багов в Jira

У баг-репорта в Джире есть несколько стандартных статусов.

• Open: дефект зарегистрирован, но работа над ним еще не началась.
• In Progress: разработчик приступил к устранению ошибки.
• Resolved: проблема решена, но еще требует проверки со стороны тестировщика.
• Closed: дефект устранен и подтвержден тестировщиком.
• Postponed: устранение бага отложено.
• To Be Reformulated: баг-репорт нужно уточнить или переформулировать.

Каждый баг, помимо статуса, будет иметь свою резолюцию (результат).

• Fixed: проблема исправлена.
• Fixed indirectly: баг исправился сам после внесения других изменений.
• Functions As Designed (FAD): описанное поведение не является багом, оно соответствует требованиям.
• Won’t Fix: проблему невозможно исправить.
• Duplicate: такой баг уже зарегистрирован в системе.
• Incomplete: недостаточно данных для работы с дефектом.
• Cannot Reproduce: ошибка не воспроизводится, поэтому ее нельзя исправить.

Улучшение коммуникации между тестировщиками и разработчиками

Составляйте баг-репорты так, чтобы разработчики сразу понимали проблему. Ведь вы — одна команда.

• Указывайте точные шаги для воспроизведения, а лучше записывайте видео.
• Используйте факты, избегайте эмоций и расплывчатых формулировок. Например, вместо «Кнопка вообще не работает» напишите «Кнопка “Отправить” не реагирует на нажатие в браузере Chrome».
• Используйте понятные названия элементов интерфейса: «кнопка “Войти”» вместо «большая синяя кнопка».

FAQ: Ответы на популярные вопросы о баг-репортах

Что делать, если баг нельзя воспроизвести?

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

Как описывать сложные баги?

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

Записаться на бесплатную консультацию