Как правильно оформить баг-репорт

При тестировании возникает необходимость документирования найденных дефектов. Это позволяет исправить их в кратчайшие сроки.

Если кратко, то хороший баг-репорт позволяет:

• воспроизвести проблему;
• понять, в чем проблема и какова ее важность.

Что такое баг, типы багов

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

Критичность и приоритет бага. Атрибуты баг-репорта

Необходимо рассказать о приоритете и критичности бага. Важно понимать разницу между ними. Примеры приведу из личного опыта. Объектом тестирования в моей работе является ПО приёмников цифрового телевидения. Главной задачей ПО приёмника является расшифровка контента, передаваемого в зашифрованном виде. Для успешной расшифровки абонент должен приобрести у оператора подписку на соответствующий пакет телеканалов.

Критичность бага — это атрибут, который характеризует влияние бага на общую функциональность разрабатываемого ПО. По критичности баги делят на:

S1. Блокирующий (Blocker). Все тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.

S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функциональность, не связанную с расшифровыванием каналов.

S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.

S4. Незначительный (Minor). Не нарушает основные логические цепочки приложения, с ним можно продолжать работать почти без потери качества. Здесь можно привести в пример неточный перевод с русского на английский в меню приёмника.

S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.

Приоритет бага — это то, в каком порядке нужно решать проблемы. Существует три степени приоритетности:

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

P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.

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

Что такое баг-репорт, его типичная структура

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

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

Состав баг репорта приведен в таблице:

Как правильно оформить баг-репорт

1. Для начала нужно убедиться, что найденный баг еще не был оформлен. Следует провести поиск его в соответствующем проекте по всем подходящим ключевым словам и/или полям. Если баг уже есть, следует обновить его описание.
2. Если баг не найден — нажимаем на кнопку создания бага. Не стоит забывать важное правило: один дефект — один баг в трекере.
3. Далее нужно постараться кратко описать, что не работает — это и будет заголовок баг-репорта.
4. После этого перейти к подробному описанию бага: указать шаги к воспроизведению.
5. Указать ожидаемый результат. Можно добавить ссылку на спецификацию.
6. Указать полученный результат.
7. Указать версию ПО, также указать версию окружения.
8. Если необходимо, приложить соответствующие артефакты: логи, скриншоты, дампы и т. д.

Ошибки при создании баг-репорта

Здесь перечислим проблемы, которые чаще всего встречаются при написании баг репорта.

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

Отсутствуют шаги для воспроизведения. Есть риск, что разработчик, не поняв как повторить проблему, вернет баг со статусом «Не воспроизводится».

Неправильно назначен баг. Возможно, баг по ошибке был назначен не на того разработчика или вообще остался в статусе «не назначен». Есть риск, что багу долгое время не будет уделено внимание.

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

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

Жизненный цикл бага

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

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

• Новый (New). Тестировщик нашел баг, дефект успешно занесен в bug-tracking систему.
• Открыт (Opened). После того, как тестировщик отправил ошибку, она либо автоматически, либо вручную назначается на человека, который должен её проанализировать. В зависимости от решения, баг может быть:
• Отложен (Postponed). Исправление бага отложено, т.к. он не является критичным на данном этапе разработки или по другим причинам.
• Отклонен (Rejected). По разным причинам дефект может и не считаться таковым, что вынуждает отклонить его. Не баг, а фича.
• Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему.
• Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика, который должен исправить ошибку.
• Исправлено (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.
• Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект. Если бага больше нет, он получает данный статус.
• Повторно открыт (Reopened). Если опасения тестировщика оправданы, и баг в новом билде не исправлен — он все так же потребует исправления, поэтому вновь открывается.
• Закрытый (Closed). В результате определенного количества перепроверок баг все-таки окончательно устранен и больше не потребует внимания команды — он объявляется закрытым.

Более наглядно жизненный цикл бага можно посмотреть на диаграмме:

При использовании системы тест менеджмента Test IT существует возможность интеграции с системами баг-трекинга: Jira, Azure DevOps, Redmine, YouTrack, ClickUp, TeamStorm.  

В качестве примера покажем TeamStorm. Достаточно нажать «Сохранить и создать баг», и мы получаем почти готовый баг репорт в баг-трекере.

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

Вместо заключения

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

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

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

Не пропустите Yoonion Big Meetup — уникальную бизнес-конференцию для топов и тимлидов из IT. Количество мест ограничено!