3 плохих привычки при составлении баг-репорта

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

Инструменты управления дефектами не гарантируют качество. Это лишь передовые методы, которые в ряде случаев спасают положение.

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

#1) Лень

Люди не спешат прикладывать максимальные усилия.

Такой процесс трекинга дефектов применяется в большинстве команд тестировщиков:

Вначале руководитель тестирования проводит проверку, которая предусматривает подтверждение:

•             Обоснованности — действительно ли это баг?
•             Завершенности — заголовок, шаги, данные, скриншоты и пр.
•             Дубликатов
•             Воспроизводимости багов… и т.д.

«Я опишу проблему так, как считаю нужным, и в случае чего руководитель QA перепроверит и решит, насколько дефект следует считать таковым/закрытым или нет». Подобные подходы зачастую оказываются неэффективными, главным образом потому, что руководитель отдела QA не может дать 100% гарантии. Более того, некоторые клиенты заключают соглашения об уровне предоставления услуги (SLA), в которых предусмотрен допустимый уровень недействительных дефектов, превышение которого влечет за собой штраф.

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

#2) Спешка

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

Система позволяет вписать дату рождения пациента с помощью календаря.

Но есть один нюанс. Если выбрать дату 31-марта-1983, ее позже можно будет заменить, скажем, на «31-февраля-1983».

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

Обратите внимание на возраст и дату рождения на скриншоте.

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

•             Это дефект.
•             Это воспроизводимый дефект (в других условиях).
•             Это не дубликат (уточнить у своей команды для подтверждения).
•             Вам известно детальное описание проблемы.
•             Вам известны точные шаги, которые позволяют это сделать.

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

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

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

Работа тестировщика — удостовериться в том, что информация о серьезности проблемы передана.

Решение: Не стоит спешить при составлении отчета. Тестировщик должен на 100% отдавать себе отчет о всех возможных последствиях проблемы. Тестировщик не только сообщает, что, мол, какая-то часть софта работает плохо, он еще и поясняет что произойдет, если дефект не устранить.

#3) Недостаток креатива

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

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

Решение: Ценен нестандартный подход. Если какой-то идее не хватает «вау-фактора», и вы знаете что именно нужно исправить, тогда предложите свое видение. В худшем случае ваше предложение не примут. Но важно попытаться.

Стоит также проявлять осторожность. Лучше избегать таких комментариев: «Я ненавижу цвет баннера, пожалуйста, замените его». Вот хороший пример комментария. «Замените опцию «Email дилеру» на «Чат с дилером» на автомобильном сайте». Возможно, такой подход поспособствует конверсии — и больший объем трафика трансформируется в продажи.

Проверочный список:

1) Проблема изложена в заголовке лаконично и исчерпывающе?

Пример: «Опция создания пациента не работает» — это неподходящий заголовок. Альтернативный вариант: «Опция создания пациента не работает даже когда все поля заполнены корректно».

2) Какой допустимый уровень воспроизводимости дефекта?

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

3) Это проблема платформы, браузера или пользователя?
4) Выполнены ли шаги, в результате которых проблема становится заметной?
5) Добавлен ли скриншот?
6) Требуются ли комментарии к скриншоту, чтобы объяснить некоторые нюансы?
7) Можно ли считать название файла изображения достаточно описательным?

Не следует оставлять безымянные названия файлов (Untitled.jpg). Файл должен называться соответствующим образом.

8) Добавлены ли данные по тестированию?

Например, для дефекта в модуле Admin, где требуются данные для авторизации. У команды разработчиков может быть, а может и не быть доступа к QA-среде, из-за чего нередко возникают вынужденные простои.

9) Можно ли что-то добавить, чтобы обнаруженный дефект казался более обоснованным? (Например, отсылка к FRD, разговор с клиентом).
10) Понятна ли тестировщику вся серьезность проблемы, с разных ракурсов?
11) Понятно ли, в чем причина проблемы? Если да, тогда имеются ли доказательства (возможно, логи) и можно ли их добавить?
12) Присутствуют ли в отчете о дефекте сложности по части грамматики, формата, орфографии и пунктуации?
13) Известен ли тестировщику способ улучшить продукцию?

Займет ли вышеописанная проверка много времени? Если это войдет в привычку, то нет.