Нашёл ошибку на сайте или в приложении? Теперь нужно объяснить разработчику, что сломалось, при каких условиях и как повторить проблему. Для этого составляют баг-репорт. Разберём его структуру, покажем заполненный пример и расскажем, как оформлять ошибки, чтобы их было проще исправлять.
Что такое баг-репорт простыми словами
Баг-репорт (bug report) — это отчёт об ошибке в программе, на сайте или в приложении. В нём описывают, что работает неправильно, как воспроизвести проблему и какой результат должен быть вместо этого.
С английского bug переводится как «жук», но в IT этим словом называют ошибку или дефект программы. Report означает «отчёт» или «сообщение». Поэтому bug report можно перевести как «отчёт об ошибке».
Предположим, покупатель добавляет в корзину интернет-магазина два одинаковых товара по 1 200 рублей. Количество увеличивается до двух, но стоимость товаров остаётся 1 200 рублей вместо 2 400. Если по требованиям сумма должна пересчитываться автоматически, это ошибка.
Тестировщик фиксирует её в баг-репорте. Разработчик получает описание проблемы, повторяет действия и ищет причину неправильного расчёта.
Баг-репорты используют не только тестировщики. Ошибку может обнаружить разработчик, менеджер продукта или обычный пользователь. Но именно для тестировщика ПО умение правильно оформлять дефекты — один из базовых рабочих навыков.
Важный момент: не каждое неудобство или неожиданное поведение программы считается багом. Если непонятно, как должна работать функция, сначала стоит проверить требования. Возможно, она работает именно так, как было задумано.
Из чего состоит баг-репорт
Единой обязательной формы для всех компаний нет. В одном проекте тестировщик заполняет пять полей, в другом — десять. Состав зависит от продукта, процессов команды и программы, в которой ведут ошибки.
Однако основные элементы повторяются в большинстве шаблонов.
| Поле | Что нужно указать |
| ID | Уникальный номер ошибки. Обычно присваивается автоматически |
| Summary (заголовок) | Краткое описание проблемы |
| Preconditions (предусловия) | Что должно быть выполнено до проверки |
| Steps to Reproduce | Последовательность действий для воспроизведения |
| Expected Result | Как программа должна работать |
| Actual Result | Что произошло на самом деле |
| Environment (окружение) | Версия приложения, браузер, ОС, устройство, тестовый стенд |
| Severity (серьёзность) | Насколько сильно ошибка влияет на работу программы |
| Priority (приоритет) | Насколько срочно её нужно исправить |
| Attachments (вложения) | Скриншоты, видео, сообщения об ошибках, логи |
Также могут указывать статус задачи, частоту возникновения ошибки, ссылку на требование или тест-кейс.
Самые важные части баг-репорта — шаги воспроизведения, ожидаемый и фактический результаты. По ним разработчик должен понять, что проверить и какое поведение нужно восстановить.
Пример баг-репорта в тестировании
Возьмём учебный пример с интернет-магазином. У нас есть товар стоимостью 1 200 рублей, скидок нет. По условиям задачи стоимость товаров в корзине должна автоматически пересчитываться при изменении количества.
Допустим, количество изменилось, а сумма осталась прежней. Посмотрим, как оформить такую проблему.
Заголовок: [Корзина] Стоимость товара не меняется при увеличении количества с 1 до 2.
Предусловия: в корзину добавлен один товар стоимостью 1 200 рублей. Скидки не применяются.
Шаги воспроизведения:
- Открыть корзину интернет-магазина.
- Убедиться, что количество товара равно 1, а его стоимость — 1 200 рублей.
- Изменить количество товара с 1 на 2.
- Проверить стоимость товаров в корзине.
Ожидаемый результат: стоимость товаров автоматически меняется с 1 200 на 2 400 рублей.
Фактический результат: количество товара изменилось на 2, но стоимость осталась 1 200 рублей.
Окружение: веб-версия магазина, десктоп. В реальном отчёте дополнительно указывают адрес тестового стенда, версию браузера и операционную систему.
Серьёзность: предположительно Major, поскольку ошибка затрагивает расчёт стоимости товаров. Окончательная оценка зависит от принятой в команде шкалы.
Приоритет: определяется командой с учётом влияния ошибки на оформление заказов и сроков релиза.
Вложения: скриншот или запись экрана, на которой видно количество товара и неправильную сумму.
Как это может выглядеть:
Обрати внимание на описание фактического результата. Мы не утверждаем, что покупатель действительно заплатит неправильную сумму. Для такого вывода нужно отдельно проверить оформление заказа и обработку платежа. Пока известно только то, что неверно отображается стоимость товаров в корзине.
Хороший баг-репорт фиксирует наблюдаемые факты. Предположения о причине ошибки можно добавить отдельно, если для них есть основания.
Как правильно написать баг-репорт
Допустим, ты впервые тестируешь сайт и обнаружил проблему. Не спеши сразу создавать задачу. Сначала собери информацию, которая поможет другим участникам команды.
Проверь, действительно ли это ошибка
Сравни поведение программы с требованиями. Например, если поле «Телефон» принимает только российские номера, номер другой страны может отклоняться совершенно правильно.
Когда требования неочевидны, уточни их у аналитика или ответственного за продукт. Так ты избежишь ситуации, когда разработчику отправляют ошибку, которой на самом деле нет.
Затем попробуй повторить проблему. Проверь, возникает ли она при тех же действиях и условиях.
Перед созданием отчёта также поищи похожую задачу в системе отслеживания ошибок. Если баг уже зарегистрирован, полезнее добавить новую информацию к существующему отчёту, чем создавать дубль.
Придумай понятный заголовок
По заголовку должно быть ясно, где произошла ошибка и что именно не работает.
Плохой вариант:
«Корзина сломалась»
Из такого описания невозможно понять, что произошло: товар исчез, не добавился, изменилось количество или неправильно рассчиталась сумма.
Хороший вариант:
«[Корзина] Стоимость товара не меняется после увеличения количества»
Здесь сразу понятны раздел сайта, проблема и действие, которое её вызывает.
Необязательно делать заголовок длинным. Главное, чтобы он помогал отличить одну ошибку от другой.
Запиши шаги воспроизведения
Это инструкция для человека, который будет проверять баг. Начни с исходного состояния и перечисли действия в правильном порядке.
Вместо «Попробовать поменять количество товара» лучше написать «В корзине изменить количество товара с 1 на 2».
Если проблема возникает только у авторизованного пользователя, укажи это в предусловиях. Если нужна определённая роль, настройка, промокод или тестовый аккаунт, эту информацию тоже нужно добавить.
Не пропускай действия, без которых проблема не возникает. При этом не расписывай очевидные операции, которые не влияют на результат.
Раздели ожидаемый и фактический результаты
Ожидаемый результат описывает правильную работу функции. Фактический — то, что ты увидел при проверке.
Например:
- Ожидаемый: после отправки формы появляется сообщение «Заявка отправлена».
- Фактический: после нажатия кнопки форма остаётся открытой, сообщение не появляется.
Но отсутствие сообщения ещё не доказывает, что заявка не дошла до сервера. Возможно, данные отправились, а проблема возникла при отображении подтверждения.
Если ты не проверял серверный ответ или сохранение заявки, не делай выводов за пределами увиденного.
Добавь окружение и доказательства
Часть ошибок появляется только при определённых условиях. Например, в одном браузере форма работает, а в другом не отправляется.
Поэтому указывай данные, которые могут повлиять на воспроизведение:
- версию браузера и операционной системы;
- модель устройства, если проверяешь мобильное приложение;
- версию приложения и адрес тестового стенда;
- тестовые данные и настройки, от которых зависит ошибка;
- частоту возникновения проблемы, если уже проверял повторяемость.
К отчёту можно приложить скриншот, короткую запись экрана или текст сообщения об ошибке.
Если проблема связана с запросом к серверу, пригодятся сведения из вкладки Network в инструментах разработчика браузера: адрес запроса, HTTP-статус и ответ. Но добавляй их по делу. Для простой опечатки на кнопке технические логи обычно не нужны.
Перед отправкой скриншотов и логов проверь, нет ли в них паролей, токенов, персональных данных или другой закрытой информации.
Курс «Тестировщик ПО (QA-инженер)» в Академии IT DMS
Сертификат или удостоверение о повышении квалификации.
AFFTIMES−5 % на первую покупку. Скидка суммируется с любыми акциями школы. Если оплачиваете через менеджера в чате, назовите ему промокод.
Как выглядит плохой баг-репорт
Сравним два описания одной проблемы.
| Некачественный баг-репорт | Нормальный баг-репорт |
| «Не работает корзина» | «[Корзина] Стоимость товаров не пересчитывается после изменения количества с 1 на 2» |
| «Захожу на сайт, что-то меняю» | Указаны исходное количество, цена товара и последовательность действий |
| «Неправильная цена» | Ожидается 2 400 ₽, отображается 1 200 ₽ |
| Нет сведений об окружении | Указаны стенд, браузер и версия приложения |
| «Срочно исправьте!» | Описано влияние на функцию, приоритет обсуждает команда |
Проблема плохого отчёта в том, что разработчику приходится самостоятельно выяснять исходные условия, искать нужный экран и угадывать, какое поведение считается правильным.
Перед отправкой своего баг-репорта попробуй мысленно выполнить по нему проверку с нуля. Если для этого не хватает информации, дополни описание.
Серьёзность и приоритет бага: в чём разница
Серьёзность (Severity) показывает, насколько сильно ошибка нарушает работу программы.
Приоритет (Priority) определяет, насколько важно исправить её по сравнению с другими задачами.
Например, опечатка в заголовке главной страницы не мешает сайту работать. Её серьёзность низкая. Но если завтра начинается крупная рекламная кампания, исправление может получить высокий приоритет.
А ошибка в редко используемой функции внутреннего инструмента может сильно нарушать её работу, но иметь более низкий приоритет, если этой функцией временно никто не пользуется и есть другие срочные задачи.
Какие бывают степени серьёзности бага
В командах встречаются разные шкалы. Один из распространённых вариантов выглядит так:
| Уровень | Что означает | Пример |
| Blocker | Блокирует дальнейшую работу или тестирование | Приложение не запускается, продолжить проверку невозможно |
| Critical | Критически нарушает работу системы | Операция приводит к потере важных данных |
| Major | Существенно нарушает отдельную функцию | Не удаётся завершить оформление заказа |
| Minor | Ошибка затрагивает второстепенную функцию | Некорректно работает необязательная настройка |
| Trivial | Незначительный дефект | Опечатка в малозаметной подсказке |
Названия и границы категорий не универсальны. Некоторые команды используют всего три уровня, другие объединяют Blocker и Critical.
Для приоритетов тоже бывают разные обозначения: High, Medium, Low или P1, P2, P3. Причём номер P1 не всегда соответствует определённой серьёзности — значение зависит от правил проекта.
Тестировщик обычно описывает влияние проблемы и может предложить оценку серьёзности. А приоритет исправления согласуют с учётом пользователей, бизнес-рисков, сроков и других задач команды.
Жизненный цикл бага в тестировании
После создания баг-репорта работа с ошибкой продолжается. Задача проходит несколько этапов — от регистрации до проверки исправления.
Рассмотрим типичный процесс:
- New — тестировщик создал баг-репорт.
- Active / In Progress — команда приняла задачу в работу, разработчик исследует проблему и исправляет её.
- Resolved / Fixed — исправление выполнено, задача ожидает проверки или дальнейшей обработки.
- Retest — тестировщик повторяет исходные действия и смотрит, устранена ли ошибка.
- Closed — исправление подтверждено, задача закрыта.
Если ошибка сохранилась, баг-репорт могут вернуть в работу — это называют Reopened.
Не все ошибки проходят полный путь. Задачу могут закрыть как дубликат, отклонить, если поведение соответствует требованиям, или отложить на другой релиз.
Названия статусов и разрешённые переходы зависят от системы и процесса команды. Например, в Azure DevOps с процессом Agile используются статусы New, Active, Resolved и Closed. При этом повторное тестирование — действие специалиста, а не обязательно отдельный статус.
После исправления полезно проверить не только исходную проблему, но и соседние сценарии. Если разработчик изменил расчёт стоимости в корзине, стоит убедиться, что сумма правильно считается и для одного товара, и для нескольких, а скидки продолжают работать.
Чем баг-репорт отличается от тест-кейса и чек-листа
Все три инструмента используют в тестировании ПО, но для разных задач.
| Инструмент | Для чего нужен | Пример |
| Чек-лист | Перечислить, что нужно проверить | «Проверить изменение количества товара в корзине» |
| Тест-кейс | Описать конкретную проверку с условиями и ожидаемым результатом | «Увеличить количество с 1 до 2 и проверить пересчёт стоимости» |
| Баг-репорт | Зафиксировать обнаруженное отклонение | «Количество увеличилось до 2, но стоимость не изменилась» |
Сначала тестировщик может составить чек-лист или тест-кейсы. Затем выполнить проверки и, если обнаружится ошибка, оформить баг-репорт.
Но баг-репорт необязательно появляется после выполнения готового тест-кейса. При исследовательском тестировании специалист изучает продукт без заранее расписанных подробных сценариев и тоже может находить дефекты.
В каких программах составляют баг-репорты
Для учебной практики достаточно таблицы Excel или Google Sheets. Но в командах разработки обычно используют системы отслеживания задач и ошибок — баг-трекеры.
Среди популярных инструментов:
Jira. Позволяет создавать задачи типа Bug, описывать шаги воспроизведения, назначать исполнителей, добавлять вложения и отслеживать статусы.
YouTrack. Система JetBrains для управления задачами и ошибками. В ней можно заполнять описание, указывать тип и приоритет задачи, прикладывать файлы и связывать проблемы между собой.
GitLab Issues. Инструмент для задач внутри GitLab. Можно использовать готовые шаблоны, добавлять метки, комментарии и материалы для воспроизведения ошибки.
Принципы оформления баг-репорта одинаковы: нужно объяснить проблему, показать условия её возникновения и зафиксировать разницу между ожидаемым и фактическим поведением.
Шаблон баг-репорта в Excel
Для тренировки можно использовать готовую таблицу. Мы подготовили шаблон с двумя вкладками: заполненный пример и пустая форма.
В таблице есть поля для заголовка, предусловий, шагов, результатов, окружения, серьёзности, приоритета и вложений. Рядом с каждым полем — подсказка.
Попробуй заполнить шаблон на учебном сайте, где разрешено проводить проверки. Если найдёшь ошибку, сначала повтори её, а затем составь отчёт. Если дефектов не обнаружилось, не придумывай их: можно потренироваться на условном примере, отдельно обозначив его как учебный.
На первом этапе важнее научиться понятно описывать поведение программы, чем запоминать расположение кнопок в конкретном баг-трекере.
Что делать, если баг не воспроизводится
Иногда ошибка появляется один раз и исчезает. Например, форма заявки не отправилась, но при повторной попытке всё сработало.
Не стоит сразу считать проблему исправленной. Попробуй выяснить, при каких обстоятельствах она возникла.
Проверь, изменились ли данные, авторизация, состояние страницы или подключение к сети. Если ошибку заметили только на конкретном устройстве, полезно повторить проверку на нём.
Запиши точное время возникновения, доступные сообщения об ошибке и действия пользователя. Если есть логи или сведения о запросах, добавь их в отчёт.
Когда повторить проблему не удалось, так и напиши. Например: «Ошибка возникла один раз при отправке формы, при четырёх последующих попытках не воспроизвелась». Такой результат можно указывать только после соответствующей проверки.
Решение о дальнейшей работе с подобной ошибкой зависит от её последствий. Пропавшая подсказка и возможная потеря оплаченного заказа требуют разного внимания даже при одинаковой частоте возникновения.
Как проверить готовый баг-репорт
Перед отправкой убедись, что другой человек сможет разобраться в проблеме без дополнительных вопросов.
Проверь, указано ли место возникновения ошибки, понятны ли начальные условия, достаточно ли подробны шаги и можно ли по ним получить описанный результат.
Особенно внимательно посмотри на ожидаемый результат. Он должен опираться на требования или согласованные правила работы функции. Иначе получится спор о том, как программа могла бы работать, вместо описания реального дефекта.
Умение оформлять баг-репорты пригодится уже на первых учебных проектах и при подготовке к собеседованию на Junior QA. А если хочешь разобраться, какие ещё навыки нужны для старта, почитай наш материал о том, как стать тестировщиком с нуля.
FAQ
Bug report — это отчёт об ошибке в программном обеспечении. Он содержит описание проблемы, условия возникновения, шаги воспроизведения и сравнение ожидаемого результата с фактическим.
Обычно указывают заголовок, шаги воспроизведения, ожидаемый и фактический результаты, окружение. Остальные обязательные поля зависят от требований проекта.
Да. Для учебных задач достаточно таблицы Excel с основными полями. В командах разработки чаще используют Jira, YouTrack, GitLab Issues и другие баг-трекеры.
Тест-кейс описывает, что и как нужно проверить. Баг-репорт фиксирует найденную ошибку и помогает команде её воспроизвести.
Severity показывает влияние ошибки на работу системы, а Priority — важность её исправления. Оба показателя используются при планировании работы.
Нужно записать условия возникновения, время, доступные сообщения и количество попыток повторения. Отсутствие повторения не доказывает, что ошибка устранена.
