Как писать баг-репорты: ошибки новичков и примеры из практики

Баг-репорт — это не бюрократия; это документ, по которому разработчик будет чинить баг. Если написал плохо — баг может вернуться к тебе с пометкой «не воспроизводится». Или, ещё хуже, разработчик потратит час, чтобы понять, что ты имел в виду — а потом придёт с вопросами, которые ты мог закрыть сразу.

Я проверил сотни студенческих работ на своих курсах и вижу одни и те же ошибки снова и снова. Одинаковые заголовки, которые ничего не говорят. Одинаковые лишние шаги. Одинаковое «ну, там что-то не так» вместо конкретного описания.

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

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

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

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

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

Представь: ты тестируешь интернет-магазин. Добавляешь товар в корзину, нажимаешь «Оформить заказ» — и вместо страницы оформления видишь ошибку 500 (обычно такая выводится, когда сервер вообще не понял, что делать с запросом, или помер).

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

Заголовок: Не работает оформление заказа

Шаги: Нажать «Оформить заказ»

Ожидаемый результат: Должно работать

Фактический результат: Не работает

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

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

Окружение: Chrome 120, Windows 11, прод-среда

Шаги:

1. Открыть каталог товаров
2. Добавить любой товар в корзину
3. Перейти в корзину
4. Нажать кнопку «Оформить заказ»

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

Фактический результат: Отображается страница с ошибкой 500 (Internal Server Error)

Приоритет: критический

Вложения: скриншот ошибки, скриншот консоли с 500-м статусом

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

Давай пробежимся по ключевым полям:

• Заголовок (Summary) — самое важное поле. Должен отвечать на вопрос «где сломалось, что и при каких условиях». Подробнее — в отдельном разделе ниже.
• Шаги воспроизведения (Steps to Reproduce) — минимальный набор действий для воспроизведения бага. Ключевое слово — минимальный.
• Ожидаемый результат (Expected Result) — что должно происходить по требованиям или здравому смыслу.
• Фактический результат (Actual Result) — что происходит на самом деле. Максимально конкретно.
• Severity / Priority — насколько критичен баг. Severity — техническая серьёзность (blocker, critical, major, minor, trivial). Priority — бизнес-приоритет исправления.
• Окружение (Environment) — браузер, ОС, среда (прод, стейдж, дев). Без этого разработчик может просто не воспроизвести баг.
• Вложения — скриншоты, видео, логи. Визуальные баги без скриншота — это как пересказывать мем словами.

Заголовок, шаги, ОР и ФР (ожидаемый и фактический результат) есть всегда; серьезность и приоритет не везде принято ставить, а окружение не везде нужно (если баг не зависит ни от браузера, ни от операционной системы, ни от чего-либо еще, то как будто бы и можно не писать). Что касается вложений, то иногда они помогают понять проблему, а иногда и без них очевидно.

Ошибки новичков — разбор полётов

Я проверяю студенческие работы на курсах уже больше двух лет — и студенты совершают очень похожие ошибки. Вот топ-5, которые я вижу чаще всего.

1. Заголовок описывает ожидание, а не реальность

Очень часто я натыкаюсь на заголовки вроде:

«В подзаголовке должен быть текст Пельмени»

Отлично — а что на самом деле? Я читаю баг-репорт, а не требования. Я хочу увидеть, что пошло не так.

❌ Плохо: В поле должна быть дата рождения

✅ Хорошо: В поле «Дата рождения» отображается «null» вместо даты

Заголовок должен описывать проблему, а не цитировать ТЗ.

2. Два бага в одном репорте (и наоборот)

Два по цене одного — классика.

"При нажатии на кнопку «Купить» приложение крашится, а ещё кнопка зелёная вместо красной".

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

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

Правило простое: если у багов разные причины — разделяй. Если одна причина — объединяй.

3. Лишние шаги воспроизведения

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

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

4. Нет конкретики в данных

«Введите значение в поле» — какое значение? Может, баг воспроизводится на определенных значениях.

«Нажмите кнопку» — какую кнопку? На странице может быть и десять кнопок.

Конкретные данные — конкретный результат. Если баг воспроизводится при вводе email без символа @, так и пиши: «Ввести test.mail.ru в поле Email». Не «ввести некорректный email» — потому что некорректный email может быть десятком разных вещей.

5. Визуальные баги без скриншотов

Визуальный баг без скриншота — это как пересказывать мем словами. Можно, конечно, но зачем?

Скриншот не только показывает баг, но и фиксирует окружение: какой браузер, какое разрешение, какие данные были на экране. Это бесплатный контекст, который ты даёшь разработчику.

Для неочевидных багов записывай видео — 30 секунд скринкаста стоят тысячи слов.

Заголовок — самая важная строка

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

Формула хорошего заголовка:

Что сломалось + Где + При каких условиях

Вот примеры:

❌ Проблема с корзиной

✅ Товар не добавляется в корзину при клике на «Купить» на странице каталога

❌ Ошибка в поле

✅ Поле «Email» принимает значение без символа @ на странице регистрации

❌ Картинка не отображается

✅ Аватар пользователя отображается как битая ссылка в профиле после смены фото

❌ Не работает поиск

✅ Поиск возвращает пустой результат при вводе кириллицы в каталоге товаров

❌ Кнопка не нажимается

✅ Кнопка «Отправить» неактивна после заполнения всех обязательных полей на странице обратной связи

❌ Ошибка при регистрации

✅ Ошибка 422 при регистрации с email, содержащим символ «+» (user+tag@mail.ru)

Заметь закономерность: плохие заголовки — одно-три слова, которые ничего не говорят. Хорошие — полное предложение, после которого понятно, что произошло, даже без чтения остального баг-репорта.

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

Мышление тестировщика — как находить то, что не просили

Хороший баг-репорт — это результат, а не процесс. Процесс — это то, как ты думаешь, когда тестируешь.

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

И что вы думаете? Я получил пять работ на проверку — и в них было описано пять разных багов, о существовании половины которых я даже не подозревал. Студенты настолько внимательно прошлись по требованиям, что нашли то, о чём я не думал даже как автор проекта.

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

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

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

Подробнее о том, каково работать тестировщиком каждый день — в статье «Каково работать тестировщиком».

Баг-репорт и нейросети

В 2026 году было бы странно не попробовать использовать ChatGPT/Claude/Gemini/Deepseek для работы с баг-репортами. Давай разберёмся, где это помогает, а где — нет.

Что ИИ реально может:

• Переформулировать невнятный заголовок в конкретный
• Подсказать пропущенные шаги воспроизведения
• Предложить дополнительные сценарии для проверки
• Привести в порядок форматирование и структуру

Что ИИ не может:

• Понять контекст твоего проекта — требования, договорённости, бизнес-логику
• Оценить severity на основе бизнес-приоритетов
• Решить, один это баг или два — для этого нужно понимать архитектуру
• Воспроизвести баг и проверить, что шаги корректны

У тестировщика в голове много проектной специфики: требования, документация, информация с созвонов и чатов, негласные правила и договорённости. Без этого контекста нейросети выдают слишком общую информацию.

Нейросеть — хороший ревьюер черновика, но плохой автор баг-репорта. Используй её как second opinion: написал баг-репорт, скинул в ChatGPT, спросил «что я мог упустить?». Но финальное решение — всегда за тобой.

Заключение

Баг-репорт — это навык, а не знание. Его нельзя выучить из статьи — нужно написать десятки и получить обратную связь.

Прочитать правила — первый шаг. Применить их на практике — совсем другое дело.

Если коротко:

• Заголовок должен отвечать на вопрос «что, где, когда»
• Шаги — минимальные, данные — конкретные
• Один баг — один репорт
• Скриншоты обязательны для визуальных багов
• Думай как тестировщик: задавай вопросы к требованиям

В курсе по веб-тестированию — учебные проекты с заложенными багами и проверка каждого баг-репорта преподавателем. А в полной программе — ещё и API-тестирование, SQL и всё, что нужно для трудоустройства.

Полная программа подготовки · Телеграм-канал