Идеальный баг-репорт: прикладные правила

Поиск багов и их описание составляет суть работы тестировщика. Ошибки заводятся на стадии разработки проекта. Их необходимо выявить и исправить, чтобы пользователь получил качественный конечный продукт. Эффективная регистрация найденного бага — результат цикла тестирования в проекте и помощь в разработке. В этой статье мы сосредоточимся на том, как написать хорошие баг-репорты.

Описание 

Описание должно быть четким и кратким. Команда разработчиков должна понять его без затруднений. Минимум слов — максимум информативности.

Шаги воспроизведения 

Шаги для воспроизведения бага должны быть ясными. Опишите действия воспроизведения ошибки максимально скрупулёзно и точно. У человека из команды разработки, который будет читать ваш репорт и исправлять ошибку, баг должен воспроизвестись без проблем.

Среда 

Не забывайте о точном описании тестовой среды. Иногда случается, что разработчику, которому поручено исправить ошибку, трудно её воспроизвести, потому что он не получил исчерпывающую информацию, в какой среде произошла ошибка в проекте. Описывая тестовую среду уточните платформу и операционную систему. Это облегчит  воспроизведение ошибки и позволит избавиться от ненужных хлопот.

Суть проблемы 

Избегайте внесения ненужных подробностей при написании баг-репорта и старайтесь представить ошибку точно, используя фактическое описание. При описании дефекта не надо помещать в баг-репорт ненужную и неактуальную информацию.

Вложения 

При описании бага прикрепите его скриншот. Скрин поможет представить четкую картину дефекта. Он более информативен чем всё остальное описание, служит доказательством обнаружения бага. 

Серьезность и приоритет 

Назначьте дефекту соответствующий уровень серьезности и приоритета (Priority & Severity), чтобы группа разработчиков могла понять его опасность и отнестись к нему соответственно. Серьёзность и приоритет во многих случаях различны. Дефект с меньшей степенью серьезности может иметь высокий приоритет и наоборот.

Каждому багу — свой репорт 

Избегайте описания многочисленных обнаруженных багов одним репортом. Все ошибки должны быть заведены отдельно, чтобы команде разработчиков было удобно решать каждую из проблем надлежащим образом .

Уникальность 

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

Знать требования проекта 

Тестировщики часами отыскивают дефект, но командой разработчиков он как ошибка не рассматривается. Причина — разработчик создаёт проект в соответствии с требованиями, а тестировщик не понимая задачи сообщает о дефекте. Теряется время как команды разработчиков, так и тестировщиков. Чтобы баг не отклоняли, приступать к тесту нужно только после тщательного анализа требований. Не тестируйте непонятно что.

Следите за грамотностью 

Избегайте простых ошибок. Неграмотно составленный с грамматическими и орфографическими ошибками баг-репорт не прибавит плюсов вашей работе.

Будьте точны и понятны 

Используйте простые слова, обращаясь к команде разработчиков или к заказчику, для лучшего понимания ими проблемы.