Баг репорт (Bug Report) или заведение бага в тестировании ПО?

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

Существует различное множество баг-трекинговых систем, которые позволяют нам не только создавать задачи, менять их статусы но и создавать баг репорты. Самые распространенные на сегодняшний день это Redmine, Bugzilla, Mantis, JIRA

Пример того как выглядит список баг репортов в JIRA:


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

Сутью нашего бага будет то что мы не можем залогиниться в админ панель админ юзером, который был только что создан, следовательно что все новые админы не могут залогиниться когда вводишь корректные юзер и пароль в текстовые поля. Ниже объяснения и описания каждого из полей.

Основные Поля в Баг Репорте

ID

Это уникальный идентификатор найденного бага

Summary

Краткое и лаконичное описание бага отвечающее на вопрос Что произошло и при каких условиях.
К примеру так «Newly-created Admin user can't sign in to admin panel»
То есть описание бага должно быть такое чтобы программисту его даже можно было не открывать а сразу искать в чем же баг. Но чаще попадаются все же сложные баги которые и требуют описания внутри дополнительных действий и разъяснений как же его воспроизвести и как на самом деле должно быть, так что только по summary описать сложно. Поэтому существуют следующие, приведенные ниже поля:

Preconditions

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

Steps to Reproduce

Поле используется для описания шагов воспроизвидения при которых наш баг воспроизведется.
К примеру
1) Open login page of admin panel
2) Enter valid credentials into «Username» and «Password» text fields
3) Press Enter button
Т. е. в этом поле описываются детальные шаги до того момента когда мы увидим баг
После последнего шага мы должны увидеть тот результат который и является багом в данной ситуации

Actual Result

Здесь мы описываем что мы получили на последнем шаге пройдя по всем шагам
К примеру это может быть описано так:
«You have entered incorrect user or password» message is displayed on login page

Expected Result

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

Project

Это дробдаун лист с названиями проектов
Если у вас в компании больше чем 1 проект то просто выбери свой проект в котором был найден баг

Build number

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

Priority

Это поле служит для определения приоритета бага, обычно выставляется проджект менеджером или скрам мастером, таким образом определяя первоочередность исправления бага на фоне остальных найденных багов, проводя таким образом очередность исправления багов
Различают такие приоритеты:
High: Наивысший, первоочередной
Medium: Среднего приоритета
Low: Самой последней значимости

Severity

Это поле указывает на серьезность ошибки. Существуют несколько уровней серьезность ошибки таких как:
Blocker: Ставиться если баг блокирует дальнейшую работу приложения или блокирует дальнейшее тестирование, к примеру такой баг что если создать пользователя с существующим именем, то никаким пользователем из всей системы мы не можем залогиниться так как показывается SQL ошибка на главной странице и никуда нельзя больше перейти
Critical: Ставиться при значительном влиянии на поведение ПО и некорректности поведения программы, но не блокирующую работу приложения, к примеру баг такой что пользователь может войти в систему без введения пароля
Major: Ставиться при незначительном влиянии на поведение ПО, и некритическом для нашего проекта, к примеру такой баг что если количество записей в списке записей подсчитывается неверно
Minor: Ставиться если влияние на функционал и поведение ПО баг не производит, к примеру это может быть грамматическая ошибка в названии чего либо

Assignee

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

Reporter

Обычно заполняется автоматически именем того кто создает баг репорт

Status

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

Comments

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

В дополнение

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