Баг-репорт: что это, шаблон, примеры и как оформить с видео

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

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

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

Баг-репорт (от англ. bug report, также отчёт об ошибке или дефект-репорт) — документ, который фиксирует отклонение фактического поведения программы от ожидаемого. Его пишут в трекере задач: Jira, YouTrack, Linear, GitHub Issues или аналогичном. Один отчёт описывает один дефект.

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

Баг, дефект и ошибка: в чём разница

В повседневной речи эти слова взаимозаменяемы. В тестировании их различают по стадии. Ошибка (error) — действие человека, например неверное условие в коде. Дефект (defect, он же баг) — следствие этой ошибки в программе. Сбой (failure) — проявление дефекта, которое видит пользователь. В баг-репорте обычно описывают именно сбой и приписывают его дефекту, а причину ищет разработчик.

Виды багов

Классификация помогает выбрать метку в трекере и подсказывает, какие данные приложить:

• Функциональные. Кнопка не отправляет форму, расчёт даёт неверную сумму, фильтр не применяется. К таким багам нужны шаги и входные данные.
• Визуальные (UI). Элементы наезжают друг на друга, текст обрезается, не работает тёмная тема. Лучше всего их показывает скриншот или видео.
• Производительность. Страница грузится долго, интерфейс подвисает при скролле. Здесь нужны время загрузки и условия, при которых это происходит.
• Совместимость. Ошибка есть в одном браузере или на одном разрешении и отсутствует в другом. Критичны точные версии окружения.
• Безопасность. Доступ к чужим данным, обход авторизации. Такие репорты оформляют закрыто и без публикации подробностей.
• Юзабилити. Функция работает, но пользователь не понимает, как ею пользоваться.

Из чего состоит баг-репорт: поля

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

Заголовок

Заголовок видят в списке задач, в уведомлениях и в поиске. По нему разработчик решает, открывать ли тикет прямо сейчас. Формула «где + что происходит + при каком условии» работает почти всегда: «Профиль: аватар не сохраняется после загрузки файла больше 5 МБ». Заголовки вида «Не работает», «Баг на сайте», «Ошибка» не несут информации и не находятся поиском.

Шаги воспроизведения

Шаги пишут так, будто читает человек, который впервые видит продукт. Начните с исходного состояния: под каким пользователем зашли, какие данные уже есть. Каждый шаг — одно действие. Конкретные значения (промокод, сумма, имя файла) выписывайте в явном виде, иначе баг у разработчика не повторится.

Ожидаемый и фактический результат

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

Окружение

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

Серьёзность и приоритет

Серьёзность (severity) описывает влияние дефекта на систему и ставится тем, кто нашёл баг. Приоритет (priority) определяет очередь исправления и обычно ставится менеджером или владельцем продукта. Шкалы разнятся от команды к команде, типичный вариант выглядит так:

Серьёзность и приоритет не совпадают автоматически. Опечатка в названии компании на главной странице имеет низкую серьёзность и высокий приоритет. Падение редко используемого отчёта в админке имеет высокую серьёзность и невысокий приоритет, если им пользуется один человек раз в квартал.

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

После создания репорт проходит несколько статусов. В большинстве трекеров цепочка выглядит так: Новый, Принят (назначен исполнитель), В работе, Исправлен, Проверен, Закрыт. Из любого шага баг может уйти в «Отклонён» (не дефект, работает по требованиям), «Дубликат» или «Не воспроизводится». Если после проверки ошибка осталась, тикет переоткрывают. Чем полнее исходный репорт, тем реже тикет попадает в статусы «Не воспроизводится» и «Переоткрыт».

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

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

Заголовок: [Где] [что происходит] [при каком условии]

Предусловия:
- Пользователь: [роль, тестовый аккаунт]
- Данные: [что должно быть создано до начала]

Шаги воспроизведения:
1. [Действие]
2. [Действие]
3. [Действие]

Ожидаемый результат:
[Как должно работать по требованиям]

Фактический результат:
[Что происходит, текст ошибки, код ответа]

Окружение:
- Браузер / ОС / устройство:
- Стенд и версия сборки:
- Разрешение экрана:

Воспроизводимость: [всегда / иногда (N из M) / один раз]
Серьёзность: [Blocker / Critical / Major / Minor / Trivial]
Приоритет: [High / Medium / Low]

Вложения:
- Видео: [ссылка на запись экрана]
- Скриншот, лог, HAR-файл: [прикрепить]

Что видит клиент: [одной фразой]
Где: [страница или раздел, ссылка]
Как дошёл до ошибки: [3-5 действий]
Что ожидал: [результат]
Что получил: [результат, текст ошибки]
Клиент: [логин или ID аккаунта, тариф]
Устройство и браузер: [данные]
Время ошибки: [дата, время, часовой пояс]
Видео: [ссылка на запись экрана]

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

Как описать баг: пять шагов

Порядок ниже помогает не упустить детали и не превратить отчёт в роман.

Шаг 1. Повторите баг минимум дважды

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

Шаг 2. Найдите минимальный путь

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

Шаг 3. Запишите заголовок и шаги

Сформулируйте заголовок по формуле «где + что происходит + при каком условии», затем пронумеруйте шаги. Пишите глаголами в повелительном наклонении: «Открыть», «Ввести», «Нажать». Не используйте «как обычно», «опять», «сами знаете».

Шаг 4. Соберите данные об окружении и вложения

Добавьте браузер, ОС, версию сборки и аккаунт. Приложите скриншот с отмеченным местом ошибки, текст ошибки из консоли браузера (F12, вкладка Console) и, если баг связан с сетью, запись запроса из вкладки Network. Для интерфейсных багов и плавающих дефектов добавьте видео, о нём ниже.

Шаг 5. Перечитайте глазами исполнителя

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

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

Разберём один и тот же дефект в двух вариантах. Сначала реальный по духу, но бесполезный отчёт:

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

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

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

Хороший пример баг-репорта

Заголовок: Оформление заказа: кнопка «Оплатить» не реагирует на клик
после ввода промокода

Предусловия:
- Пользователь: test_user_01, авторизован
- В корзине один товар

Шаги воспроизведения:
1. Открыть /checkout
2. В поле «Промокод» ввести SALE20 и нажать «Применить»
   (скидка отображается, итоговая сумма пересчитана)
3. Нажать «Оплатить»

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

Фактический результат:
Кнопка не реагирует на клик, переход не происходит.
В консоли: TypeError: Cannot read properties of undefined (reading 'id').
Без промокода оплата проходит.

Окружение:
- Chrome 130, Windows 11, 1920x1080
- Стенд stage, сборка 2.14.0

Воспроизводимость: 5 из 5 попыток
Серьёзность: Critical
Приоритет: High
Видео: [ссылка на запись экрана, 40 секунд]

Здесь есть исходное состояние, конкретное значение промокода, условие, при котором ломается («без промокода оплата проходит»), текст ошибки и окружение. Разработчик по такому тикету открывает стенд и через минуту видит ту же картину.

Баг-репорт с видео: как записать экран и приложить ссылку

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

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

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

1. Подготовьте экран. Закройте личные чаты и почту, оставьте на экране нужную страницу. Адресная строка с URL должна быть видна. Если важны размер окна и версия браузера, покажите их на старте.
2. Запустите запись. В расширении Скрини выберите вкладку, окно или весь экран. Для багов в браузере хватает записи вкладки. Включите микрофон: голосовые пояснения экономят уйму текста.
3. Пройдите сценарий. Действуйте не торопясь и проговаривайте шаги: «открываю корзину, ввожу промокод, нажимаю оплатить». Когда ошибка проявится, подержите кадр две-три секунды.
4. Покажите детали. Откройте DevTools (F12) и вкладку Console. Красная строка с ошибкой часто указывает разработчику на причину. Если баг связан с запросом, покажите вкладку Network.
5. Озвучьте ожидание. Одной фразой: «здесь должна открыться страница оплаты, но кнопка молчит».
6. Остановите запись и скопируйте ссылку. После загрузки Скрини выдаёт ссылку на просмотр вида skrini.ru/v/<идентификатор>. Вставьте её в поле «Видео» шаблона. Скачивать файл и загружать его на отдельный хостинг не нужно.

В процессе записи можно ставить маркеры-скриншоты сочетанием Ctrl+Shift+S, чтобы отметить момент ошибки. В платных тарифах речь превращается в текст с таймкодами, а на странице видео коллеги оставляют комментарии, привязанные ко времени. Для передачи записей в трекеры есть интеграции с YouTrack, Jira, GitHub Issues, Linear и вебхуком; какие из возможностей входят в ваш тариф, указано на странице тарифов.

Записать первый баг можно бесплатно: в тарифе Free запись длится до 2 минут, чего хватает для типичного дефекта, а для длинных сценариев есть платные тарифы. Установка расширения и регистрация занимают пару минут — попробовать Скрини. Подробный разбор записи в браузере есть в статье как записать экран онлайн.

Видео в обращениях саппорта

Для поддержки видео решает отдельную задачу: клиент не всегда может описать, что произошло, но легко записывает экран и отправляет ссылку. Инженер получает сценарий целиком и может переслать ссылку в разработку без пересказа. В короткий шаблон для саппорта выше поле «Видео» вынесено отдельной строкой не случайно. Подробности процесса — в статье запись экрана для техподдержки.

Проверьте свой баг-репорт за минуту

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