Без сомнения, хороший баг-репорт – это документ высокого качества. Написание хорошего баг-репорта важная задача, ведь именно баг-репорт будет основной точкой коммуникации между тестировщиком, разработчиком и менеджером проекта. Хорошо написанный баг-репорт не только создаст хорошие взаимоотношения между вами и разработчиками, но и сохранит ресурсы компании на работу с ним.

Помимо прочего, хороший баг-репорт должен содержать верно написанный Summary. Как правило, Summary состоит из 150 символов или менее. Важно убедиться, что Summary полностью отвечает на вопросы: что есть проблема? где и когда проблема воспроизводится?

Также важно помнить, что при составлении Summary необходимо точно указывать суть проблемы, – другими словами, что именно НЕ ТАК работает. А потому, не нужно использовать слова, которые опишут проблему абстрактно, без конкретизации, к примеру, ничего не происходит, некорректно/корректно отображается, неверно/верно работает и т.д.

Примеры ошибочного описания:

1. Ничего не происходит после перехода на страницу.
2. Некорректно отображается раздел «О компании».

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

Работа программиста и тестировщика – комплексный и взаимосвязанный процесс. Очень часто баги, заведенные тестировщиком, «на ходу» исправляются разработчиками. Поэтому, «непонятно» описанный баг приводит к большей затрате времени на его понимание и воспроизведение и, как следствие, потере бюджетных средств.

Можно вывести некий алгоритм действий при написании хорошего Summary:

1. Понять суть проблемы! Перед написанием Summary необходимо, чтобы у тестировщика было четкое понимание того, в чем заключается ошибка.
2. Описать ошибку детально, учитывая все подробности ее воспроизведения.
3. Убрать из сформулированного все лишнее, например, условия, не обязательные для существования ошибки,  уточнить важные детали.
4. Построить предложение по принципу «что? где? когда?».
5. Проверить предложение на соответствие грамматическим правилам языка, на котором написано Summary.
6. Сократить длину предложения, в случае если оно получилось слишком длинным. Можно использовать синонимы, сокращения или общепринятые аббревиатуры.

Исходя из вышесказанного, приведем примеры правильного оформления Summary:

1. Отображается пустая страница в разделе «Наши проекты» после нажатия на кнопку «Наши проекты».
2. Кнопки навигации не отображаются в разделе «О компании».  

Но, безусловно, в процессе тестирования, иногда обнаруживаются баги, которые явно описать невозможно, например:

Приложение «Калькулятор» производит неверные вычисления при различных арифметических действиях.

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

Кроме этого, мы можем более подробно описать данную проблему в расширенном описании.

Например, в теме и фактическом результате мы указываем «Сообщение об ошибке не показывается в поле ввода почтового адреса при вводе невалидных значений».

А в описании указываем, что данная ситуация воспроизводится при попытке подтверждения с пустым полем, при вводе почтового адреса без символа «@» или без использования доменного имени.

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

Также не забываем, что при заведении баг-репортов принято в фактическом результате указывать то же самое, что и в Summary, а в Ожидаемом – что должно отображаться по мнению тестировщика. При описании результатов используется то же правило, что и при оформлении поля Summary (по принципу Что? Где? Когда?).

Примеры правильного оформления Ожидаемого результата:

1. Отображается контент в разделе «Наши проекты» после нажатия на кнопку «Наши проекты».
2. Отображаются кнопки навигации в разделе «О компании».  

Часто возникает ситуация, что при составлении чек-листа допускается использование некорректных слов, а при описании бага – нет.

Разница заключается в том, что при составлении чек-листа можно ссылаться на предоставленные макеты продукта. Но часто в процессе разработки дизайн приложения или сайта может изменяться, поэтому конкретизация местонахождения секции только будет идти во вред.

Например, описание «Секция «Продукты» отображается в правой верхней стороне экрана».

Если после этого ее переместили в левую сторону, то тестировщик будет считать это багом.

А без конкретизации достаточно будет свериться с актуальным макетом для подтверждения правильности расположения секции. Поэтому описание «Секция «Продукты» корректно отображается на экране» допустимо.

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

В баг-репорте нужно точно указать проблему на момент тестирования.

Описание «Секция «Продукты» отображается некорректно на странице» не описывает сути проблемы.

Задача хорошего баг-репорта – описать проблему максимально полно и понятно не только для другого тестировщика, но и человека, совершенно не знакомого с продуктом

Поэтому здесь важно указать, в чем именно проявляется «некорректность» поведения

Как один из вариантов, можно указать, что «Секция «Продукты» обрезается на странице границами экрана/окна браузера»

Все будет зависеть от конкретной ситуации, в какой воспроизводится баг.

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

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

Вот еще один пример «неправильного» описания бага:

«Оглавление страницы написано неправильно»

В чем именно проявляется «неправильность» данного бага? Из темы абсолютно непонятно, в чем заключается проблема. То ли предложение выходит за границы блока, то ли оно обрезано или написано в неправильном формате, то ли содержит грамматические или лексические ошибки.

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

Подводя итоги, необходимо понимать, что качество оформленного баг-репорта отражает профессиональный уровень тестировщика и то, насколько грамотно он будет оформлен, – непосредственно повлияет на конечный результат на проекте. Важно различать ситуации, в которых использование «некорректных» слов допустимо, а в которых - нет. Лучший способ – посмотреть на заведенный баг со стороны человека, который будет его читать и пытаться воспроизвести. Не нужно забывать, что нахождение бага – это только часть выполненной работы. Правильность его оформления – не менее важно.