Почему качество баг-репортов важно

Баг-репорт — это инструмент коммуникации между QA и разработкой. Хорошо написанный баг-репорт исправляется быстро. Плохо написанный игнорируется, возвращается на уточнение или депритизируется, потому что никто не может воспроизвести.

Влияние плохих баг-репортов:

  • Разработчик тратит 30 минут на воспроизведение размытого бага = потерянное время
  • Баг возвращается в QA за дополнительной информацией = задержка 1-2 дня
  • Баг закрывается как «Cannot Reproduce» = дефект уходит в production

Влияние хороших баг-репортов:

  • Разработчик читает репорт, воспроизводит за 2 минуты, сразу начинает исправлять
  • Не нужна коммуникация туда-обратно
  • Баг исправляется в том же спринте, когда был обнаружен

Анатомия идеального баг-репорта

Заголовок

Заголовок должен отвечать на три вопроса: Что сломалось, Где сломалось и Когда/Как сломалось.

Формула: [Компонент] Действие падает с [Ошибкой] при [Условии]

Плохо: «Логин не работает» Хорошо: «Форма логина возвращает HTTP 500 при email с символом ‘+’»

Плохо: «Проблема с корзиной» Хорошо: «Итого корзины показывает $0.00 после применения купона 100% скидки к одному товару»

Окружение

Всегда указывайте: браузер/версия, ОС, разрешение экрана, роль пользователя, версия API.

Предусловия

Чётко укажите начальную точку:

  • «Пользователь авторизован с ролью Admin»
  • «В корзине 2 товара (итого: $59.98)»

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

Пронумерованные, точные шаги, которые может выполнить любой:

1. Перейти на https://app.example.com/login
2. Ввести "user+test@example.com" в поле email
3. Ввести "ValidPass123!" в поле пароля
4. Нажать кнопку "Sign In"

Правила:

  • Одно действие на шаг
  • Указывать точные значения (не «введите email»)
  • Указывать точные URL и пути навигации
  • Нумеровать каждый шаг
  • Начинать из известного состояния (предусловия)

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

Что должно произойти согласно требованиям: «Пользователь перенаправлен на дашборд. Приветствие отображает имя пользователя.»

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

Что происходит на самом деле, с конкретными деталями: «Страница показывает HTTP 500 Internal Server Error. В консоли: TypeError: Cannot read property 'split' of undefined»

Доказательства

Прикрепите:

  • Скриншот — с аннотациями (стрелки, выделения) на проблемные места
  • Видео — запись экрана с полным воспроизведением
  • Логи консоли — ошибки из консоли браузера
  • Сетевой трейс — файл HAR или конкретный request/response
  • Серверные логи — релевантные записи об ошибках

Дополнительная информация

  • Частота: Всегда / Периодически (3 из 10 попыток) / Один раз
  • Обходной путь: Есть ли альтернативный путь для пользователей?
  • Регрессия: Работало ли в предыдущей версии?
  • Связанные баги: Ссылки на похожие issues

Пример реального баг-репорта 

Заголовок: Checkout падает с "Payment declined" для валидных карт Visa,
           заканчивающихся на 0000, в Safari 17

Окружение: Safari 17.2 / macOS Sonoma 14.2 / Production

Предусловия:
- Пользователь авторизован как test_user_42
- В корзине "Premium Plan" ($49.99/мес)

Шаги воспроизведения:
1. Перейти на /checkout
2. Выбрать способ оплаты "Credit Card"
3. Ввести карту: 4242 4242 4242 0000
4. Ввести срок: 12/28
5. Ввести CVC: 123
6. Нажать "Subscribe"

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

Фактический результат:
Баннер ошибки: "Payment declined. Please try a different card."
В Network tab: POST /api/payments возвращает 422.

Примечание: Та же карта работает в Chrome 120 и Firefox 121.
Проблема специфична для Safari.

Частота: Всегда в Safari 17. Никогда в Chrome/Firefox.
Обходной путь: Оформить заказ в Chrome.
Регрессия: Работало в Safari 16.

Упражнение: Исправьте баг-репорты

Перепишите следующие плохо написанные баг-репорты:

Плохой репорт 1:

Заголовок: Поиск сломан
Описание: Когда я ищу что-то, работает неправильно.

Плохой репорт 2:

Заголовок: Медленная страница
Описание: Страница слишком медленная. Пожалуйста, исправьте.
Решение

Переписанный репорт 1:

Заголовок: Поиск возвращает 0 результатов для существующих товаров,
           когда запрос содержит спецсимволы (&, <, >)

Окружение: Chrome 120 / Windows 11 / QA-окружение

Предусловия:
- Товар "AT&T Wireless Plan" существует в БД
- Пользователь на главной странице

Шаги:
1. Кликнуть на строку поиска в шапке
2. Ввести "AT&T"
3. Нажать Enter

Ожидаемый: Результаты показывают "AT&T Wireless Plan"
Фактический: "0 results found for AT&T". Символ & кодируется как %26,
но API не декодирует его перед поиском.

Частота: Всегда с &, <, >. Обычные запросы работают.

Переписанный репорт 2:

Заголовок: Дашборд загружается 12 секунд при 500+ задачах
           (ожидается < 3 секунд)

Окружение: Chrome 120 / macOS / Production

Предусловия: Аккаунт с 547 задачами в 12 проектах

Шаги:
1. Войти как test_heavy_user (547 задач)
2. Перейти на /dashboard
3. Измерить время загрузки (DOMContentLoaded)

Ожидаемый: Дашборд загружается менее чем за 3 секунды
Фактический: DOMContentLoaded: 12.3 секунды. GET /api/tasks
возвращает 547 элементов одним ответом (4.2MB). Нет пагинации.

Доказательства: [профиль производительности] [файл HAR]

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

  1. «Не работает» — объясните, что конкретно не работает
  2. Нет шагов воспроизведения — разработчики не могут починить то, что не видят
  3. Скриншоты без контекста — всегда аннотируйте, на что смотреть
  4. Нет информации об окружении — баги часто специфичны для браузера или ОС
  5. Эмоциональный язык — «Этот ужасный баг» не помогает. Будьте фактичны
  6. Не проверить, был ли уже зарегистрирован — сначала поищите существующие

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

  • Баг-репорты — инструменты коммуникации, пишите для разработчика, который будет исправлять
  • Формула заголовка: [Компонент] Действие падает с [Ошибкой] при [Условии]
  • Шаги воспроизведения — самый важный раздел: одно действие на шаг, точные значения
  • Всегда включайте ожидаемый vs фактический результат с конкретными деталями
  • Прикрепляйте доказательства: аннотированные скриншоты, видео, логи консоли, сетевые трейсы
  • Указывайте окружение, частоту, обходной путь и информацию о регрессии