Создание баг-репорта
Создание баг-репорта
Нашёл баг — половина дела. Вторая половина — описать его так, чтобы разработчик мог воспроизвести, понять и исправить. Плохо написанный баг-репорт теряется в беклоге или возвращается с комментарием «не воспроизводится». В этом уроке разберём, как писать баг-репорты, которые действительно помогают.
Зачем нужен баг-репорт
Баг-репорт решает две задачи:
- Воспроизводимость — разработчик должен увидеть ту же ошибку, что видел ты
- Коммуникация — все в команде понимают: что сломано, насколько это критично, кто этим занимается
Хороший баг-репорт — это полная, точная и лаконичная информация. Лишних слов нет, нужных — достаточно.
Обязательные поля баг-репорта
ID
Уникальный номер, присваивается автоматически в баг-трекере (Jira, YouTrack, GitHub Issues). Используется для ссылок: «исправить BUG-142 до релиза».
Заголовок (Title / Summary)
Самое важное поле. Читается первым. Должен ответить на вопрос «что именно сломано и при каком условии».
Плохой заголовок: «Сайт не работает»
Хороший заголовок: «Кнопка "Войти" не реагирует на клик при незаполненном поле Email в Firefox 120»
Формула хорошего заголовка: [Что] + [При каком условии] + [Где/В чём]
Шаги воспроизведения (Steps to Reproduce)
Пронумерованная последовательность действий, которая приводит к ошибке. Каждый шаг — одно конкретное действие.
Требования к шагам:
- Начинай с открытия нужной страницы
- Указывай точные данные (что вводить, на что нажимать)
- Пиши только те шаги, которые нужны для воспроизведения
Ожидаемый результат (Expected Result)
Что должно было произойти по логике работы приложения.
Фактический результат (Actual Result)
Что произошло на самом деле. Описывай конкретно: текст ошибки, поведение элемента, что появилось на экране.
Окружение (Environment)
| Поле | Пример |
|---|---|
| ОС | Windows 11, macOS Ventura 13.4 |
| Браузер | Chrome 120.0.6099.109 |
| Версия приложения | v2.3.1 / build #4521 |
| Устройство | Desktop / iPhone 14 Pro |
| URL | https://staging.example.com/login |
Один и тот же баг может воспроизводиться только в определённом браузере или ОС — без этих данных разработчик будет искать проблему там, где её нет.
Вложения (Attachments)
- Скриншот — обязательно, если баг визуальный
- Видео — для трудно воспроизводимых или анимационных багов
- Логи консоли — при ошибках JavaScript (F12 → Console)
- HAR-файл — при сетевых проблемах
Severity (критичность)
Severity — насколько сильно баг влияет на работу системы. Определяет тестировщик.
| Уровень | Описание | Пример |
|---|---|---|
| Critical | Система не работает, нет обходного пути | Приложение падает при входе, потеря данных |
| Major | Важная функциональность не работает | Нельзя оформить заказ, оплата не проходит |
| Minor | Функциональность работает, но с проблемами | Неверное сообщение об ошибке, некорректная сортировка |
| Trivial | Косметический дефект, не влияет на работу | Опечатка в тексте, незначительное смещение элемента |
Priority (приоритет)
Priority — в какую очередь исправлять. Определяет менеджер или команда, исходя из бизнес-потребностей.
| Уровень | Описание |
|---|---|
| High | Исправить немедленно, до релиза |
| Medium | Исправить в ближайшем спринте |
| Low | Исправить когда будет время |
Чем отличаются Severity и Priority
Это не одно и то же! Путать их — классическая ошибка.
Пример 1: Опечатка в имени CEO на главной странице.
Severity = Trivial (технически незначительно), Priority = High (репутационный риск, нужно исправить срочно).
Пример 2: Приложение падает при загрузке файла формата .bmp.
Severity = Critical (краш), Priority = Low (никто не использует .bmp, нет срочности).
Пример хорошего баг-репорта
ID: BUG-234
Заголовок: Форма регистрации принимает пустой email при нажатии Enter
Severity: Major
Priority: High
Окружение:
ОС: Windows 11
Браузер: Chrome 120.0.6099.109
URL: https://staging.myapp.com/register
Шаги воспроизведения:
1. Открыть страницу /register
2. В поле «Имя» ввести: Иван
3. Поле «Email» оставить пустым
4. В поле «Пароль» ввести: Test1234!
5. Нажать клавишу Enter (не кнопку «Зарегистрироваться»)
Ожидаемый результат:
Форма не отправляется. Под полем «Email» появляется ошибка
«Введите email».
Фактический результат:
Форма отправляется с пустым email. В консоли ошибка:
POST /api/register 500 Internal Server Error.
Пользователь видит белый экран.
Вложения: [скриншот консоли], [скриншот белого экрана]
Пример плохого баг-репорта
Заголовок: Регистрация не работает
Шаги: Попробовал зарегистрироваться — ничего не произошло.
Ожидаемый результат: Должно работать.
Фактический результат: Не работает.
Что не так:
- Нет точных шагов — как разработчику воспроизвести?
- Нет окружения — в каком браузере?
- Неясно, что именно сломано
- Нет вложений
Частые ошибки при написании баг-репортов
«Не воспроизводится» — шаги написаны неточно или пропущены предусловия. Решение: добавь предусловия и проверь шаги, пройдя их заново.
Несколько багов в одном репорте — «кнопка не работает и текст неправильный» — это два разных тикета.
Эмоциональные описания — «ужасная ошибка», «сайт сломан» — лишнее. Только факты.
Нет ожидаемого результата — разработчик не знает, что считается правильным поведением.
Путаница Severity и Priority — назначай severity по техническому влиянию, priority — по бизнес-важности.
Что мы запомним
- Баг-репорт нужен для воспроизводимости и коммуникации
- Обязательные поля: заголовок, шаги, ожидаемый и фактический результат, окружение, severity, priority
- Severity — техническое влияние (Critical/Major/Minor/Trivial), задаёт тестировщик
- Priority — срочность исправления (High/Medium/Low), задаёт команда
- Severity и Priority — разные понятия, не путай их
- Хороший заголовок: «Что + При каком условии + Где»