Что должно входить в хороший баг-репорта

Структура и содержание идеального баг-репорта

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

Обязательные компоненты баг-репорта

1. Короткий, но информативный заголовок (Title/Summary)

    *   Должен однозначно отражать суть проблемы. Хороший заголовок — это ответ на вопрос «*Что* сломалось и *где*?».
    *   **Плохо:** "Не работает кнопка".
    *   **Хорошо:** "Кнопка 'Отправить' в форме обратной связи неактивна после ввода невалидного e-mail".

1. Идентификаторы и приоритет (ID, Severity, Priority)

    *   **ID:** Уникальный номер, присваиваемый трекером (JIRA, Youtrack и т.д.).
    *   **Severity (Критичность):** Объективная оценка влияния дефекта на систему (Blocker, Critical, Major, Minor, Trivial).
    *   **Priority (Приоритет):** Субъективная оценка важности исправления с точки зрения бизнеса или релиза (High, Medium, Low). Эти поля часто задаются в соответствии с политикой проекта.

1. Детальное описание (Description)

    *   **Что происходит?** Точное и нейтральное описание некорректного поведения системы.
    *   **Что должно происходить?** Чёткая ссылка на требования, спецификацию или ожидаемое корректное поведение. Это ключевой критерий для определения, является ли ситуация багом.

1. Шаги для воспроизведения (Steps to Reproduce)

    *   **Нумерованный, максимально детализированный список действий.** Разработчик, следуя этим шагам, должен гарантированно получить тот же результат.
    *   **Пример:**

    ```gherkin
    1. Открыть главную страницу сайта https://example.com.
    2. Нажать на кнопку "Войти".
    3. В модальном окне в поле "Логин" ввести 'test_user'.
    4. В поле "Пароль" ввести '12345'.
    5. Нажать кнопку "Отправить".
    ```

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

1. Окружение (Environment)

    *   Позволяет выявить специфические для платформы или конфигурации проблемы.
    *   **Что указывать:**
        *   **ОС и версия:** Windows 11 Pro 22H2, macOS Ventura 13.5, Android 14.
        *   **Браузер и версия:** Chrome 122.0.6261.94 (Desktop), Safari 16.5 (iOS).
        *   **Версия приложения / билд:** Mobile App v2.4.1 (build 781), Backend API v1.5.3.
        *   **Дополнительно:** Разрешение экрана, наличие специфичных программ, локаль, тип сети (Wi-Fi/4G).

1. Визуальные доказательства (Attachments)

    *   **Скриншоты / Скринкаст:** Один скриншот может заменить сотни слов. Важно выделять на скриншоте область с проблемой (стрелкой, рамкой).
    *   **Логи (Logs):** Ключевые фрагменты из консоли браузера (F12 -> Console/Network), серверных логов, логов мобильного приложения (logcat для Android, console для iOS).

    ```javascript
    // Пример ошибки из консоли браузера
    Uncaught TypeError: Cannot read properties of undefined (reading 'submit')
        at HTMLButtonElement.onclick (main.js:47)
    ```

    *   **Ответы API:** Запрос/ответ с ошибкой из вкладки Network инструментов разработчика.

Дополнительные элементы, повышающие ценность отчёта

• Связанные тест-кейсы: Ссылка на упавший автоматизированный или ручной тест.
• Анализ и предположения (Root Cause Analysis): Если тестировщик обладает технической экспертизой, можно добавить предположение о возможной причине (например, "Проблема, вероятно, связана с кэшированием данных пользователя после смены роли").
• Работоспособность в других окружениях: Указание, воспроизводится ли баг в другом браузере или на другом устройстве. Например: "На iOS Safari поведение корректное".
• Частота воспроизведения: Всегда (100%), Иногда (~30%), Один раз.
• История и связи: Ссылки на связанные задачи, инциденты, требования.

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

Заголовок: Поиск по каталогу возвращает ошибку 500 при использовании кириллических символов в запросе.

Серьезность: Major Приоритет: High

Окружение:

• ОС: Windows 10
• Браузер: Chrome 121
• Билд бэкенда: v1.2.0
• Фронтенд: latest (main branch)

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

1. Перейти на страницу каталога товаров /catalog.
2. В строке поиска ввести слово "футболка".
3. Нажать Enter или кликнуть на иконку лупы.

Ожидаемый результат: Отображается список товаров, соответствующих поисковому запросу. Фактический результат: Страница перезагружается, отображается стандартная ошибка сервера "500 Internal Server Error". В консоли браузера — ошибка.

Приложения:

1. Скриншот страницы с ошибкой (приложен).
2. Лог из консоли браузера:

   GET https://api.example.com/search?q=%D1%84%D1%83%D1%82%D0%B1%D0%BE%D0%BB%D0%BA%D0%B0 500
   

3. Ответ от сервера (вкладка Network -> Preview):

   {
     "error": "Database query failed: Illegal mix of collations"
   }
   

Дополнительно: Проблема не воспроизводится при поиске на латинице (например, "t-shirt").

---

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