Отчет о дефекте (defect report): Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. (IEEE 829)
«Смысл написания отчета о проблеме (отчета об ошибке) состоит в том, чтобы исправить ошибки» - Джем Канер. Если тестировщик неправильно сообщает об ошибке, то программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима. Или потратит кучу лишнего времени на то, чтобы сделать вашу работу за вас. Едва ли такой тестировщик будет выгоден бизнесу, приятен коллегам и долго задержится на своем месте.
Главное при написании отчета - он должен быть сразу и однозначно понят читающим, а дефект однозначно воспроизведен по указанным шагам в указанном окружении.
Основные поля баг-репорта:
Дополнительные:
В случаях использования TMS поля будут настроены лидом/менеджером и в зависимости от размеров проекта могут быть пункты вроде milestone, epic, feature и т.п.
Помимо прочего, баг-репорты могут создаваться не только тестировщиками, но и любыми членами команды, приходить от пользователей или техподдержки. Во втором случае необходимо будет воспроизвести ошибку, составить баг-репорт по всем правилам или дополнить присланный, затем провести ретроспективу на тему того, как ошибка попала в прод и как этого избежать в будущем.
Несколько ключевых моментов, которые следует учитывать при написании отчета об ошибке:
Источники:
Доп. материал:
Документирование возникновения, характера и состояния дефекта. [Глоссарий ISTQB]
Включает описание ситуации или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Поле | Описание |
---|---|
Заголовок (Summary) | Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. |
Проект (Project) | Название тестируемого проекта |
Компонент приложения (Component) | Название части или функции тестируемого продукта |
Номер версии (Version) | Версия на которой была найдена ошибка |
Критичность (Severity) | Наиболее распространена пятиуровневая система градации серьезности дефекта: • S1 Блокирующий (Blocker) • S2 Критический (Critical) • S3 Значительный (Major) • S4 Незначительный (Minor) • S5 Тривиальный (Trivial) |
Приоритет (Priority) | Приоритет дефекта: • P1 Высокий (High) • P2 Средний (Medium) • P3 Низкий (Low) |
Статус (Status) | Статус бага. Зависит от используемой процедуры и жизненного цикла бага. Например: • Новый • Открыт • Закрыт |
Автор (Author) | Создатель баг репорта |
Назначен на (Assigned To) | Имя сотрудника, назначенного на решение проблемы |
Описание (Description) | Окружение (Environment): Информация об окружении, на котором был найден баг. Операционная Система, Service Pack; для WEB тестирования — имя и версия браузера и т.д. Шаги воспроизведения (Steps to Reproduce): Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. Фактический Результат (Actual Result): Результат, полученный после прохождения шагов к воспроизведению. Ожидаемый результат (Expected Result): Ожидаемый правильный результат |
Дополнения | Прикрепленный файл (Attachment): Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы |
https://www.softwaretestinghelp.com/how-to-write-good-bug-report/
https://testlio.com/blog/the-ideal-bug-report/
https://testit.software/blog/post/kak-pravilno-oformit-bag-report