Самый частый исход плохо написанного баг-репорта: разработчик не может воспроизвести проблему, помечает её «Cannot Reproduce» и идёт дальше. Баг остаётся. Каждый элемент эффективного репорта предотвращает конкретный провал: точный заголовок предотвращает неверную маршрутизацию, пронумерованные шаги с предусловиями предотвращают «не воспроизводится», раздельные ожидаемый и фактический результаты не дают разработчикам депrioritize то что они не могут оценить.

Почему баг-репорты проваливаются

Самый частый исход плохо написанного баг-репорта: разработчик открывает его, не может воспроизвести, помечает «Cannot Reproduce» и идёт дальше. Баг остаётся. Время потрачено. Разработчик слегка раздражён. Никто не выигрывает.

Второй по частоте исход: разработчик воспроизводит, но не понимает влияние, депrioritizes, и это уходит в продакшн.

Оба провала предотвратимы.

Анатомия баг-репорта который исправят

Заголовок: одно предложение, без расплывчатых слов

Заголовок: то что видно в Jira или любом другом трекере команды. Разработчик читая список тикетов должен понять что за баг, не открывая его.

Плохие заголовки:

  • «Login bug»
  • «Something broken on the dashboard»
  • «Error message issue»
  • «Table not working correctly»

Хорошие заголовки:

  • «Login form submits with empty password field: no validation error shown»
  • «Dashboard table loses sort order after filtering by status»
  • «File upload shows 'Success' toast even when upload fails with 413 error»
  • «Items table row count differs from API response when page is loaded with active filter»

Паттерн: [компонент/фича] [что происходит] [когда/при каком условии]. Всё что нужно разработчику чтобы понять масштаб проблемы, ещё не кликая на открытие.

Окружение: точно где это происходит

Расплывчато: «Chrome on Windows»

Полезно:

Browser: Chrome 124.0.6367.78 (Windows 11)
OS: Windows 11 22H2
App version/build: v2.4.1 (commit: abc123)
Test environment: staging (https://staging.lab.becomeqa.com)
Test user: admin@becomeqa.com

Детали окружения кажутся занудством пока не пытаешься воспроизвести баг который возникает только в Firefox на macOS, и 20 минут запускаешь Chrome на Windows недоумевая почему не падает.

Шаги воспроизведения: точные, пронумерованные, самодостаточные

Каждый шаг должен быть настолько конкретным чтобы человек никогда не видевший этот баг воспроизвёл его с первой попытки.

Плохо:

1. Log in
2. Go to items
3. Sort and filter
4. Bug appears

Хорошо:

Preconditions: User is logged in as admin@becomeqa.com. 
The items table is displaying the default view (no active filters).

Steps:
1. Navigate to https://lab.becomeqa.com/dashboard
2. Click the "Status" column header to sort ascending
3. Click the "Filter" dropdown and select "Planned"
4. Click the "Status" column header again to sort descending
5. Remove the filter by clicking "Clear" in the filter dropdown

Expected result: Table returns to default view showing all items, 
sorted by the last sort order (Status descending).

Actual result: Table shows all items but sort order resets to default 
(unsorted), losing the sort state from step 2.

Разница: первый вариант заставляет читателя угадывать что означает «sort and filter». Второй не требует угадывания.

Ожидаемый и фактический результат: нужны оба, а не один

Каждый баг-репорт требует обоих:

Ожидаемый результат: что должно произойти согласно спецификации, здравому смыслу или намерению разработчика. Если есть задокументированное требование, ссылайся на него. «Согласно критериям приёмки в PROJ-142, фильтрация не должна влиять на состояние сортировки». Фактический результат: что происходит на самом деле. Будь точен. «Показывает ошибку»: слабо. «Отображает 'Internal Server Error' в красном тосте вверху страницы на 3 секунды»: полезно.
Не пиши «Ожидаемый: работает. Фактический: не работает». Это самый распространённый провал в баг-репортах джуниоров. Ожидаемый результат должен описывать конкретное правильное поведение, а не просто «работает».

Severity и priority: разные вещи

Severity оценивает влияние на систему: насколько серьёзен этот баг технически?
  • Critical: крах системы, потеря данных, уязвимость безопасности, блокирует основную функциональность для всех пользователей
  • Major: значимая фича сломана для части пользователей, есть обходное решение
  • Minor: небольшая функциональная проблема, косметическое, вряд ли затронет многих пользователей
  • Trivial: опечатка, незначительное несоответствие UI, нет функционального влияния
Priority отражает бизнес-срочность: как быстро это нужно исправить?

Опечатка на странице ошибки медицинского продукта может быть Minor severity но High priority (вопрос соответствия нормативам). Сломанная функция для администраторов может быть Major severity но Low priority (используется раз в месяц двумя людьми).

Точная оценка severity и priority сигнализирует что ты понимаешь бизнес-влияние, а не только техническое поведение.

Вложения: показывай, а не только описывай

Скриншоты визуально фиксируют фактический результат. Скриншот с неверным тостом стоит больше трёх предложений его описания.

Видеозаписи незаменимы для багов зависящих от тайминга: гонки состояний, глюки анимации, нестабильные падения. Программа записи экрана (Loom, OBS, ShareX) настраивается за 30 секунд и предотвращает часы «не воспроизводится».

Сетевые логи (из DevTools браузера, вкладка Network) критичны для багов на уровне API. Они показывают точно какой запрос был отправлен, какой ответ пришёл, и тайминг.

Логи консоли часто содержат ошибку объясняющую баг. Разработчики мгновенно видят первопричину из стектрейса JavaScript-ошибки.

Для нестабильных багов запиши видео при первом воспроизведении. Не предполагай что сможешь воспроизвести снова для разработчика.

Полный пример

Вот как выглядит хорошо написанный баг-репорт:

Title: File upload modal shows "Upload successful" toast when file exceeds 5MB size limit Environment:
  • Browser: Chrome 124, Firefox 125
  • OS: Windows 11
  • Build: v2.4.1
  • Environment: staging
Preconditions: User logged in as admin@becomeqa.com Steps to reproduce:

1. Navigate to https://staging.lab.becomeqa.com/dashboard

2. Click "Upload File" button

3. Select a file larger than 5MB (e.g., a 10MB .pdf)

4. Click "Upload" in the modal

Expected result: Upload fails with a validation error: "File size must be 5MB or less." The file is not uploaded. The success toast does not appear. Actual result: Modal closes, "Upload successful" toast appears briefly. On navigation to Files section, the file is not present, indicating upload failed silently. No error is communicated to the user. Severity: Major. Users lose their upload without any feedback, and may not realize the file wasn't saved. Priority: High. Affects any user trying to upload files over the size limit. Attachments: [screenshot showing success toast] [network log showing 413 response]

Этот репорт даёт разработчику всё: точное воспроизведение, чёткое сравнение ожидаемого и фактического, точную оценку severity, и доказательства.

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

«Не работает» без указания что должно происходить. Всегда описывай ожидаемое поведение. Шаги предполагающие знание. «Залогинься как администратор». Какой администратор? Какой URL? Какие данные? Отсутствие предусловий. Баги которые происходят только с определёнными данными, определёнными ролями, или после определённых предшествующих действий требуют этого контекста в секции предусловий. Однострочные заголовки. «Баг оплаты зарепорчен». Зарепорчен для какого сценария? Завышение severity. Если называть всё Critical, Critical перестаёт что-либо значить. Резервируй его для потери данных, проблем безопасности, и фич полностью сломанных для всех пользователей. Не убран тестовый мусор. Если шаги воспроизведения создали тестовые данные (нового пользователя, заказ, файл), укажи это чтобы кто-то мог убрать без привлечения администратора базы данных.

FAQ

Нужно ли писать баг-репорты на каждую найденную проблему

Логируй всё что работает не так как должно. Разработчики и product owner'ы могут закрыть или депrioritize, но не могут исправить то о чём не знают. Исключение: то в чём ты не уверен баг ли это. Сначала уточни в комментарии или быстром сообщении.

Что если не могу стабильно воспроизвести баг

Всё равно логируй. Напиши в репорте: «Нестабильный: воспроизведён 3 из 10 попыток. Стабильный триггер не выявлен». Приложи видео одного воспроизведения. Залогированный нестабильный баг лучше незалогированного.

Насколько детальными должны быть шаги воспроизведения

Настолько детальными чтобы разработчик только что пришедший в команду мог воспроизвести без единого вопроса к тебе. Если сомневаешься, ошибись в сторону большей детализации.

Мой баг пометили "by design". Я был неправ

Необязательно. «By design» означает что product owner решил: текущее поведение приемлемо. Это легитимный исход. Важно что ты чётко задокументировал поведение. Если оно вызывает путаницу у пользователей, этот разговор должен происходить до принятия продуктового решения, а не после.

→ See also: Как писать тест-кейсы: формат, примеры и частые ошибки | Что такое ручное тестирование: полное руководство для 2026 года