Как правильно составить описание бага в баг-трекере. Принцип «Что? Где? Когда?»
В рамках рубрики «QA советы новичкам» мы детально разберем принцип «Что? Где? Когда?».
Все мы уже прекрасно знаем, что баги заводятся в специальных системах отслеживания ошибок, так называемых баг-трекерах (от англ. Bug tracker или Bug tracking system).
На сегодняшний день существует много программ учета ошибок, однако все они преследуют одну цель – максимально точно и лаконично описать суть дефекта. Именно поэтому все баг-трекеры имеют схожий принцип заполнения.
При составлении баг-репорта рекомендуется указывать следующую информацию о баге:
- Summary (Краткое описание бага);
- Description (Описание бага);
- Priority/Severity (Приоритетность/Серьезность бага);
- Steps to reproduce (Шаги воспроизведения);
- Attachment (Скриншоты/Видео).
Во время заведения баг-репорта можно заметить, что некоторые поля могут быть отмечены обязательными. Данная опция зависит от типа баг-трекера и от требований на отдельном проекте.
Рассмотрим более детально, как правильно заполнять такое обязательное поле как «Описание бага» или «Summary».
Многие тестировщики, особенно начинающие, испытывают огромные трудности именно с формулировкой сути бага. Понимая в чем суть проблемы, очень важно суметь грамотно донести ее до программиста, который будет в дальнейшем читать ваш репорт.
Для того, чтобы избежать путаницы, а также сохранить и без того ограниченное проектом время, в IT-практике было решено унифицировать подход к заполнению данного поля и тем самым облегчить жизнь и программистам, и тестировщикам, которые будут работать с багами.
При описании ошибки очень важно указать на суть проблемы, в каком месте системы это случилось, а также при каких обстоятельствах. Простым языком: поле «Summary» заполняется по принципу «Что происходит? Где происходит? Когда происходит?». Только в таком порядке и никак иначе!
Неправильная формулировка может привести к недопониманию со стороны разработчика, который возьмется за исправление данного бага. В результате баг будет исправлен не так, как ожидалось, либо не будет исправлен вообще. Также разработчик потеряет много времени на то, чтобы разобраться в чем суть данной проблемы.
Давайте на примерах рассмотрим, какие основные проблемы могут возникать при описании бага:
- Использование сленга. Безусловно, постоянное использование англоязычных слов в лексиконе, и просто общение внутри команды, не может не сказаться на работе как таковой. Однако не стоит использовать сленговые слова при заполнении отчетности, так как разработчик или другой человек, который будет читать ваш баг-репорт, может неправильно понять суть проблемы. Например:
Неправильный вариант Возникает эксепшн на форме добавления сотрудника при нажатии кнопки «Сохранить»
Правильный вариант Отображается ошибка на форме добавления сотрудника после выбора кнопки «Сохранить»
Не всегда удается понять пункт «Когда». Часто действие, которое привело к результату, отличающемуся от ожидаемого, описывается не совсем понятно. Например: