Как написать баг-репорт: структура, шаги воспроизведения и пример

Баг-репорт (bug report) — это отчет об ошибке в программе: документ, по которому разработчик может повторить проблему у себя и понять, что именно работает не так. Хороший баг-репорт отвечает на три вопроса: что сломалось, как это увидеть своими глазами и насколько это срочно.

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

Зачем нужен баг-репорт

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

Баг-репорт живет в баг-трекере — системе учета ошибок (Jira, YouTrack, Redmine и другие; конкретный инструмент выбирает команда). Плохой отчет разработчик вернет с вопросом «а как повторить?», и на баг уйдет несколько дней переписки вместо часа работы. Понятный отчет экономит это время всем.

Обязательные и необязательные поля

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

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

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

Заголовок — самое читаемое поле: по нему баг сортируют, ищут и решают, брать ли его в работу. Хороший заголовок отвечает на «что, где, когда»: что сломалось, в каком месте и при каком действии.

Сравните. Плохо: «Ошибка на странице». Хорошо: «Клик по кнопке Оплатить в корзине не открывает экран оплаты (iOS, приложение 4.12)». Второй заголовок уже дает разработчику гипотезу, где искать.

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

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

Шаги воспроизведения (steps to reproduce) — это пронумерованный путь от известного старта до момента ошибки. Их пишут так, чтобы повторить баг мог человек, который видит продукт впервые.

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

После того как шаги написаны, пройдите по ним сами еще раз с чистого листа. Это ловит две частые беды: пропущенный шаг (у вас баг был, а по инструкции не повторяется) и плавающий баг, который воспроизводится не всегда — о такой нестабильности честно предупредите в отчете.

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

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

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

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

Severity и Priority: не путать

Эти два поля постоянно смешивают, хотя они про разное и их ставят разные люди.

Severity (серьезность) — это техническая оценка того, насколько сильно ошибка влияет на работу системы. Ее обычно ставит тестировщик.

Priority (приоритет) — это оценка срочности исправления с точки зрения бизнеса: что чинить в первую очередь. Ее обычно определяет менеджер продукта или ведущий разработчик.

Ключевая мысль: severity и priority не обязаны совпадать. Опечатка в названии компании на главной странице — низкая severity (система работает), но высокая priority (бьет по репутации, чинить сегодня). Редкий сбой в служебной админке — высокая severity (функция падает), но низкая priority (затрагивает двух сотрудников, подождет).

Названия и число уровней зависят от баг-трекера; ниже — распространенная шкала.

Вложения

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

Давайте вложениям понятные имена — например, по маске <ID бага>_<суть>: файл BUG-1043_payment-button.png находится в списке вложений мгновенно, а screenshot_final(2).png — нет.

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

Возьмем одну и ту же ошибку и оформим ее дважды. Сначала — как делать не надо.

Заголовок: Оплата не работает
Шаги: зашел в приложение, все сломалось
Результат: ошибка
Severity: blocker

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

Теперь тот же баг по правилам.

ID: BUG-1043
Заголовок: Кнопка Оплатить в корзине не открывает экран оплаты (iOS, приложение 4.12.0)
Предусловие: пользователь авторизован, в корзине один товар
Шаги воспроизведения:
  1. Открыть корзину
  2. Нажать кнопку Оплатить
Фактический результат: клик не обрабатывается, экран оплаты не открывается
Ожидаемый результат: открывается экран выбора способа оплаты
Окружение: iPhone 13, iOS 17.5, приложение 4.12.0
Severity: Critical (нельзя завершить покупку)
Priority: High
Вложения: BUG-1043_payment-button.mp4 (скринкаст)

Разработчик читает такой отчет один раз и сразу знает, где и как воспроизвести проблему.

Автопроверка полноты отчета

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

REQUIRED = ["id", "title", "steps", "actual", "expected",
            "environment", "severity", "priority"]

def missing_fields(report):
    # поле считаем незаполненным, если его нет или значение пустое
    return [f for f in REQUIRED if not report.get(f)]

good = {
    "id": "BUG-1043",
    "title": "Кнопка Оплатить не реагирует на клик в корзине на iOS",
    "steps": ["Открыть корзину с 1 товаром", "Нажать кнопку Оплатить"],
    "actual": "Клик не обрабатывается, переход к оплате не происходит",
    "expected": "Открывается экран выбора способа оплаты",
    "environment": "iPhone 13, iOS 17.5, приложение 4.12.0",
    "severity": "critical",
    "priority": "high",
}

bad = {
    "id": "BUG-1044",
    "title": "Не работает",
    "steps": [],
    "actual": "ошибка",
    "expected": "",
    "environment": "",
    "severity": "blocker",
    "priority": "high",
}

for name, report in [("good", good), ("bad ", bad)]:
    gaps = missing_fields(report)
    print(name, "-> пропущено:", gaps if gaps else "ничего, все обязательные поля заполнены")

Вывод программы:

good -> пропущено: ничего, все обязательные поля заполнены
bad  -> пропущено: ['steps', 'expected', 'environment']

Обратите внимание на границу метода: у отчета bad заголовок «Не работает» формально не пустой, поэтому проверка его пропускает. Автопроверка снимает грубые пробелы, но качество формулировок все равно остается на человеке.

Чек-лист и что делать, если баг не воспроизводится

Перед отправкой пройдитесь по короткому списку: заголовок отвечает на «что, где, когда»; шаги пронумерованы и повторяются с чистого листа; есть фактический и ожидаемый результат; указано окружение; severity и priority проставлены осознанно; приложен скриншот или скринкаст.

Если баг у вас был, а по вашим же шагам не повторяется, диагностируйте по симптомам. Не хватает шага — проверьте, не сделали ли вы что-то по привычке, не записав. Баг плавающий — укажите частоту («воспроизводится примерно в одном случае из пяти») и приложите скринкаст. Зависит от данных — добавьте в предусловие конкретный аккаунт или товар, на котором ошибка есть.

Выводы

• Баг-репорт — это отчет об ошибке, по которому разработчик повторяет проблему и понимает, что чинить; его цель — убрать лишние переписки.
• Обязательный костяк: ID, заголовок, шаги воспроизведения, фактический и ожидаемый результат, окружение, severity и priority.
• Заголовок отвечает на «что, где, когда», шаги нумеруются и проверяются с чистого листа, а фактический и ожидаемый результат вместе доказывают, что это баг.
• Severity — техническая серьезность (ставит тестировщик), priority — срочность для бизнеса (ставит менеджер); они не обязаны совпадать.
• Конкретные названия полей и уровней зависят от баг-трекера — сверяйтесь с правилами своей команды.

Где применяется и что учить дальше

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

FAQ

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

Что делать, если непонятно, баг это или задумано так? Сверьтесь с требованиями или спецификацией. Если там ответа нет, заводите отчет, но в ожидаемом результате честно отметьте, что поведение под вопросом, и адресуйте его аналитику или менеджеру.

Можно ли писать несколько багов в одном отчете? Не стоит. Один отчет — одна ошибка: так их проще оценивать, назначать и закрывать по отдельности. Разные баги в одной карточке застревают, пока не починят их все.