Баг-репорт, который читают: как правильно описать ошибку, чтобы разработчик сразу всё понял

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

1. Цена плохого баг-репорта

Статистика времени

Что происходит с плохим баг-репортом

Итого: от обнаружения бага до начала фикса проходит 5–8 часов вместо 10–15 минут.

Что даёт хороший баг-репорт

Цена ошибки

2. Анатомия хорошего баг-репорта

Обязательные элементы

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

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

Проблемы: Какая кнопка? На какой странице? В каком браузере? Что должно было произойти?

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

Почему хорошо: Разработчик сразу знает, где искать проблему (форма оплаты), видит ошибку, понимает окружение.

Структура идеального репорта

3. Заголовок: формула идеального названия

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

[Что не работает] + [Где] + [При каких условиях]

Примеры заголовков

Шаблоны заголовков для разных типов багов

Чего избегать в заголовке

4. Шаги воспроизведения: как писать правильно

Золотые правила шагов воспроизведения

Структура шагов

Примеры шагов: плохо vs хорошо

Пример 1: Форма регистрации

Пример 2: API-запрос

Уровень детализации

Частые ошибки в шагах воспроизведения

Чек-лист хороших шагов

• Шаги пронумерованы

• Указаны предусловия (роль, данные)

• Каждый шаг — одно конкретное действие

• Указаны точные названия элементов (кнопок, полей)

• Указаны точные значения (что вводить, что выбирать)

• Коллега смог воспроизвести по этим шагам

• Нет лишних шагов (только необходимые)

• Шаги написаны в императиве (не «я нажал», а «нажать»)

5. Ожидаемое vs фактическое поведение

Почему это важно

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

Как писать фактический результат

Примеры ОР vs ФР

Пример 1: Функциональный баг

Пример 2: UI-баг

Пример 3: Performance-баг

Частые ошибки

6. Окружение (Environment): что указывать

Обязательные параметры окружения

Дополнительные параметры (при необходимости)

Формат записи окружения

Веб-приложение

OS: Windows 11 Pro (23H2)
Browser: Chrome 120.0.6099.109
Resolution: 1920x1080
Version: v2.5.1 (prod)
URL: https://example.com

Мобильное приложение

Device: iPhone 15 Pro
OS: iOS 17.2
App version: 3.1.0 (build 456)
Network: Wi-Fi (100 Mbps)

API

Environment: Staging
API version: v2
Server: api-staging.example.com
Database: PostgreSQL 15.3

Как быстро собрать информацию

Частые ошибки

7. Приоритет (Priority) и Серьёзность (Severity)

Разница между Priority и Severity

Правило: Severity = насколько плохо ломается. Priority = как быстро надо чинить.

Уровни Severity

Уровни Priority

Матрица Severity vs Priority

Примеры комбинаций

High Severity + Low Priority

Баг: Критичная уязвимость безопасности в старой версии API, которую никто не использует.

Почему так: Технически серьёзно (S2), но не срочно (P4), т.к. никто не пострадает.

Low Severity + High Priority

Баг: Опечатка в названии компании на главной странице сайта.

Почему так: Технически мелочь (S5), но срочно (P2), т.к. видят все клиенты.

High Severity + High Priority

Баг: На prod не работает регистрация новых пользователей.

Почему так: Критичная функция сломана (S2), блокирует рост (P1).

Как определить Severity (для тестировщика)

Частые ошибки

8. Скриншоты, видео, логи: что прикладывать

Что прикладывать к баг-репорту

Скриншоты: как делать правильно

Видео: когда нужно и как записывать

Инструменты для записи видео

Формат и длина видео

Логи: какие и как собирать

Типы логов

Как оформлять логи

HAR-файлы для API-багов

HAR (HTTP Archive) — файл со всей информацией о сетевых запросах.

Чек-лист вложений

• Скриншот проблемы (для UI-багов)

• Видео воспроизведения (для сложных багов)

• Логи из консоли браузера (всегда проверять)

• HAR-файл (для API/network багов)

• Аннотации на скриншоте (стрелки, рамки)

• Понятные имена файлов (не screenshot1.png)

• Оптимизированный размер (до 10 МБ видео, до 2 МБ скриншот)

Частые ошибки

9. Типы багов и шаблоны описания

Функциональные баги

Пример:

Заголовок: Фильтр по цене не применяется в каталоге товаров после выбора категории

Окружение: Chrome 120, Windows 11, prod v2.5

Шаги:
1. Открыть /catalog
2. Выбрать категорию "Электроника"
3. В фильтре "Цена" ввести: От 1000, До 5000
4. Нажать "Применить"

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

Вложения: video.mp4, console-error.png

UI/UX баги

Пример:

Заголовок: Кнопка "Купить" имеет неправильный цвет и размер на карточках товаров

Окружение: Safari 17.2, macOS Sonoma, prod

ОР: Согласно макету Figma [ссылка]:
- Цвет: #10b981
- Высота: 48px
- Шрифт: 16px, medium

ФР:
- Цвет: #10c982 (не соответствует)
- Высота: 44px
- Шрифт: 14px

Вложения: comparison.png (макет слева, факт справа)

API баги

Пример:

Заголовок: 500 Internal Server Error на POST /api/orders при пустом поле delivery_address

Окружение: Staging API v2, PostgreSQL 15.3

Шаги (cURL):
curl -X POST https://api-staging.example.com/orders \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"product_id": 123, "quantity": 2, "delivery_address": ""}'

ОР: 400 Bad Request с сообщением "delivery_address is required"
ФР: 500 Internal Server Error

Response:
{
  "error": "Database constraint violation: delivery_address cannot be null"
}

Вложения: request-response.har

Performance баги

Пример:

Заголовок: Загрузка страницы /catalog занимает 15 сек при 1000+ товарах

Окружение: Chrome 120, Windows 11, prod

ОР: Согласно NFR: загрузка страницы < 3 сек
ФР:
- При 500 товарах: 6 сек
- При 1000 товарах: 15 сек
- При 1500 товарах: 23 сек

Метрики (Chrome DevTools):
- DOMContentLoaded: 12.3s
- Load: 15.1s
- Largest Contentful Paint: 13.8s

Вложения: performance-flamegraph.png, network-waterfall.png

Security баги

Важно: Security-баги отправлять приватно (не в публичный трекер), по защищённым каналам.

Пример:

Заголовок: XSS-уязвимость в форме комментариев позволяет выполнить произвольный JS

Окружение: prod v2.5
Severity: Critical
Priority: P1

Шаги (PoC):
1. Открыть /product/123
2. В поле "Комментарий" ввести:
   <script>alert(document.cookie)</script>
3. Нажать "Отправить"

ОР: Комментарий экранируется, отображается как текст
ФР: Скрипт выполняется, показывается alert с cookie

Impact: Атакующий может украсть сессии пользователей, выполнить действия от их имени

Recommendation: Экранировать HTML в комментариях на сервере

Вложения: xss-exploit.mp4 (НЕ публиковать)

Локализация/i18n баги

Пример:

Заголовок: Сообщение об ошибке валидации не переведено в форме логина на немецком

Окружение: Chrome 120, язык интерфейса: Deutsch (DE)

ОР: "E-Mail-Adresse ist ungültig"
ФР: "Email is invalid" (на английском)

Вложения: error-message-de.png

10. ТОП-10 ошибок в баг-репортах

Детали по каждой ошибке

Ошибка 1: Неинформативный заголовок

Ошибка 2: Нет шагов воспроизведения

Ошибка 7: Несколько багов в одном репорте

Почему раздельно:

• Разные разработчики могут фиксить

• Разные приоритеты

• Один баг может быть исправлен раньше других

• Удобнее трекать статус

Ошибка 9: Эмоции вместо фактов

Ошибка 10: Баг не воспроизводится

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

• Воспроизвёл баг минимум 2 раза подряд

• Проверил на другом браузере (если возможно)

• Проверил в инкогнито (чтобы исключить расширения)

• Проверил на другом аккаунте (чтобы исключить специфичные данные)

• Если баг intermittent — указал частоту (3 из 5 попыток)

• Если не могу воспроизвести снова — записал видео до того, как баг пропал

11. Инструменты для баг-трекинга

Популярные баг-трекеры

Сравнение возможностей

Вспомогательные инструменты

Инструменты для записи багов

Browser extensions для тестировщиков

Шаблоны баг-репортов в Jira

Пример Issue Template

## Environment
- OS:
- Browser:
- Version:
- URL:

## Steps to Reproduce
1.
2.
3.

## Expected Result


## Actual Result


## Attachments
- [ ] Screenshot
- [ ] Video
- [ ] Console logs
- [ ] HAR file

## Additional Info
- Reproducibility: Always / Sometimes (X of Y tries)
- User role:
- Test case ID:

Автоматизация баг-репортинга

12. Чек-лист идеального баг-репорта

Перед отправкой

После отправки

Критерии quality баг-репорта

Финальная проверка: 30-секундный тест

Покажи свой баг-репорт коллеге. Если он за 30 секунд понял:

• Что сломано

• Где сломано

• Как воспроизвести

→ Баг-репорт готов к отправке.

Итоги

Хороший баг-репорт — это не просто описание проблемы. Это инструмент эффективной коммуникации, который экономит время всей команды и ускоряет релизы. Ключевые выводы:

• Заголовок — формула: Что + Где + При каких условиях

• Шаги воспроизведения — детальные, нумерованные, воспроизводимые

• ОР vs ФР — чёткое разделение, ссылки на документацию

• Окружение — ОС, браузер, версия, URL обязательно

• Severity vs Priority — техническое влияние vs бизнес-срочность

• Вложения — скриншоты с аннотациями, видео, логи, HAR-файлы

• Один баг = один репорт — для удобного трекинга

• Воспроизводимость — проверить 2+ раза перед отправкой

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

А лучшие вакансии для QA (тестировщиков) ищите на hirehi.ru