Как написать баг-репорт
Тестировщик пишет: «сломана оплата». Разработчику всё ещё нужно спросить, какая учётная запись использовалась, какой товар был выбран, на каком билде и что должно было произойти. В отчёте есть тревога, но нет пути обратно к наблюдению.
Разбираясь, как написать баг-репорт, сохраните короткую полезную историю: где начинается поведение, какое действие меняет состояние, что произошло на самом деле, что ожидалось и какое доказательство сможет проверить другой человек.
Как написать баг-репорт через короткий воспроизводимый сценарий
Начните с короткого заголовка, где названы объект, условие и видимый сбой. Затем убирайте шаги, пока дефект не перестанет воспроизводиться. Короткий сценарий помогает проверить утверждение, не проходя через несвязанную настройку.
Если нужны особая учётная запись, данные или флаг, укажите их в окружении или предусловиях. Не прячьте единственный ключ воспроизведения в скриншоте.
Разделите ожидаемое поведение и наблюдение
Запишите, что продукт должен сделать на основании требования, договорённости или явно названного действия пользователя. Затем отдельно опишите фактический результат. Разница между ними и есть история дефекта. Слова «не работает» её не заменяют.
Если требование неясно, обозначьте отчёт как вопрос или приложите недостающее решение. Баг-репорт не должен превращать предположение в факт.
Добавьте контекст, который меняет результат
- Билд, окружение, браузер или устройство.
- Роль учётной записи, состояние данных и флаги.
- Частота или условия появления проблемы.
- Сетевое, консольное или API-доказательство, если оно сужает поиск причины.
Оставляйте только контекст, влияющий на воспроизведение или приоритет. Длинный рассказ об окружении мешает заметить важное различие.
Выбирайте доказательства, которыми можно пользоваться
Скриншот показывает итоговое состояние, но редко объясняет путь. Добавьте короткую запись экрана или трассировку запроса, если важен момент времени, и удалите персональные данные. Для логов укажите нужный момент или идентификатор связи вместо огромного неразмеченного файла.
Замыкайте цикл после первого сообщения
Если разработчик задал вопрос, добавьте ответ и новое доказательство в отчёт. Если проблема не воспроизвелась, запишите, что именно проверялось, а не меняйте формулировку молча. После исправления повторите короткий путь и один соседний риск.
Хороший отчёт сокращает расстояние между наблюдением и решением команды. Ему не нужны громкие слова, чтобы сделать дефект рабочим.
Как написать баг-репорт: сделайте одно наблюдение воспроизводимым
Возьмите один неожиданный результат небольшой формы или API. До добавления скриншота напишите заголовок, исходное состояние, минимальные шаги, ожидаемый и фактический результат.
Проверьте, сможет ли человек с тем же билдом и данными воспроизвести проблему только по тексту. Добавьте недостающий контекст и удалите всё, чем не стоит делиться.
Завершите границей: частота, затронутый путь и то, что не проверялось. Так отчёт не превратится в широкое утверждение обо всех пользователях.
Вопросы перед следующим шагом
- Какой самый короткий сценарий всё ещё показывает проблему?
- Какое наблюдение отделяет ожидаемое от фактического?
- Какой контекст влияет на воспроизведение или приоритет?
- Что нужно удалить перед передачей доказательств?
Повторяйте управление дефектами и другие темы CTFL с помощью вопросов и объяснений.
Подробнее об ISTQB Quiz →