Баг-репорт: как правильно написать (шаблон + примеры)

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

В этом гайде разберём, из каких полей состоит баг-репорт по программе ISTQB, как сформулировать заголовок и шаги воспроизведения, чем severity отличается от priority, и покажем три полных примера «плохо → хорошо». В конце — чек-лист перед отправкой.

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

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

По программе ISTQB Foundation Level (версия 4.0.1), у отчёта о дефекте три цели: дать тем, кто будет его исправлять, достаточно информации; отслеживать качество продукта; подсказать, как улучшить процесс разработки и тестирования. То есть баг-репорт пишут не «для галочки» и не для отчёта руководителю, а для человека, который будет исправлять дефект.

Баг-репорты ведут в баг-трекере: Jira, YouTrack, Azure DevOps, GitHub Issues. Поля в разных системах называются по-разному, но суть одинакова. О том, какие бывают виды проверок, из которых вырастают баг-репорты, — в статье «Функциональное тестирование».

Структура баг-репорта: поля по ISTQB

Программа ISTQB Foundation Level перечисляет, что обычно содержит отчёт о дефекте, найденном во время тестирования. В таблице — эти поля с пояснением и примером.

Поле	Что писать	Пример
ID	Уникальный номер. Обычно присваивает баг-трекер.	SHOP-1423
Заголовок	Коротко: что сломалось, где и когда	Корзина: кнопка «Оформить заказ» неактивна после удаления промокода
Автор и дата	Кто нашёл и когда	А. Коваль, 12.11.2026
Объект и окружение	Что тестировали и где: ОС, браузер или устройство, стенд, версия сборки	Windows 11, Chrome 131, staging, сборка 2.14.0
Контекст	Тест-кейс или активность, в рамках которой найден дефект; тестовые данные	TC-87 «Применение промокода», пользователь test_buyer_3
Шаги воспроизведения	Нумерованный список действий	1. Открыть /cart. 2. Нажать «Удалить промокод». 3. Нажать «Оформить заказ»
Ожидаемый результат	Как должно быть по требованиям	Открывается страница оформления с ценой без скидки
Фактический результат	Что произошло на самом деле	Кнопка неактивна; в консоли TypeError
Severity	Серьёзность: насколько дефект вредит	Critical
Priority	Приоритет: как срочно исправлять	High
Статус	Состояние дефекта в жизненном цикле	New
Ссылки и вложения	Скриншоты, видео, логи, связанные задачи и тест-кейсы	checkout-bug.mp4, console.log

Проверки, из которых вырастает баг-репорт, обычно описаны в тест-кейсах. Если вы ещё путаете эти документы, начните с нашего гайда «Как стать QA-тестировщиком с нуля» — там разобрана вся тестовая документация.

Как написать заголовок

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

Что сломалось + где + при каком условии.

Плохо	Хорошо
Не работает корзина	Корзина: кнопка «Оформить заказ» неактивна после удаления промокода
Баг с регистрацией!!!	Регистрация: письмо подтверждения не приходит, если email содержит «+»
Поехала вёрстка	Главная, iPhone SE: кнопка «Купить» перекрывает цену в карточке товара
API падает	POST /api/orders возвращает 500, если quantity = 0

Несколько правил: без эмоций и оценок («ужасный баг»), без «не работает» без уточнения, до 80–100 символов. Один заголовок — один дефект.

Шаги воспроизведения, ожидаемый и фактический результат

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

Шаги — сердце баг-репорта. Их читает человек, который не видел, что вы делали, поэтому:

• Нумеруйте. Одно действие — один шаг.
• Начинайте с предусловий. Кто вошёл в систему, какие данные уже есть, какой язык интерфейса. «Пользователь авторизован, в корзине 1 товар, применён промокод SALE10».
• Пишите конкретно. Не «введите некорректные данные», а «в поле Email введите test@example».
• Проверьте шаги ещё раз перед отправкой. Если дефект не воспроизводится по вашим шагам — они неполные.

Ожидаемый результат

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

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

Что произошло на самом деле — точно и без интерпретаций. Текст ошибки копируйте дословно, а не пересказывайте. «Страница не загрузилась» хуже, чем «через 30 секунд появляется страница 504 Gateway Time-out».

Severity и Priority: в чём разница

Самый частый вопрос на собеседованиях Junior QA. Определения из глоссария ISTQB:

• Severity (критичность, серьёзность) — «важность воздействия конкретного дефекта на разработку или функционирование компонента или системы».
• Priority (приоритет) — степень важности, присваиваемая объекту, например дефекту.

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

Severity	Что означает	Пример
Blocker	Невозможно продолжить работу или тестирование, обходного пути нет	Приложение падает при запуске
Critical	Не работает ключевая функция или теряются данные либо деньги	Оплата списывает деньги, а заказ не создаётся
Major	Функция работает неправильно, но есть обходной путь	Фильтр по цене игнорирует верхнюю границу
Minor	Незначительный функциональный или визуальный дефект	Кнопка смещается на 5 px на мобильном
Trivial	Косметика, которая не влияет на работу	Опечатка в подвале сайта

Почему это два разных поля, лучше всего видно на крайних случаях:

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

Три примера: плохо → хорошо

Пример 1. Веб-приложение

Плохо: «Не могу оформить заказ, кнопка не работает. Исправьте срочно!»

Хорошо:

Пример 2. Мобильное приложение

Плохо: «На айфоне всё съехало».

Хорошо:

Пример 3. API

Плохо: «Заказ с нулём ломает бэкенд».

Хорошо:

Обратите внимание: в третьем примере тестировщик проверил не только ответ, но и базу данных. Именно поэтому SQL и тестирование API — обязательная часть навыков junior QA.

Скриншоты, видео и логи

• Скриншот — для визуальных дефектов. Выделите проблемное место рамкой или стрелкой, обрежьте лишнее.
• Видео — когда важна последовательность действий или дефект «мигает». 10–30 секунд достаточно.
• Консоль браузера — текст ошибки со вкладки Console в DevTools.
• Сеть — запрос и ответ со вкладки Network или HAR-файл, если проблема на границе фронтенда и бэкенда.
• Логи приложения — для мобильных и серверных дефектов, если у вас есть к ним доступ.

Проверьте, что во вложениях нет паролей, токенов и персональных данных реальных пользователей.

Жизненный цикл дефекта

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

New → Open → In Progress → Fixed → Retest → Closed (или Reopened, если дефект не исправлен).

Задача тестировщика не заканчивается отправкой: после исправления нужно проверить, что дефект действительно исчез и рядом ничего не сломалось. Именно для этого существует регрессионное тестирование.

Чек-лист перед отправкой

• Дефект воспроизводится ещё раз по моим шагам.
• Я проверил, что такого баг-репорта ещё нет (дубликат).
• Заголовок отвечает на вопросы «что, где, когда».
• Указаны окружение и версия сборки.
• Шаги пронумерованы, одно действие — один шаг.
• Есть ожидаемый и фактический результат.
• Severity и priority проставлены обоснованно, а не «всё Critical».
• Добавлены скриншот, видео или логи.
• Один дефект — один баг-репорт.
• Текст без эмоций и обвинений.

Типичные ошибки новичков

• Несколько дефектов в одном репорте. Один исправят, второй потеряется.
• «Не работает» без деталей. Разработчик потратит время, чтобы понять, что именно.
• Пропущенные предусловия. Дефект воспроизводится только с промокодом, а о промокоде ни слова.
• Интерпретация вместо факта. «Сервер не выдерживает нагрузку» вместо «ответ приходит через 30 секунд с кодом 504».
• Завышенная серьёзность. Если всё Critical, команда перестаёт доверять оценкам.
• Тон обвинения. Баг-репорт описывает продукт, а не человека.

Можно ли писать баг-репорты с AI

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

Частые вопросы

Что такое баг-репорт простыми словами?

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

Чем severity отличается от priority?

Severity (серьёзность, в глоссарии ISTQB — критичность) показывает, насколько сильно дефект влияет на работу системы, и её обычно определяет тестировщик. Priority (приоритет) показывает, насколько срочно дефект нужно исправить с точки зрения бизнеса, и окончательно его устанавливает менеджер продукта или лид команды. Поэтому бывают критичные дефекты с низким приоритетом и мелкие — с высоким.

Сколько шагов воспроизведения должно быть в баг-репорте?

Столько, сколько нужно, чтобы дефект воспроизвёл другой член команды, и не больше. Обычно это 3–8 шагов. Одно действие — один шаг. Если шагов получается больше 10–12, попробуйте найти более короткий путь к дефекту: это часто помогает понять его причину.

Обязательно ли прикладывать скриншот или видео?

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

На каком языке писать баг-репорты?

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

Что делать, если разработчик говорит, что это не баг, а фича?

Вернитесь к требованиям: если поведение противоречит спецификации, макету или принятым договорённостям, сошлитесь на конкретное место. Если требований нет, вынесите вопрос на продакт-менеджера или аналитика, а не спорьте в комментариях. Дефект со статусом «Rejected» — нормальный результат, если решение принято осознанно.

Источники

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1, раздел 5.5 «Defect Management»
• ISTQB Glossary: defect report, severity, priority

Стать QA-тестировщиком →