Modern QA2026Эффективные баг-репорты
Join

Course › 11 Manual Testing Fundamentals

Foundations · Chapter 11

Эффективные баг-репорты

Updated Jul 2026

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

Пять обязательных полей

Каждый баг-репорт, независимо от используемого инструмента (Jira, Linear, GitHub Issues, Bugzilla), должен содержать эти пять полей:

1. Окружение

ОС, браузер/версия, устройство, версия API, номер сборки, включённые feature flags. Это «где» бага.

Environment: Chrome 122, macOS 14.3, staging environment, build #4521
Feature flags: new_checkout_flow=true, dark_mode=false

Без деталей об окружении первый вопрос разработчика будет «какой браузер?» — и баг-репорт уже задерживается.

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

Нумерованные, минимальные. Уберите всё, что не требуется для воспроизведения бага. Если воспроизводится за 3 шага, не включайте 10.

Steps to Reproduce:
1. Navigate to https://staging.example.com/login
2. Enter email: user+tag@test.com
3. Enter password: ValidPass123!
4. Click "Sign In"

Минимально значит минимально. Не включайте «Открыть браузер» как шаг. Не включайте навигацию через домашнюю страницу, если прямой URL работает. Цель — кратчайший путь к багу.

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

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

Expected: User is authenticated and redirected to /dashboard.
The welcome message "Hello, user+tag@test.com" is displayed.

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

Что произошло на самом деле. Включите доказательства: скриншоты, ошибки в консоли, сетевые трассировки, тела ответов.

Actual: Server returns HTTP 500. Response body: {"error": "invalid_parameter"}.
No client-side errors in the console. Network tab shows the POST /auth/login
request failed with 500.

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

См. файл Серьёзность и приоритет для подробностей. Всегда указывайте оба параметра.

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

Аспект Плохо Хорошо
Заголовок «Вход сломан» «Вход возвращает 500, когда email содержит символ '+'»
Шаги «Попробовать войти» «1. Перейти на /login 2. Ввести user+tag@test.com 3. Ввести валидный пароль 4. Нажать Submit»
Ожидаемый «Должно работать» «Пользователь аутентифицирован и перенаправлен на /dashboard»
Фактический «Не работает» «Сервер возвращает HTTP 500. Тело ответа: {error: 'invalid_parameter'}. Консоль: нет клиентских ошибок.»
Окружение (отсутствует) «Chrome 122, macOS 14.3, staging env, build #4521»

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

Заголовок баг-репорта

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

Формула заголовка

[Что происходит] when [условие/триггер]

Примеры:

  • «Login returns 500 when email contains '+' character»
  • «Cart total shows $0.00 after applying 100% discount code»
  • «Profile image upload silently fails for files larger than 5MB»
  • «Search results page shows infinite spinner on empty query»

Антипаттерны:

  • «Bug in login» (какой баг?)
  • «URGENT: production issue!!!» (срочность указывается в поле приоритета)
  • «Test case TC-AUTH-007 failed» (что конкретно произошло?)

Вложения, ускоряющие исправление

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

Скриншоты с аннотациями

Не делайте просто скриншот всего экрана. Аннотируйте:

  • Обведите или укажите стрелкой на сломанный элемент
  • Выделите сообщения об ошибках
  • Включите адресную строку, чтобы разработчик знал точную страницу

Инструменты: macOS Screenshot (Cmd+Shift+4), Snagit, Lightshot, скриншот через DevTools браузера.

Видеозаписи

Для сложных многошаговых сценариев, где скриншотов недостаточно:

  • Ограничивайте видео 60 секундами
  • По возможности комментируйте голосом («Теперь я нажимаю Submit, и вы видите, что появляется ошибка...»)
  • Обрезайте начало и конец — начинайте непосредственно перед триггером бага

Инструменты: Loom, запись экрана macOS (Cmd+Shift+5), OBS Studio.

HAR-файлы и сетевые логи

Для проблем на уровне API файл HAR (HTTP Archive) фиксирует каждый сетевой запрос:

  1. Откройте Chrome DevTools > вкладка Network
  2. Воспроизведите баг
  3. Правой кнопкой на вкладке Network > «Save all as HAR with content»
  4. Приложите файл .har к баг-репорту

Логи консоли

Скопируйте и вставьте фактический вывод консоли. Не пересказывайте своими словами.

Console output:
Uncaught TypeError: Cannot read properties of undefined (reading 'map')
    at UserList.render (UserList.jsx:42)
    at processChild (react-dom.js:1234)

Команды cURL

Для API-багов предоставьте команду curl, которая воспроизводит проблему напрямую:

curl -X POST https://staging.example.com/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email": "user+tag@test.com", "password": "ValidPass123!"}'
# Returns: HTTP 500 {"error": "invalid_parameter"}

Это позволяет разработчику воспроизвести проблему без использования пользовательского интерфейса.

Изоляция: сужение бага

Перед оформлением попробуйте сузить масштаб. Чем точнее ваш отчёт, тем быстрее исправление.

Вопросы для самопроверки

  1. Специфично для браузера? Попробуйте в Chrome, Firefox, Safari. Если происходит только в одном — отметьте это.
  2. Специфично для окружения? Происходит на staging и в production, или только на staging?
  3. Специфично для данных? Происходит с любым email или только с email, содержащими спецсимволы?
  4. Специфично по времени? Происходит каждый раз или периодически?
  5. Специфично для прав доступа? Происходит для всех пользователей или только для определённых ролей?

Прерывистые баги

Это самые сложные для описания. Для прерывистых багов:

  • Укажите частоту воспроизведения: «Воспроизводится примерно в 3 из 10 попыток»
  • Опишите, что вы пробовали и что НЕ вызвало баг
  • Отметьте закономерности: «Чаще возникает сразу после деплоя»
  • Включите временные метки случаев, чтобы команда могла проверить логи

Рабочий процесс баг-репорта

Оформление

  1. Сначала проверьте наличие дубликатов. Дублирующие отчёты тратят время каждого.
  2. Оформляйте один баг на один отчёт. Не объединяйте «вход не работает И ссылка на сброс пароля сломана».
  3. Назначьте на правильную команду или компонент. Если не уверены, назначьте в очередь триажа.

После оформления

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

Верификация

Когда исправление развёрнуто:

  1. Воспроизведите по исходным шагам — баг должен исчезнуть.
  2. Протестируйте связанные сценарии — не внесло ли исправление регрессию?
  3. Закройте баг-репорт с комментарием: «Verified fixed in build #4530.»

Написание баг-репортов в условиях давления

При инцидентах в production вам может потребоваться оформить баг-репорт за 2 минуты. Используйте этот минимальный шаблон:

Title: [What breaks] when [trigger]
Environment: Production, [timestamp]
Steps: [minimal path]
Actual: [what happened, include error codes]
Impact: [who is affected, how many users]

Вы можете добавить детали позже. Приоритет — как можно быстрее донести информацию до нужных людей.

Практическое упражнение

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

  1. Попросите коллегу попробовать воспроизвести по вашему отчёту (не задавая вам вопросов)
  2. Если не смогут воспроизвести — вашему отчёту нужно больше деталей
  3. Если смогут воспроизвести менее чем за 2 минуты — ваш отчёт эффективен

Ключевые выводы

  • Баг-репорт должен обеспечивать воспроизведение менее чем за две минуты
  • Включайте все пять полей: окружение, шаги, ожидаемый результат, фактический результат, серьёзность/приоритет
  • Заголовок должен описывать баг, а не функцию: «[Что происходит] when [условие]»
  • Прикладывайте доказательства: аннотированные скриншоты, HAR-файлы, логи консоли, команды curl
  • Изолируйте перед оформлением: сузьте браузер, окружение, данные и права доступа
  • Быстро отвечайте на вопросы разработчиков — устаревший баг-репорт теряет приоритет