Без сомнения, хороший баг-репорт – это документ высокого качества. Написание хорошего баг-репорта важная задача, ведь именно баг-репорт будет основной точкой коммуникации между тестировщиком, разработчиком и менеджером проекта. Хорошо написанный баг-репорт не только создаст хорошие взаимоотношения между вами и разработчиками, но и сохранит ресурсы компании на работу с ним.
Помимо прочего, хороший баг-репорт должен содержать верно написанный Summary. Как правило, Summary состоит из 150 символов или менее. Важно убедиться, что Summary полностью отвечает на вопросы: что есть проблема? где и когда проблема воспроизводится?
Также важно помнить, что при составлении Summary необходимо точно указывать суть проблемы, – другими словами, что именно НЕ ТАК работает. А потому, не нужно использовать слова, которые опишут проблему абстрактно, без конкретизации, к примеру, ничего не происходит, некорректно/корректно отображается, неверно/верно работает и т.д.
Примеры ошибочного описания:
- Ничего не происходит после перехода на страницу.
- Некорректно отображается раздел «О компании».
При описании бага, таким образом, совершенно непонятна суть и, соответственно, определить, на что следует обратить внимание и что именно необходимо исправить будет сложно.
Работа программиста и тестировщика – комплексный и взаимосвязанный процесс. Очень часто баги, заведенные тестировщиком, «на ходу» исправляются разработчиками. Поэтому, «непонятно» описанный баг приводит к большей затрате времени на его понимание и воспроизведение и, как следствие, потере бюджетных средств.
Можно вывести некий алгоритм действий при написании хорошего Summary:
- Понять суть проблемы! Перед написанием Summary необходимо, чтобы у тестировщика было четкое понимание того, в чем заключается ошибка.
- Описать ошибку детально, учитывая все подробности ее воспроизведения.
- Убрать из сформулированного все лишнее, например, условия, не обязательные для существования ошибки, уточнить важные детали.
- Построить предложение по принципу «что? где? когда?».
- Проверить предложение на соответствие грамматическим правилам языка, на котором написано Summary.
- Сократить длину предложения, в случае если оно получилось слишком длинным. Можно использовать синонимы, сокращения или общепринятые аббревиатуры.
Исходя из вышесказанного, приведем примеры правильного оформления Summary:
- Отображается пустая страница в разделе «Наши проекты» после нажатия на кнопку «Наши проекты».
- Кнопки навигации не отображаются в разделе «О компании».
Но, безусловно, в процессе тестирования, иногда обнаруживаются баги, которые явно описать невозможно, например:
Приложение «Калькулятор» производит неверные вычисления при различных арифметических действиях.
В таком случае, достаточно сложно определить, в чем именно баг. Тестировщику лишь видно, что полученный результат явно отличается от ожидаемого. Потому, в таких случаях, баг описывается в «глобальном» смысле. Но однозначно понятно, что проблема скрыта в какой-то части кода, которая влияет на конечный результат. Потому, в таком баге мы и допускаем использование тех самых «запрещенных слов».
Кроме этого, мы можем более подробно описать данную проблему в расширенном описании.
Например, в теме и фактическом результате мы указываем «Сообщение об ошибке не показывается в поле ввода почтового адреса при вводе невалидных значений».
А в описании указываем, что данная ситуация воспроизводится при попытке подтверждения с пустым полем, при вводе почтового адреса без символа «@» или без использования доменного имени.
Таким образом мы не удлиняем тему бага, но в то же время уточняем, в каких условиях баг воспроизводится.
Также не забываем, что при заведении баг-репортов принято в фактическом результате указывать то же самое, что и в Summary, а в Ожидаемом – что должно отображаться по мнению тестировщика. При описании результатов используется то же правило, что и при оформлении поля Summary (по принципу Что? Где? Когда?).
Примеры правильного оформления Ожидаемого результата:
- Отображается контент в разделе «Наши проекты» после нажатия на кнопку «Наши проекты».
- Отображаются кнопки навигации в разделе «О компании».
Часто возникает ситуация, что при составлении чек-листа допускается использование некорректных слов, а при описании бага – нет.
Разница заключается в том, что при составлении чек-листа можно ссылаться на предоставленные макеты продукта. Но часто в процессе разработки дизайн приложения или сайта может изменяться, поэтому конкретизация местонахождения секции только будет идти во вред.
Например, описание «Секция «Продукты» отображается в правой верхней стороне экрана».
Если после этого ее переместили в левую сторону, то тестировщик будет считать это багом.
А без конкретизации достаточно будет свериться с актуальным макетом для подтверждения правильности расположения секции. Поэтому описание «Секция «Продукты» корректно отображается на экране» допустимо.
Не нужно сравнивать чек-лист и баг-репорт по правильности описания. Это разные документы, которые выполняют свои поставленные задачи. То, что работает для одного, совершенно недопустимо для другого. Задача чек-листа – описать поведение максимально кратко.
В баг-репорте нужно точно указать проблему на момент тестирования.
Описание «Секция «Продукты» отображается некорректно на странице» не описывает сути проблемы.
Задача хорошего баг-репорта – описать проблему максимально полно и понятно не только для другого тестировщика, но и человека, совершенно не знакомого с продуктом
Поэтому здесь важно указать, в чем именно проявляется «некорректность» поведения
Как один из вариантов, можно указать, что «Секция «Продукты» обрезается на странице границами экрана/окна браузера»
Все будет зависеть от конкретной ситуации, в какой воспроизводится баг.
Опять же, как указано выше, есть допустимые варианты, когда перечисление некорректных значений занимает много места, и их лучше вынести в расширенное описание бага. В таком случае можно использовать «некорректные» слова.
Но в других ситуациях нужно все-таки конкретизировать проблему.
Вот еще один пример «неправильного» описания бага:
«Оглавление страницы написано неправильно»
В чем именно проявляется «неправильность» данного бага? Из темы абсолютно непонятно, в чем заключается проблема. То ли предложение выходит за границы блока, то ли оно обрезано или написано в неправильном формате, то ли содержит грамматические или лексические ошибки.
Баг – не головоломка, которую должен решать заказчик. Отличный пример бага – когда заказчику даже не нужно смотреть скриншот или видео для понимания проблемы.
Подводя итоги, необходимо понимать, что качество оформленного баг-репорта отражает профессиональный уровень тестировщика и то, насколько грамотно он будет оформлен, – непосредственно повлияет на конечный результат на проекте. Важно различать ситуации, в которых использование «некорректных» слов допустимо, а в которых - нет. Лучший способ – посмотреть на заведенный баг со стороны человека, который будет его читать и пытаться воспроизвести. Не нужно забывать, что нахождение бага – это только часть выполненной работы. Правильность его оформления – не менее важно.