Как написать хороший баг-репорт. Советы от Senior QA

Долго думал, какую статью написать. Ну конечно же статья должна быть о тестировании. И мне пришла мысль написать о проблеме, с которой сам сталкивался в начале своей работы тестировщиком. И это, как вы уже поняли: «Как написать хороший баг репорт?».

Зачем нужен хороший отчет об ошибке?

Все очень просто, если ваш отчет об ошибке будет корректен, то шансы на её исправление становятся выше. Таким образом, исправление ошибки зависит от того, насколько эффективно вы уведомите о ней.

«Смысл написания отчета о проблеме (отчета об ошибках) состоит в том, чтобы исправить ошибки»
Сэм Канер

Советы по написанию правильного отчета об ошибке

Воспроизводимость: если ваша ошибка не воспроизводится, она никогда не будет исправлена.

Необходимо четко указать шаги для воспроизведения ошибки. Баг нужно описать шаг за шагом.

Как идеальный кейс можно использовать: «Воспроизведите ошибку три раза, прежде чем писать отчет об ошибке» .

Описание ошибки: писать конкретно и на самом деле.

Постарайтесь описать проблему минимальным количеством слов. Не описывать несколько проблем, даже если они схожи. К каждой проблеме свой отчет.

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

Повторяющиеся баги: это настоящая «балласт» в цикле тестирования.

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

Ответить на 2 вопроса: “Как?” и “Где”?” В отчете должно быть четко указано, как именно была проведена проверка и где произошел дефект. Человек, который будет читать вашу ошибку, должен легко его воспроизвести и повторно не выяснять у вас отсутствующие детали.

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

Визуальное доказательство/скриншот: иногда картинка стоит больше тысячи слов.

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

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

Шаги для воспроизведения: всегда предполагайте, что у вашего разработчика нет представления о найденной вами ошибке — как он ее воспроизведет?

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

Если проблема воспроизводится не каждый раз, вы можете включить коэффициент воспроизводимости (например, 5/10 воспроизведения ошибки).

Окружающая среда. Веб-сайты и приложения могут вести себя по-разному в зависимости от среды.

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

Начальный URL.  Одним из важных элементов, о которых легко забывают, является исходный URL. Это поможет разработчикам быстрее ориентироваться, что сэкономит всем много времени.

Серьезность и приоритет ошибки. Определив серьезность или приоритет проблемы в своем отчете об ошибке, разработчик понимает, как быстро ошибка должна быть исправлена.

Надеюсь, эти советы будут вам полезны.

Этот текст с личного блога автора, опубликованный с его разрешения.