В мире тестировщиков есть один священный документ, по которому тебя будут судить, помнить и иногда проклинать — баг-репорт. Он может быть твоим союзником и гордостью, а может превратиться в источник боли и коллективной фрустрации. Особенно у разработчиков.
Разбираемся, как писать баг-репорты, которые:
- понятны,
- воспроизводимы,
- вызывают желание чинить, а не сжигать всё к чертям.
Зачем вообще баг-репорт, если можно в чатик кинуть «у меня не работает»?
Вот представь: разработчик видит сообщение «ничего не работает» и начинает гадать:
- Что именно?
- Где?
- На каком устройстве?
- В какой версии?
- А что ты делал до этого?
Это как жалоба в техподдержку уровня «мой компьютер шумит». Помощи — ноль.
Баг-репорт — это структурированное описание проблемы, которое помогает команде воспроизвести и устранить баг. Это твой вклад в качество продукта и, по сути, твой профессиональный след.
Из чего состоит хороший баг-репорт?
1. Заголовок (Title)
Кратко, по делу. Что сломалось и где.
Плохо: «Ошибка»
Хорошо: «[Профиль] Не работает кнопка “Сохранить” при изменении имени»
Формула: [Модуль] + [Что не работает] + [Условие]
2. Окружение (Environment)
Где именно баг проявляется: браузер, версия ОС, тип устройства, тестовая сборка или прод.
Пример:
- Chrome 125.0.6422.112
- Windows 11
- test.staging.site.com
- Аккаунт: user123
3. Предусловия (Preconditions)
Что должно быть заранее. Например: «Пользователь авторизован» или «У товара есть доступные размеры».
4. Шаги воспроизведения (Steps to Reproduce)
Конкретно, пошагово. Как будто ты объясняешь бабушке.
Пример:
- Зайти в личный кабинет
- Изменить имя на любое другое
- Нажать кнопку “Сохранить”
5. Фактический результат (Actual Result)
Что происходит на самом деле. Кратко и без эмоций.
Пример: После нажатия кнопки ничего не происходит, в консоли ошибка 500
6. Ожидаемый результат (Expected Result)
Что должно было произойти, если бы всё было ок.
Пример: Имя пользователя сохраняется, появляется сообщение об успешном изменении
7. Вложения (Attachments)
Скриншоты, видео, логи, консольные ошибки — всё, что поможет увидеть проблему глазами.
Типичные ошибки новичков в баг-репортах
❌ «У меня не работает»
— Что именно? Где? Это не баг-репорт, это крик в пустоту.
❌ «Сломалось!» без скринов, логов и шагов
— Разработчику приходится самому искать проблему. В итоге либо не чинит, либо чинит не то.
❌ Слишком много текста без структуры
— Никто не будет разбирать 2 экрана текста, написанных в духе потока сознания.
❌ Эмоции и оценочные суждения
Пример: «Кнопка тупо не работает, кто это вообще делал?!»
— Так не надо. Ты не в Твиттере.
Лайфхаки для прокачки баг-репортинга
1. Пиши так, как будто баг будет чинить не разработчик, а робот
Максимально чётко, сухо и понятно.
2. Используй шаблон
Во многих системах (Jira, YouTrack, TestRail) можно настроить шаблоны багов. Это дисциплинирует и не даёт забыть важные поля.
3. Тестируй на разных окружениях
Если баг воспроизводится только на Safari в iPhone 11 — это важно! Не обобщай.
4. Сначала воспроизведи, потом пиши
Проверь, точно ли баг стабилен. Вдруг это глюк одной сессии или локальной сборки?
5. Коммуникация — твой друг
Если баг непонятный — напиши в чат разработчику. Возможно, это фича. Возможно, это уже фиксится.
Бонус: чек-лист хорошего баг-репорта
- Понятный заголовок
- Указано окружение (браузер, ОС, устройство)
- Есть предусловия
- Пошаговое описание
- Ясный фактический результат
- Ожидаемое поведение
- Скриншоты или видео
- Без эмоций и домыслов
Пример идеального баг-репорта:
Title: [Профиль] Не работает кнопка «Сохранить» при изменении имени
Environment:
- Windows 11
- Chrome 125.0.6422.112
- staging.site.ru
- Аккаунт user_test_01
Preconditions: Пользователь авторизован, открыт раздел «Профиль»
Steps to Reproduce:
- Перейти в личный кабинет
- Ввести новое имя в поле «Имя»
- Нажать кнопку «Сохранить»
Actual Result: Кнопка не реагирует, в консоли ошибка 500
Expected Result: Имя сохраняется, появляется сообщение «Изменения сохранены»
Attachments: Видеозапись экрана, скриншот консоли
Важно: баг-репорт — это лицо QA
Ты можешь быть очень внимательным тестировщиком, но если твои баги описаны кое-как, у команды будет ощущение, что ты всё делаешь «на глазок».
Хороший баг-репорт — это знак уважения к команде, к проекту и к своей профессии. А ещё — это один из ключевых аргументов на собеседованиях, когда просят показать примеры своей работы.
Пиши баги так, чтобы их хотелось чинить, а не забыть в backlog до лучших времён.
Хочешь больше примеров и фидбек на свои баг-репорты? Подписывайся на канал — будем разбирать, делиться фейлами и становиться лучше вместе.