Баг-репорт это главный рабочий продукт тестировщика. Хороший репорт позволяет разработчику воспроизвести дефект без единого вопроса. Плохой съедает время всей команды. На собеседовании часто дают «плохой» баг-репорт и просят найти, что в нём не так.
Поля баг-репорта
- Заголовок: где, что, при каких условиях.
- Окружение: стенд, версия сборки, браузер и версия, ОС, устройство.
- Предусловия: учётка, роль, данные, настройки до начала шагов.
- Шаги воспроизведения: конкретные, с данными.
- Фактический результат: что произошло.
- Ожидаемый результат: что должно было произойти и откуда это известно.
- Вложения: скриншот, видео, ошибка из Console, ответ сервера, лог.
- Серьёзность, приоритет, компонент, воспроизводимость.
Заголовок
Формула: где, что, при каких условиях.
Плохо: Не работает промокод!!!
Плохо: Баг в корзине
Хорошо: Корзина: промокод SALE10 не применяется к товарам со скидкой
Заголовок должен находиться поиском и быть понятным без открытия репорта. Эмоции и восклицательные знаки информации не добавляют.
Шаги
Шаги должен повторить любой человек, не знающий контекста:
Предусловия: пользователь user1@test.ru, корзина пуста
1. Добавить в корзину «Чайник Х» (артикул 1042), 2 шт.
2. В поле промокода ввести SALE10
3. Нажать «Применить»
Не пиши «попробовать промокод» или «как обычно». Не смешивай шаги и результат: для результата отдельные поля. Убери лишние шаги: найди минимальный сценарий.
Фактический и ожидаемый результат
Дефект это разница между ними, поэтому нужны оба. Для денег пиши числа и формулу:
Фактический: итог 3000 ₽, скидка не применена
Ожидаемый: итог 2700 ₽ (2 × 1500 ₽ − 10% по условиям SALE10, см. страницу акции)
«Сумма неправильная, должна быть правильная» не описывает ничего.
Вложения, которые помогают
- Для вёрстки: скриншот с выделенной проблемой.
- Для веба: запрос и ответ из вкладки Network, ошибка из Console, иногда HAR-файл.
- Для мобильных падений: стек-трейс из logcat или из системы сбора крешей.
- Для плавающих багов: время попыток, чтобы найти записи в логах сервера.
Правила
- Один дефект на репорт. У каждого своя серьёзность и судьба.
- Проверь дубли перед заведением.
- Воспроизводимость числом: «3 из 10 попыток», а не «иногда».
- Никаких секретов и персональных данных. Пароли, токены, номера карт клиентов, ФИО и телефоны клиентов в общий трекер не кладут. HAR и cURL содержат куки и токены: перед отправкой вычищай. Клиента идентифицируй по внутреннему ID.
- Честная серьёзность. Двойное списание денег не может быть Minor.
Как читать чужой баг-репорт на собесе
Пройди по полям сверху вниз и для каждого спроси: хватит ли этого, чтобы воспроизвести и проверить исправление? Типичные находки:
- общий заголовок;
- нет окружения или версии сборки;
- нет конкретных данных в шагах;
- «не работает» вместо фактического результата;
- ожидаемое без источника;
- несколько дефектов в одном репорте;
- неверная серьёзность;
- утечка персональных данных.
Частые ошибки
- Писать репорт для себя, а не для человека без контекста.
- Прикладывать только скриншот там, где важен ответ сервера.
- Ждать, пока плавающий баг станет стабильным, и не заводить его.
- Вставлять в трекер реальные данные клиента с прода.
Что спросят на собесе
- Из каких полей состоит баг-репорт?
- Как написать хороший заголовок?
- Что не так с этим баг-репортом? (дадут текст)
- Как оформить плавающий баг?
- Что нельзя прикладывать к баг-репорту?