Pepelen
Тестирование ПО: профессия QA с нуля

Lesson

Урок 2. Баг-репорт: что должно быть и как писать понятно

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

1 / 5

Поля баг-репорта и типичные ошибки

Как выглядит хороший баг-репорт

Баг-репорт — это документ, который помогает разработчику воспроизвести дефект и исправить его. Если репорт написан плохо, разработчик потратит время на уточнение деталей или вовсе не сможет воспроизвести баг. Обязательные поля баг-репорта: Заголовок — краткое и информативное описание проблемы (что, где, при каком условии). Шаги воспроизведения — пронумерованные действия, которые приводят к дефекту. Фактический результат — что произошло на самом деле. Ожидаемый результат — что должно было произойти согласно требованиям. Окружение — ОС, браузер, версия приложения. Severity (серьёзность) — насколько дефект влияет на систему. Priority (приоритет) — насколько срочно его нужно исправить. Вложения — скриншоты, видео, логи. Типичные ошибки новичков: неинформативный заголовок («кнопка не работает» — какая кнопка? не работает как?); отсутствие шагов воспроизведения («зашёл и сломалось»); нет ожидаемого результата; репорт «не баг, а несоответствие моим ожиданиям» — без сверки с требованием нельзя утверждать, что это баг. Пример плохого заголовка: «Что-то не так с формой». Пример хорошего: «Кнопка 'Оформить заказ' неактивна при заполненной корзине и корректных данных доставки (Chrome 125, Windows 11)». Хороший заголовок отвечает на вопросы: ЧТО случилось, ГДЕ, ПРИ КАКОМ УСЛОВИИ.
Lesson notes
Как выглядит хороший баг-репорт
Баг-репорт — это документ, который помогает разработчику воспроизвести дефект и исправить его. Если репорт написан плохо, разработчик потратит время на уточнение деталей или вовсе не сможет воспроизвести баг. Обязательные поля баг-репорта: Заголовок — краткое и информативное описание проблемы (что, где, при каком условии). Шаги воспроизведения — пронумерованные действия, которые приводят к дефекту. Фактический результат — что произошло на самом деле. Ожидаемый результат — что должно было произойти согласно требованиям. Окружение — ОС, браузер, версия приложения. Severity (серьёзность) — насколько дефект влияет на систему. Priority (приоритет) — насколько срочно его нужно исправить. Вложения — скриншоты, видео, логи. Типичные ошибки новичков: неинформативный заголовок («кнопка не работает» — какая кнопка? не работает как?); отсутствие шагов воспроизведения («зашёл и сломалось»); нет ожидаемого результата; репорт «не баг, а несоответствие моим ожиданиям» — без сверки с требованием нельзя утверждать, что это баг. Пример плохого заголовка: «Что-то не так с формой». Пример хорошего: «Кнопка 'Оформить заказ' неактивна при заполненной корзине и корректных данных доставки (Chrome 125, Windows 11)». Хороший заголовок отвечает на вопросы: ЧТО случилось, ГДЕ, ПРИ КАКОМ УСЛОВИИ.
Урок 2. Баг-репорт: что должно быть и как писать понятно — Тестирование ПО: профессия QA с нуля