Как написать качественный баг-репорт

Перевод статьи «How to Write a Bug Report That Will Make Your Engineers Love You [+Bug Report Template]».

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Содержание

• Что такое баг-репорт?
• Как должен выглядеть баг-репорт?
• Что должен содержать баг-репорт?
• Обязательные атрибуты баг-репорта
  • Название
  • Серьезность и приоритет бага
  • Описание
  • Окружение
  • Шаги воспроизведения
  • Ожидаемый результат
  • Фактический результат
  • Вложения
• Советы по написанию хорошего баг-репорта

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

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

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

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

Как должен выглядеть баг-репорт?

Существует два основных критерия хорошо написанного баг-репорта:

• Воспроизводимость. Чтобы разработчик мог исправить баг, он должен его увидеть, а для этого – воспроизвести. Баги, которые нельзя воспроизвести, могут остаться неисправленными.
• Ясность и информативность. Описание должно содержать минимальный объем текста, но предоставлять как можно больше информации. Обширное “эссе” может только запутать разработчика.

Следует помнить, что баг-репорт, возвращенный тестировщику со статусом “Невозможно воспроизвести” или “Требуется информация”, – это зря потраченное время как тестировщика, так и разработчика. Поэтому очень важно предоставить качественный и правильно составленный баг-репорт.

Мы рекомендуем в начале рабочего процесса обсудить с членами команды и утвердить шаблон баг-репорта. Его можно создать с помощью старых добрых таблиц Excel, но мы предлагаем использовать баг-трекинговые системы. Наша команда использует Teamwork, но вы можете выбрать платформу, соответствующую вашему вкусу и проекту, например Jira, Trello, Mantis или Redmine.

Что должен содержать баг-репорт?

В разных баг-трекинговых системах предлагаются разные шаблоны баг-репортов. Тем не менее, есть ряд обязательных атрибутов:

• Заголовок (Title)
• Серьезность/приоритет (Severity/Priority)
• Описание (Description)
• Окружение (Environment)
• Шаги воспроизведения (Steps to reproduce)
• Ожидаемый результат (Expected result)
• Фактический результат (Actual result)
• Вложения (скриншоты, видео, текст) (Attachments)

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

• Уникальный номер (ID). Каждый баг-репорт должен иметь уникальный идентификатор. Обычно он состоит из первых букв названия проекта и порядкового номера. Большинство багтрекинговых систем автоматически присваивает идентификатор каждому багу.
• Автор. Большинство багтрекинговых систем содержат эту информацию по умолчанию, что позволяет быстро связаться с тестировщиком, который нашел и описал баг.
• Кому назначено (Assigned to). В этом пункте указывается информация о разработчике, который будет исправлять баг. В зависимости от договоренности и организации проекта, баг может быть назначен старшему QA или PM, который будет решать, кто из разработчиков должен его устранить.
• Статус, показывающий текущую стадию работы над багом. Подробнее о статусах багов читайте в статье “Жизненный цикл бага в тестировании ПО”.
• Тип инцидента. Мы считаем необходимым, чтобы тестировщики сообщали не только о дефектах/багах, но и о возможных улучшениях, которые могут быть реализованы на проекте.
• Дата создания.

Обязательные атрибуты баг-репорта

Заголовок

Первым и самым важным атрибутом баг-репорта в любой баг-трекинговой системе является краткое описание бага. Оно позволяет быстро сориентироваться в проблеме. Описание формулируется в виде ответов на три простых вопроса: “Что?”, “Где?”, “Когда?”.

Например:

• Что? – Не загружается фотография.
• Где? – В разделе “Профиль”.
• При каких условиях? – При нажатии на кнопку “Загрузить из галереи”.

Серьезность и приоритет бага

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

Severity

Серьезность характеризует влияние дефекта на работу приложения. Например:

• Blocker. Ошибка, приводящая к сбою в работе приложения.
• Critical. Критический дефект, приводящий к отказу некоторых ключевых функций.
• Major. Важнейшая ошибка, которая указывает на отклонение от бизнес-логики или нарушает работу программы, но не оказывает существенного влияния на работу приложения.
• Minor. Незначительный дефект, который не нарушает функциональность приложения при тестировании, но влияет на ожидаемый результат. Примером может служить ошибка проектирования.
• Trivial. Ошибка, которая не влияет на функциональность или работу приложения, но может быть обнаружена визуально, например, опечатка в тексте.

Priority

Приоритет определяет очередность исправления дефектов. Мы используем следующую общую градацию:

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

В некоторых проектах баг-репорт содержит только один атрибут (Severity или Priority), определенный тестировщиком. Но могут использоваться и оба атрибута. В этом случае тестировщик обычно задает только Severity, а старший тестировщик или менеджер выставляет Priority в зависимости от основной цели проекта или предпочтений заказчика.

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

Описание

Эта часть развивает суть поля Title, поскольку довольно часто заголовок становится слишком громоздким. Вот тут-то и пригодится поле Description, позволяющее описать проблему без каких-либо ограничений. Здесь же указываются дополнительные условия (как часто возникает ошибка, является ли она случайной, какие обстоятельства могут ее вызвать).

Например:

ПРИМЕЧАНИЕ: часовой пояс Account = Atlantic Time (Canada).

В некоторых баг-трекинговых системах, таких как Jira, это поле также включает такие элементы, как “Окружение”, “Шаги воспроизведения”, “Ожидаемый результат”, “Фактический результат” и даже “Вложения”.

Окружение

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

• Производитель устройства и номер модели
• Версия ОС
• Версия приложения
• Сетевое подключение
• Ориентация экрана
• Браузер

Например:

• Устройство – iPhone XR.
• Версия ОС – 13.3.1.
• Версия билда – 0.4
• Подключение к сети – Wi-Fi

Шаги воспроизведения

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

Например:

• Предварительные условия: пользователь зарегистрирован в системе.
• Перейти к списку предлагаемых товаров.
• Добавить товар “А” в корзину.
• Нажать кнопку “Купить”.

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

Ожидаемый результат

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

Например:

После нажатия кнопки “Отправить” обязательные поля выделяются красным цветом.

Фактический результат

В этом поле описывается эффект от бага. Иногда тестировщики пишут общие фразы, например, “Кнопка отмены не работает должным образом”. Это не очень информативно, не так ли? Нажимается ли кнопка? Отменяется ли действие? Или происходит другое событие, не связанное с отменой?

Очень важно написать четкое описание фактического результата. В большинстве случаев оно совпадает с заголовком баг-репорта.

Например:

После нажатия кнопки “Отправить” обязательные поля выделяются зеленым цветом.

Вложения

Стандартной практикой является прикрепление к баг-репорту дополнительных файлов, поскольку информацию легче воспринимать, когда она представлена визуально. Это могут быть:

• Скриншоты (удобно, когда ошибка выделена кружком или стрелкой)
• Видео (иногда бывает сложно описать ошибку словами, поэтому лучше ее показать)
• Логи.

Советы по написанию хорошего баг-репорта

Вот наши рекомендации по написанию эффективного баг-репорта:

• Не бойтесь обращаться за помощью к менеджеру проекта, если вам что-то непонятно.
• Обязательно запрашивайте у разработчиков отзывы и предложения по поводу ваших баг-репортов. Каждый проект уникален, да и разработчики все разные, так что очень важно найти правильный подход. Комфортная атмосфера и взаимопонимание между членами команды способствуют быстрой и качественной работе.
• Перечитайте баг-репорт, прежде чем сохранить его. Можно даже сделать это дважды.
• Убедитесь, что баг-репорт содержит описание только одной ошибки.
• Воспроизведите ошибку еще несколько раз, проанализируйте шаги и добавьте больше деталей, если это необходимо.
• Не критикуйте и не обвиняйте своих коллег. Баги неизбежны, и их не всегда легко уловить и исправить. Помните, вы – одна команда!

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