Какие поля нужно заполнять при заведении бага?

Структура баг-репорта: обязательные и рекомендуемые поля

При заведении дефекта в системе отслеживания (Jira, YouTrack, Redmine и т.д.) качественное заполнение полей — основа эффективной коммуникации между QA и разработчиками. Неполный или нечёткий баг-репорт увеличивает время на анализ и исправление. Поля можно разделить на обязательные (без которых репорт не имеет смысла) и рекомендуемые (для глубокого контекста).

1. Обязательные (минимальный жизнеспособный набор)

• Заголовок (Title/Summary): Краткое, но информативное описание проблемы. Должен отвечать на вопрос «Что? Где? При каких условиях?».

    *   *Плохо:* «Не работает кнопка».
    *   *Хорошо:* «Кнопка 'Submit' на форме регистрации неактивна после заполнения всех обязательных полей».

• Шаги воспроизведения (Steps to Reproduce): Последовательный, нумерованный список действий, ведущих к ошибке. Должен быть настолько детальным, чтобы любой член команды мог воспроизвести баг.

  Пример:
  1. Открыть главную страницу https://example.com.
  2. Нажать на ссылку "Регистрация".
  3. Заполнить поля: Email = test@example.com, Password = Qwerty123.
  4. Оставить поле "Phone number" пустым (оно помечено как обязательное).
  5. Нажать кнопку "Create Account".
  Ожидаемый результат: Появление валидационной ошибки под полем "Phone number".
  Фактический результат: Пользователь перенаправляется в личный кабинет, поле "Phone number" в профиле пустое.
  

• Фактический результат (Actual Result): Что происходит на самом деле после выполнения шагов. Констатация наблюдаемого некорректного поведения.
• Ожидаемый результат (Expected Result): Как система должна вести себя согласно требованиям, спецификации или здравому смыслу. Ключевое поле для определения, является ли наблюдаемое поведение дефектом.
• Серьезность (Severity): Оценка влияния бага на функционал продукта (Blocker, Critical, Major, Minor, Trivial). Определяется QA.
• Приоритет (Priority): Оценка срочности исправления (High, Medium, Low). Часто выставляется продактом или тимлидом с учетом Severity и бизнес-контекста.
• Статус (Status): Статус жизненного цикла бага (Open, In Progress, Resolved, Closed, Reopened). Меняется workflow.
• Назначенный (Assignee): Ответственный за исправление (разработчик) или за верификацию (QA). Позволяет отслеживать ответственность.

2. Рекомендуемые (для обогащения контекста)

• Описание (Description): Общее расширенное описание проблемы, если заголовка недостаточно. Можно добавить гипотезу о причине.
• Окружение (Environment): Конкретные условия, при которых баг был обнаружен. Крайне важно для нестабильных (flaky) багов.

    *   **Веб:** Браузер и его версия (Chrome 122), ОС (Windows 11), разрешение экрана.
    *   **Мобильное приложение:** Модель устройства (iPhone 15 Pro), версия ОС (iOS 17.4), тип сети (Wi-Fi/4G).
    *   **Бэкенд:** Версия API, окружение (Staging, Production).

• Компонент/Модуль (Component): На какую часть системы влияет дефект (e.g., "Payment Gateway", "User Profile API", "Mobile - iOS"). Помогает в маршрутизации.
• Файлы вложения (Attachments): Визуальные доказательства, которые сокращают время на понимание.

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

• Связанные артефакты (Links):

    *   **Test Case ID:** Связь с тест-кейсом в Test Management System (TestRail, Zephyr), который обнаружил баг.
    *   **Требование (Requirement/User Story):** Ссылка на требование в Confluence или задачу в Jira, которое было нарушено.
    *   **Pull Request:** После исправления — ссылка на код ревью.

• Тип дефекта (Bug Type): UI, Functional, Performance, Security, Localization. Помогает в анализе метрик.

Процесс от QA-инженера: больше, чем просто заполнение

1. Локализация и изоляция: Прежде чем заводить баг, я минимизирую шаги, проверяю на разных данных и окружениях, чтобы убедиться, что это не проблема данных или конфигурации.
2. Поиск дублей: Всегда проверяю, не был ли такой дефект уже заведен. Если нахожу, добавляю в найденный репорт своё окружение и шаги.
3. Чёткая формулировка: Пишу так, будто объясняю продукту, который вижу впервые. Избегаю местоимений ("оно", "там").
4. Подготовка данных: Заранее готовлю тестовые данные (логины, номера карт) и сохраняю их, если баг требует специфичных условий.
5. Критичность Severity: Выставляю её объективно. Blocker — система падает, дальнейшее тестирование невозможно. Critical — ключевая функция не работает. Major — функция работает с серьёзными ограничениями.

Вывод: Идеальный баг-репорт — это самодостаточный артефакт, который позволяет разработчику понять суть проблемы, воспроизвести её локально и найти причину, не обращаясь за дополнительными разъяснениями. Заполнение всех перечисленных полей — это не бюрократия, а профессиональный стандарт, который экономит время всей команды и ускоряет выпуск качественного продукта.