Как написать хороший баг-репорт?

Помимо выполнения самого тестирования, тестировщику ПО также необходимо заполнять всю необходимую документацию. В частности, это касается баг-репортов, без которых работа специалиста QA практически невозможна на практике.

Вот несколько правил написания качественного баг-репорта:

1. Краткость, но не в ущерб содержательности
   
   На каждый дефект прописывается отдельный баг-репорт. Нужно описать его так, чтобы было четко понятно, в следствие какого процесса возникает баг. При этом от грамотного специалиста QA ждут краткого и качественного описания, а не перечисления абсолютно всех действий (указываем только значимые, чтобы другой человек мог тоже воспроизвести баг).
   
2. Проверить воспроизводимость дефекта
   
   До написания баг-репорта тестировщику ПО необходимо убедиться, что баг действительно имеет место и может быть воспроизведен, а также каким именно путем к нему пришли.
   
3. Правильная структура
   
   Единственного правильного шаблона для написания баг-репорта не существует. Однако есть некоторые повторяющиеся поля для описания бага (атрибуты):
   
   - Заголовок (summary) – суть выявленного бага в кратком формате, описываемая по формуле «что-где-при каких обстоятельствах»;
   - Описание (description) – этапы воспроизведения бага;
   - Фактический/ожидаемый результат (actual/expected result) – сравнение получившегося итога с тем, который требовался;
   - Вложения (attachments) – схема, скриншот или запись;
   - Приоритет (priority) – насколько срочно необходимо исправить (тестировщик оставляет это поле пустым, приоритет выставляет не он);
   - Серьезность (severity) – степень влияния на функционирование: blocker (полностью нарушает работу), critical (значительно), major (нарушает работу, но без серьезных изменений), minor (не влияет на работу).

Подробный разбор качественного написания баг-репортов можно получить на наших курсах по тестированию ПО с нуля!