Как будешь заводить баг в систему

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

Общий подход: от обнаружения до отчетности

Мой процесс всегда начинается не с клика в системе, а с тщательной подготовки. Я следую принципу: «Плохой баг/репорт хуже, чем его отсутствие», потому что он тратит время разработчиков и запутывает процесс.

Шаг 1: Предварительная валидация и локализация

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

• Воспроизведение: Могу ли я воспроизвести дефект стабильно (100% или с известной вероятностью)? Если нет, это может быть Heisenbug, и его описание будет особым.
• Изоляция: Проблема в последней версии приложения? Актуальна ли для всех окружений (Dev, Stage)? Проявляется ли на разных браузерах/устройствах?
• Чистота окружения: Не связано ли это с кэшем, cookie, локальными настройками, данными тестового пользователя? Я часто проверяю в incognito режиме или на чистой виртуальной машине.
• Актуальность: Не заведен ли этот баг ранее? Обязательно проверяю в Jira, GitLab Issues или другой используемой системе, используя поиск по ключевым словам, сценарию и модулю.

Только после этого, если дефект подтвержден, я перехожу к оформлению.

Шаг146: Структура и содержание баг-Rепорта

Я следую классическому правилу «Как можно более подробно и как можно более сжато». Хороший репорт должен позволить любому члену команды (дев, менеджер, другой QA) понять суть и воспроизвести проблему без моих дополнительных пояснений.

Ключевые поля в системе (на примере Jira, но структура универсальна):

1. Summary (Заголовок): Кратко, ясно и информативно. Использую формулу: [Где] + [Что] + [При каком условии]. Пример: "Страница корзины: итоговая сумма рассчитывается неверно при добавлении товара со скидкой". Плохой пример: "Не работает кнопка".
2. Description (Описание): Здесь я даю детали. Структурирую так:

    *   **Окружение:** `OS: Windows 11, Browser: Chrome 122.0.6261.112, Environment: Staging, App Version: 2.5.1`
    *   **Шаги для воспроизведения (Steps to Reproduce):** Нумерованный список конкретных действий. Должен быть точен.

    ```markdown
    1.  Открыть главную страницу https://staging.example.com.
    2.  Авторизоваться под пользователем `test_user@mail.com` / `Password123`.
    3.  Перейти в каталог, выбрать товар "Монитор XYZ" (SKU: MON-XYZ-001).
    4.  Нажать кнопку "В корзину".
    5.  Перейти в корзину.
    6.  Обратить внимание на поле "Итоговая сумма".
    ```

    *   **Фактический результат (Actual Result):** Что происходит на самом деле. `"Итоговая сумма составляет 15 000 руб., хотя должна быть 14 250 руб. (с учетом скидки 5%)".`
    *   **Ожидаемый результат (Expected Result):** Ссылаюсь на требования, спецификацию или здравый смысл. `"Согласно требованию FR-345, итоговая сумма должна рассчитываться с учетом всех примененных скидок. Ожидаемая сумма: цена товара (15 000 руб.) - 5% = 14 250 руб."`
    *   **Дополнительная информация (Additional Context):** Это могут быть логи (`console.log`, `network`-запросы), предположения о возможной причине (если я, как QA, могу сделать educated guess, например: "Проблема проявляется только при скидке типа 'процент от суммы', скидки 'фиксированная сумма' работают корректно"), ссылки на связанные задачи.

1. Приоритет (Priority) и Серьезность (Severity): Я четко разделяю эти понятия и обосновываю выбор.

    *   **Severity (Blocker, Critical, Major, Minor, Trivial)** — объективная оценка влияния дефекта на функционал. `Blocker` — система падает, `Critical` — ключевая функция не работает. В нашем примере — `Major` (функция работает, но выдает неверный результат).
    *   **Priority (High, Medium, Low)** — субъективное решение команды/менеджера о том, КОГДА чинить. На него влияют severity, сроки, бизнес-важность фичи. Часто выставляется после обсуждения.

1. Прикрепленные файлы (Attachments): Это обязательно. Я всегда добавляю:

    *   **Скриншот (Screenshot)** с аннотациями: красные стрелки, круги, текст для выделения проблемы.
    *   **Скринкаст (Screen Recording)** для сложных или "плавающих" багов, особенно в UI или связанных с анимацией. Гифка или короткое видео.
    *   Логи из DevTools (вкладки `Console`, `Network` при необходимости) в виде текстового файла.

Шаг 3: После заведения

• Назначение (Assignee): Обычно система автоматически назначает задачу на разработчика нужной команды или тимлида. Если нет — назначаю вручную, основываясь на компоненте.
• Комментарий: Могу добавить первый комментарий, указав на срочность или особые условия воспроизведения.
• Мониторинг: Баг попадает в бэклог команды. Я отслеживаю его статус, готовлюсь к регрессионному тестированию после фикса. Если разработчик просит уточнений — оперативно отвечаю.

Ключевые принципы, которых я придерживаюсь:

• Нейтральность и объективность: Описываю факты, а не эмоции ("Приложение падает" вместо "Это ужасный баг!").
• Один баг — один репорт: Не объединяю несколько не связанных проблем. Это усложняет трекинг и фиксацию.
• Воспроизводимость — король: Если баг не воспроизводится стабильно, я все равно могу его завести, но в описании четко укажу: "Воспроизведено 2 раза из 10 попыток", "Условия воспроизведения не удалось полностью выявить" и приложу ВСЕ возможные логи и данные окружения.
• Связь с требованиями: Где возможно, ссылаюсь на номер user story, спецификацию или дизайн-макет (в Figma, Zeplin). Это превращает мой репорт из субъективного мнения в объективное несоответствие.

Таким образом, мой процесс заведения бага — это не механическое заполнение полей, а аналитическая работа, цель которой — максимально эффективно передать информацию о проблеме тем, кто ее будет исправлять. Это минимизирует цикл "вопрос-ответ" с разработчиком и ускоряет весь процесс разработки.