В рамках рубрики «QA советы новичкам» мы детально разберем принцип «Что? Где? Когда?».
Все мы уже прекрасно знаем, что баги заводятся в специальных системах отслеживания ошибок, так называемых баг-трекерах (от англ. Bug tracker или Bug tracking system).
На сегодняшний день существует много программ учета ошибок, однако все они преследуют одну цель – максимально точно и лаконично описать суть дефекта. Именно поэтому все баг-трекеры имеют схожий принцип заполнения.
При составлении баг-репорта рекомендуется указывать следующую информацию о баге:
- Summary (Краткое описание бага);
- Description (Описание бага);
- Priority/Severity (Приоритетность/Серьезность бага);
- Steps to reproduce (Шаги воспроизведения);
- Attachment (Скриншоты/Видео).
Во время заведения баг-репорта можно заметить, что некоторые поля могут быть отмечены обязательными. Данная опция зависит от типа баг-трекера и от требований на отдельном проекте.
Рассмотрим более детально, как правильно заполнять такое обязательное поле как «Описание бага» или «Summary».
Многие тестировщики, особенно начинающие, испытывают огромные трудности именно с формулировкой сути бага. Понимая в чем суть проблемы, очень важно суметь грамотно донести ее до программиста, который будет в дальнейшем читать ваш репорт.
Для того, чтобы избежать путаницы, а также сохранить и без того ограниченное проектом время, в IT-практике было решено унифицировать подход к заполнению данного поля и тем самым облегчить жизнь и программистам, и тестировщикам, которые будут работать с багами.
При описании ошибки очень важно указать на суть проблемы, в каком месте системы это случилось, а также при каких обстоятельствах. Простым языком: поле «Summary» заполняется по принципу «Что происходит? Где происходит? Когда происходит?». Только в таком порядке и никак иначе!
Неправильная формулировка может привести к недопониманию со стороны разработчика, который возьмется за исправление данного бага. В результате баг будет исправлен не так, как ожидалось, либо не будет исправлен вообще. Также разработчик потеряет много времени на то, чтобы разобраться в чем суть данной проблемы.
Давайте на примерах рассмотрим, какие основные проблемы могут возникать при описании бага:
- Использование сленга. Безусловно, постоянное использование англоязычных слов в лексиконе, и просто общение внутри команды, не может не сказаться на работе как таковой. Однако не стоит использовать сленговые слова при заполнении отчетности, так как разработчик или другой человек, который будет читать ваш баг-репорт, может неправильно понять суть проблемы. Например:
| Неправильный вариант | Правильный вариант |
| Возникает эксепшн на форме добавления сотрудника при нажатии кнопки «Сохранить» | Отображается ошибка на форме добавления сотрудника после выбора кнопки «Сохранить» |
- Не всегда удается понять пункт «Когда». Часто действие, которое привело к результату, отличающемуся от ожидаемого, описывается не совсем понятно. Например:
| Неправильный вариант | Правильный вариант |
| Происходит выход из экзамена на последнем вопросе анкеты при нажатии на кнопку «Предыдущий ответ» | Происходит выход из экзамена на последнем вопросе анкеты после выбора кнопки «Предыдущий ответ» |
- Несоблюдение принципа «Что? Где? Когда?». Самая серьезная и в то же время самая распространенная ошибка при заполнении отчета. Если вы поймете, что данный принцип рассчитан на то, чтобы облегчить ваш мыслительный процесс, тогда на формирование отчетности будет уходить намного меньше времени.
«Что?» – это НЕ существительное, это то, что произошло, своего рода ГЛАГОЛ-уточнение («Что выполняется?» или «Что НЕ выполняется?»). Особенно хорошо данная проблема просматривается на примере английского варианта отчета.
Например:
| Неправильный вариант | |
| Misinformation validation error message in the registration form during incorrect filling registration form. | «Misinformation validation error message» – ЧТО? «.. in the registration form» – ГДЕ? «.. during incorrect filling registration form» – КОГДА? |
| Правильный вариант | |
| Misinformation validation error message IS SHOWN in the registration form after filling the registration form with incorrect data. | «Misinformation validation error message IS SHOWN» – ЧТО ДЕЛАЕТ? «.. in the registration form» – ГДЕ? «.. after filling the registration form with incorrect data» – КОГДА? ПОСЛЕ ЧЕГО? ВСЛЕДСТВИЕ КАКОГО ДЕЙСТВИЯ? В ПЕРИОД КАКОГО ДЕЙСТВИЯ? |
- Добавление в теме, описании и результатах ссылки на сайт. Ссылка на сайт пишется всегда в первом шаге, а в указанных атрибутах необходимо давать информацию о расположении бага: название формы, страницы, блока.
| Неправильный вариант | Правильный вариант |
| Не изменяется цвет товара на сайте <ссылка на сайт> после выбора красного цвета. | Не изменяется цвет товара на странице товара «Printed Summer Dress» после выбора красного цвета. |
Дорогие слушатели, как только вы поймете, что данный принцип на самом деле придуман для того, чтобы упростить вашу работу, и начнете им руководствоваться, тогда у вас останется больше времени на любимое занятие: поиск изъянов и неточностей в программном обеспечении.
Рекомендуем особенно внимательно ознакомиться с данной информацией слушателям наших онлайн-курсов, так как она будет являться одной из опорных точек при проверке и оценивании ДЗ.
Бывают случаи, когда нет возможности поместить всю необходимую для описания бага информацию в поле «Summary». Причиной может стать установленное ограничение на количество символов в поле, либо чтобы избежать нагромождения большого количества текста в поле. В таких случаях рекомендуется сформулировать описание бага таким образом, чтобы в минимальном количестве текста максимально понятно была описана суть заводимого бага. А уже в поле «Description» поместить более детальный вариант описания бага.
