Баг-репорт: что это и как описать ошибку без лишней боли

Ситуация: вы начали свой путь в тестировании, устроились в компанию и сели за работу. И вот ваш первый баг — в интернет-магазине не работает кнопка «оплатить заказ». Вы скорее бежите в чат: «Кнопка не алё, исправьте!» 

Но никто не спешит решать проблему. Потом вообще выясняется, что ваше сообщение потерялось. А всё потому что надо было написать баг-репорт — да, потратить немного времени, но превратить находку в нормальный тикет для разраба. 

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

Содержание

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

Структура баг-репорта: какие поля нужны

Баг-репорт: шаблон и пример для новичка

Серьёзность и приоритет в тестировании: в чём разница

Жизненный цикл бага в тестировании

Как писать баг-репорты, чтобы их не возвращали на уточнение

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

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

Такой отчёт превращает жалобу в конкретную задачу. А чем точнее диагноз, тем проще назначить правильное лечение.

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

• Баг — ошибка в коде, из-за которой кнопка или функция работает не так, как должна. 
• Дефект — любое несоответствие правилам: от сломанного кода до кривой картинки или опечатки в тексте.
• Сбой — разовый глюк системы, который часто происходит из-за внешних причин. Например, если вырубили инет. 
• Тикет —  любая карточка с задачей в рабочей программе. Это может быть и починка бага, и создание новой функции.

Ещё сразу исправим возможную ошибку. На английском баг-репорт пишется вот так: bug report. А не bag report. 

Зачем нужен баг-репорт, если можно написать в чат

Рабочий чатик — это окей, чтобы спросить совет, но для серьёзных задач он не подойдёт. Фразу «у меня не открывается форма» без контекста разраб вряд ли поймёт. 

Отчёт об ошибке устроен понятнее. Он сразу даёт разработчику нужную инфу:

• Пошаговый алгоритм — куда жмать, чтобы увидеть проблему.
• Окружение — на каком устройстве и в каком браузере всё сломалось. 
• Вложения — скриншоты или видео, где видна ошибка.
• Статус и история — кто щас чинит задачу и на каком она этапе.

Когда вы создаёте тикет через баг-трекинг, задача получает номер и ответственного человека. Она точно не потеряется и вам будет с кого спросить о сроках. 

Структура баг-репорта: какие поля нужны

В разных IT-командах шаблоны отличаются, поэтому не все bug report выглядят одинаково. Но есть стандартная структура — её поймёт разраб в любой компании. 

Пример классического шаблона баг-репорта

Заголовок — кратко объясняет суть проблемы. 

❌ Не работает корзина.
✅ На странице корзины кнопка «Оформить заказ» остаётся серой после выбора способа доставки.

Предусловия — описывает, как подготовиться к тесту.

❌ Надо зайти на сайт.
✅ Пользователь авторизован в системе. В корзину добавлен один товар.

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

❌ Нажмите туда, потом сюда и проверьте.
✅  1. Перейти в корзину. 2. Выбрать способ доставки «Курьер».

Фактический результат — что сломалось и как система ведёт себя?

❌ Всё зависло и сломалось.
✅ Кнопка «Оформить заказ» заблокирована, кликнуть на неё нельзя.

Ожидаемый результат — как программа должна работать по требованиям? 

❌ Чтобы всё работало нормально.
✅ Кнопка «Оформить заказ» становится активной — зелёной.

Окружение — среда, где тестировали: ОС, браузер, модель устройства.

❌ С компа.
✅ Windows 11, Google Chrome v120.0, тестовый стенд Staging-2.

Версия — номер сборки или релиза приложения, где нашли дефект. 

❌ Последняя версия.
✅  v3.4.2-build18.

Серьёзность — техническое влияние бага на работу программы.

❌ Полный треш.
✅ Высокая — функция не работает, но есть обходной путь. 

Приоритет — как быстро надо починить.

❌ Прям щас сделайте.
✅ High — нужно исправить в текущем спринте.

Вложения — наглядные доказательства дефекта.

❌ Нет файлов.
✅ [Скриншот заблокированной кнопки]

Как написать заголовок, чтобы разработчик понял суть

По заголовкам разработчик сортирует bug report. И если он не поймёт, что вы хотели сказать, то проигнорит задачу. Ну или возьмёт её и будет делать очень долго. 

Классическая формула заголовка:

Стрём: проблема с кнопкой. 

С какой? Где? Что с ней не так? Непонятно.

Норм: на странице оплаты кнопка «Оплатить» неактивна после выбора карты.

Разработчик сразу видит локацию, триггер и саму ошибку.

Что писать в шагах воспроизведения

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

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

Баг-репорт: шаблон и пример для новичка

Сделали универсальный шаблон баг-репорта в формате Markdown, который вы можете адаптировать под любую систему — Jira, YouTrack, GitHub Issues или Яндекс Трекер. Ctrl C, Ctrl V — и вы красавчик.

И ловите пример — написали за секунду по нашему гениальному шаблону.

Что приложить к баг-репорту

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

Какое вложение выбрать — зависит от ситуации:

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

Серьёзность и приоритет в тестировании: в чём разница

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

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

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

Кто ставит серьёзность и приоритет

Чёткого распределения ролей, как в пьесе, во многих проектах нет. Логика зависит от культуры компании и методологии разработки. 

Но часто роли делятся так:

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

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

А вот новые скиллы точно не подождут до завтра — погнали учиться уже сегодня. Как раз припасли для вас промокод со скидкой на любую профессию в Яндекс Практикуме.

Жизненный цикл бага в тестировании

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

Стандартный цикл состоит из пяти стадий:

1. Новый — тестировщик обнаружил ошибку, оформил баг-репорт и сохранил его в системе.
2. Назначен — менеджер или тимлид проверили баг и передали его конкретному разработчику для починки.
3. Исправлен — программист изменил код, устранил проблему и отправил задачу обратно в отдел тестирования.
4. Проверка — QA-инженер заново проходит шаги воспроизведения на свежей сборке приложения, чтобы убедиться, что дефект исчез.
5. Закрыт  — если ретест прошёл успешно и ошибка больше не появляется, баг окончательно закрывается.

Есть более редкие статусы, если вдруг стандартный сценарий меняется:

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

 Что значит «не воспроизводится» и почему это не всегда отписка

Топ-причина драк тестировщика и разраба — статус «не воспроизводится». Первый считает, что его послали, а второй — что проблему взяли с потолка. Но чаще всего неправы оба. 

Разработчик действительно может не повторить баг по техническим причинам:

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

В идеальном мире после этого статуса команда садится вместе и воспроизводит дефект. Если баг подтверждается, его статус меняется на «Переоткрыт». А если проблема уже исчезла сама, то тикет со спокойной душой закрывают.

Как писать баг-репорты, чтобы их не возвращали на уточнение

Чтобы отчёт об ошибке сразу улетал в работу, а не буксовал ещё на этапе уточнений, надо сделать всё красиво и понятно для разработчика. 

Вот чек-лист для составления баг-репорта

Топ ошибок при составлении отчётов:

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

Плохой и хороший баг-репорт на одном примере

Показываем, как надо и как не надо.

Вот за такой баг-репорт вас проклянут:

За этот, возможно тоже проклянут, потому что лишняя задачка, но баг-репорт всё равно хороший:

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