Как написать хороший баг-репорт?

16 июня 2021
Kak sostavit bug report_mini

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

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

 

В баг-репорте содержатся данные о том:

  • что работает неверно;
  • где проявляется ошибка;
  • когда она воспроизводится.

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

Но как же добиться этого баланса?

Пути выявления дефектов ПО

QA-специалист может обнаружить ошибки программного обеспечения следующими способами:

  1. при тестировании ПО;
  2. после общения с заказчиком, если он описал дефект;
  3. из пользовательских отзывов.

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

Инструменты документирования дефектов

Наиболее популярной в профессиональном сообществе программой для описания и отслеживания багов служит Jira. Для тестировщиков, которые перешли в ИТ из другой сферы, научиться использовать её может быть непросто. Поэтому слушатели тренинга «Основы тестирования ПО» начинают знакомство с баг-трекинговой системой уже на старте обучения.

Jira ― не единственная баг-трекинговая система. Сотрудники некоторых проектов отдают предпочтение Redmine или Mantis.

Правила составления баг-репорта

  1. Помните о формуле «1 дефект = 1 баг-репорт». Так вы обеспечите прозрачность процессов, ведь отследить каждый конкретный баг будет проще.
  2. Составляйте отчёт на понятном языке, который наверняка поймёт и другой специалист из вашей команды, и разработчик.
  3. Сохраняйте краткость и содержательность при описании ошибки.
  4. Проверяйте воспроизводимость дефекта до написания отчёта.
  5. Изучайте другие баг-репорты, чтобы исключить появление повторяющихся документов.

Элементы отчёта об ошибке

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

Summary (заголовок)

Здесь тестировщику необходимо кратко описать суть выявленного дефекта. Чтобы не упустить главное, воспользуйтесь подсказкой «Что? Где? Когда или при каких условиях?».

Рассмотрим пример. Предположим, что вам необходимо протестировать онлайн-сервис для публикации объявлений ponyaemsya.com. Ожидается, что описание объявления содержит не более 300 символов. В течение тестирование стало ясно, что пользователь может ввести и более длинный текст. Этот факт нам необходимо отобразить в отчёте. Помним о подсказке:
«Лимит знаков в поле для описания объявления отсутствует на каждой странице».

Если тестируется мобильная версия ПО, то важно указать и название платформы.

Description (описание)

Наполнение этого атрибута зависит от особенностей баг-трекинговой системы. При использовании Jira и Redmine тестировщик должен описать этапы воспроизведения бага. Mantis предполагает детальное описание дефекта, а вот путь к нему вводится в поле Steps to reproduce.

Пример описания:

  1. открытие сайта ponyaemsya.com;
  2. регистрация или вход в аккаунт;
  3. выбор раздела «Опубликовать объявление»;
  4. заполнение поля «Описание».

Чтобы не описывать последовательность шагов из 10+ шагов, опишите условия.
«Пользователь прошёл авторизацию на ponyaemsya.com и находится в разделе с выбранными товарами».

Actual/expected result (фактический и ожидаемый результат)

В этом атрибуте мы сравниваем поведение системы и требования к ней. рассмотрим пример.
«Составление описания объявления не лимитируется. Ожидается, что пользователь не может вставить текст 300+ символов».

Attachments (вложения)

Здесь вы можете проиллюстрировать выявленный дефект посредством снимка экрана или схемы. Это упростит понимание ошибки.

Priority (приоритет)

Содержание этого поля отображает срочность решения проблемы. К данному атрибуту обращаются менеджеры при планировании нагрузки.
Есть разные градации важности, но чаще всего тестировщики используют подобные обозначения:

  • P1 High (срочно);
  • P2 Medium (может подождать);
  • P3 Low (не срочно);

Чем выше приоритет, тем быстрее должна быть устранена ошибка.

Severity (серьёзность)

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

  • Blocker (нарушает работоспособность);
  • Critical (влияет значительно);
  • Major (искажает отображаемую информацию, но не несёт заметных изменений);
  • Minor (не сказывается на работе программы).

Status (статус)

Это поле содержит информацию об этапе работы с дефектом.

  • New (новый баг);
  • Environment/platform (среда, платформа или операционная система);
  • Feedback (необходима обратная связь);
  • Acknowledged (с содержанием ознакомлены);
  • Lable (категория ошибки: текст, картинка или прочее);
  • Accepted (дефект воспроизводится, подтверждён);
  • Assigned (ответственный за исправление бага назначен);
  • Resolved (поправки внесены);
  • Closed (ошибка не воспроизводится).

Заключение

Составление отчёта об ошибке неотъемлемый компонент работы тестировщика ПО. От качества этого документа зависит скорость исправления ошибки.

Перед началом составления баг-репорта необходимо:

  • проверить, повторяется ли ошибка;
  • появляется ли она на других платформах;
  • описывался ли этот дефект.

Отчёт об ошибке содержит исключительно полезную информацию и написан простым языком. Важно корректно заполнить все поля.

Научиться работать с тестовой документацией вы сможете на тренинге
«Основы тестирования ПО». Этот навык позволит вам начать карьеру в области обеспечения качества.