Как правильно составлять описание бага в баг-треккере. Принцип «Что? Где?

Когда?»

Все мы уже прекрасно знаем, что баги заводятся в специальных системах отслеживания
ошибок или, как их принято называть в ИТ-среде, баг-треккер (от англ. Bug tracker или
Bug tracking system).

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

При составлении баг-репорта Вы наверняка обращали внимание, что некоторые поля

обязательны к заполнению, к примеру: Summary (Краткое описание бага), Description
(Описание бага), Steps to reproduce (Шаги воспроизведения), Attachment
(Скриншоты/Видео), а некоторые заполняются по желанию: Category (Тип бага), Priority
(Приоритетность бага), Assignee (Ответственный за устранение бага) и др.

Сегодня мы остановимся более детально на том, как правильно заполнять такое

обязательное поле как «Описание бага» или «Summary».

Многие тестировщики, особенно начинающие, испытывают огромные трудности именно

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

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

При описании ошибки очень важно указать, что именно сломалось, в каком месте системы
это случилось, а также при каких обстоятельствах. Простым языком: поле «Summary»
заполняется по принципу «Что? Где? Когда?». Только в таком порядке и никак иначе!

Неправильная формулировка может привести к печальным последствиям.

Давайте на примерах рассмотрим, какие основные проблемы могут возникать при

описании бага:

 Использование сленга портит всё дело. Безусловно, постоянное использование

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

Пример - Неправильный вариант Пример – Правильный вариант

Возникает эксепшн при нажатии кнопки Возникает ошибка на форме добавления

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

Пример - Неправильный вариант Пример – Правильный вариант

Происходит выход из экзамена на Происходит выход из экзамена на

последнем вопросе анкеты при нажатии последнем вопросе анкеты «в момент
на кнопку «Предыдущий ответ» нажатия» или «после нажатия» на
кнопку «Предыдущий ответ»

 Несоблюдение принципа «Что? Где? Когда?». Самая серьезная и в тоже время

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

«Что?» – это НЕ существительное, это то, что произошло, своего рода ГЛАГОЛ-
уточнение («Что выполняется?» или «Что НЕ выполняется?»). Особенно хорошо
данная проблема просматривается на примере английского варианта отчета.

Пример - Неправильный вариант

Misinformation validation error "Misinformation validation error message" - ЧТО?

message in the registration form ".. in the registration form" - ГДЕ?
during incorrect filling ".. during incorrect filling registration form" - КОГДА?
registration form.

Пример - Правильный вариант

Misinformation validation error "Misinformation validation error message IS SHOWN" -

message IS SHOWN in the
registration form after filling the
registration form with incorrect
data.
ЧТО ДЕЛАЕТ?
".. in the registration form" - ГДЕ?
".. after filling the registration form with incorrect data" -
КОГДА? ПОСЛЕ ЧЕГО? ВСЛЕДСТВИЕ КАКОГО
ДЕЙСТВИЯ? В ПЕРИОД КАКОГО ДЕЙСТВИЯ?

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

Желаем удачи в прохождении нашего тренинга!