iTechArt logo

Что такое баг репорт и как с ним управляться?

Development & QA

Баг репорт — документ, описывающий несоответствие реальной работы программы с предъявленными к ней требованиями. Он содержит информацию о найденном баге (ошибке) с подробным описанием всех действий, которые привели к тому, что ошибка была обнаружена. 

Как правильно писать баг репорт? На что стоит обратить внимание, чтобы не допустить фатальных ошибок? Своим опытом делится Виола Стаховская, QA Engineer iTechArt.

Наш собеседник
Стаховская Виола.jpg

Виола Стаховская

QA Engineer iTechArt

Написала 800+ баг репортов.

Что такое баг репорт?

Для начала давайте выясним, что такое баг (ошибка/дефект). 

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

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

Чем отличается баг репорт от других видов тестовой документации

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

Что касается остальных видов тестовой документации (сюда относятся чек-листы, тест-кейсы, тест-планы, тестовые сценарии и проч.) — они нужны для того, чтобы упростить отбор и воспроизведение тестовых случаев. Тестовая документация, которая хорошо структурирована, легко поддерживается и читается, позволит в долгосрочной перспективе сэкономить время при регрессии, сводя её к проведению проверок и передаче отчета о результатах.

Почему баг репорт важен и что можно считать хорошим баг репортом

Для большей наглядности приведу историю-пример, который запомнился мне ещё со времен университета:

«Жил-был мастер, который шил платья. Как-то раз он совершил ошибку — отвлекся и не прошил нижний край у кармана в детском платье. На вешалке вещь выглядела абсолютно нормально, но она была с дефектом.

Маленькая девочка купила это платье. И все было замечательно до тех пор, пока девочка не решила воспользоваться карманом. Она опустила руку в карман, чтобы положить ключ и...он выпал! Сбой в системе, который проявил ранее скрытый дефект».

При разработке программного продукта всегда есть риск ошибки при написании кода, и это значит, что в программе может затаиться дефект. Задача тестировщика найти этот дефект.

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

Как пишется баг репорт. Основные разделы

Баг репорт заполняется в баг трекинговой системе (Jira, Trello). Он состоит из заголовка и описания, и нескольких полей (связанные задачи, команда, исполнитель, дизайнер, метки, приоритет, эпик, блокирован кем-то), которые заполняются или не заполняются в зависимости от проекта.

Заголовок должен быть кратким и емким. Нужно, чтобы уже по заголовку можно было понять суть проблемы. Обычно он составляется по принципу «Что? Где? Когда?». Например:

Что - Открывается пустой дропдаун

Где - На главной странице

Когда - При нажатии на него.

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

  1. Более подробное, чем у заголовка описание проблемы.
  1. Описание исходного состояния системы + другие данные об окружении:
  • браузер и его версия; 
  • тестовое окружение: dev, stage, prod; 
  • устройство, на котором проходило тестирование: мобильный телефон, планшет, десктоп с их операционной системой).
  1. Шаги для воспроизведения ошибки.

Все глаголы пишутся в инфинитиве. Не надо писать «я нажал/нажала на кнопку». Правильнее будет написать «нажать на кнопку»/«открыть «Корзину»/«Домашнюю страницу». Шаги нумеруются. Если надо открыть сторонний ресурс, прикрепить в скобках ссылку на него.

  1. Описать фактический результат.

Текст + скриншот экрана/записанное видео. Видео должно записываться без постороннего звука на фоне, если не тестируется компонент программы, где должен быть использован звук. Вряд ли кому то захочется слушать ваши звуки на фоне. Если видео большое или нет возможности его прикрепить прямо в баг-трекинговую систему, можно его предварительно загрузить на Гугл-диск и вставить ссылку на него (всегда проверяем ссылку и права доступа прежде, чем вставить!).

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

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

  1. Описать ожидаемый результат.

Текст/скриншот (если речь о UI баге) из требований. Иногда для наглядности можно совместить на одной фотографии фактический и ожидаемый результат. Так будет проще ориентироваться разработчику и не надо будет перелистывать фотографии взад-вперед.

  1. Выставить «Severity, Priority»

Они обычно выставляются в выпадающих списках отдельно от описания. Выставляется самим тестировщиком, но может быть потом исправлено разработчиком или PM.

  1. Заасайнить на разработчика или РМ.
  1. Нажать «Готово» :)

У баг репорта есть свой жизненный цикл

  1. Открыт (Open) — вы создали баг и передали его разработчику/РМ (чтобы тот сам определил, кому из разработчиков его выдать). Либо баг отправится в бэклог (особое место, где баги ожидают, пока их выберут и отправят в разработку. Это как игроки на скамье ждут, пока капитан команды их возьмет к себе в команду)
  2. В Работе (In Progress) — баг передан разработчику, тот его фиксит.
  3. Исправлен (Ready for Design/QA) — баг исправлен разработчиком и передан дизайнеру (если таковой входит в команду) или тестировщику на повторную проверку.

Если баг оказывается неисправленным, он возвращается обратно разработчику (желательно прикрепить фото/видео отчет, что баг до сих пор отображается).

  1. Закрыт (Closed) — баг проверен, больше не воспроизводится. При закрытии бага тестировщик пишет в комментариях, на какой окружении он был проверен и прикрепляет скриншот или видео, что баг действительно исправлен (последнее действие здорово помогает подтвердить, что баг был исправлен, если возникают вопросы при его дальнейшем появлении)

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

Основные ошибки при написании багов репортов

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

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

  1. Баг репорты повторяются.

Если на проекте более одного тестировщика, следует проверять, нет ли такого же баг репорта.

  1. Одна проблема — один репорт.

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

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

Разработчик будет терять время, читая весь документ (если вообще будет, а не отправит баг репорт обратно на вас). Прикрепляя требования надо указать, в каком разделе и пункте найти нужную информацию. Если в требованиях нужно только пару строчек — прикрепите фото этих строчек. Сразу будет понятно, и не надо будет скачивать и листать весь документ. 

  1. Проверяйте вставленные ссылки и звуки на видео! 

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