Баг репорт пример

Раздел: Тестирование > Тестовые Артефакты > Баг Репорт > Написание баг репорта

Написание баг репорта

Баг репортэто технический документ и в связи с этим хотим отметить, что язык описания проблемы должен быть техническим. Должна использоваться правильная терминология при использовании названий элементов пользовательского интерфейса (editbox, listbox, combobox, link, text area, button, menu, popup menu, title bar, system tray и т.д.), действий пользователя (click link, press the button, select menu item и т.д.) и полученных результатах (window is opened, error message is displayed, system crashed и т.д.).

Требования к обязательным полям баг репорта

Отметим, что обязательными полями баг репорта являются: короткое описание (Bug Summary), серьезность (Severity), шаги к воспроизведению (Steps to reproduce), результат (Actual Result), ожидаемый результат (Expected Result). Ниже приведены требования и примеры по заполнению этих полей.

Короткое описание

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

  1. Приложение зависает, при попытке сохранения текстового файла размером больше 50Мб.
  2. Данные на форме «Профайл» не сохраняются после нажатия кнопки «Сохранить».

В дополнение предлагаем вам изучить Принцип «Где? Что? Когда?», описанный на страницах блога «QA Nest»:

«В чем этот принцип состоит?
Составьте предложение, в котором факты дефекта изложены в следующей последовательности:

  • Где?: В каком месте интерфейса пользователя или архитектуры программного продукта находится проблема. Причем, начинайте предложение с существительного, а не предлога.
  • Что?: Что происходит или не происходит согласно спецификации или вашему представлению о нормальной работе программного продукта. При этом указывайте на наличие или отсутствие объекта проблемы, а не на его содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты указываются в описании.
  • Когда?: В какой момент работы программного продукта, по наступлению какого события или при каких условиях проблема проявляется.

Почему последовательность должна быть именно такой?
В таком виде незнакомые дефекты удобнее сортировать по summary как показывает практика (ведь, скорее всего, именно среди дефектов других инженеров будет производиться поиск дубликатов). Если вы другого мнения — придумайте свою последовательность, но она должна стать единой для всех без исключения членов проекта, иначе вы не добьетесь необходимого результата.»

Серьезность

В двух словах можно отметить, что если проблема найдена в ключевой функциональности приложения и после ее возникновения приложение становится полностью недоступно, и дальнейшая работа с ним невозможна, то она блокирующая. Обычно все блокирующие проблемы находятся во время первичной проверки новой версии продукта (Build Verification Test, Smoke Test), т.к. их наличие не позволяет полноценно проводить тестирование. Если же тестирование может быть продолжено, то серьезность данного дефекта будет критическая. На счет значительных, незначительных и тривиальных ошибок вопрос достаточно прозрачный и на наш взгляд не требует лишних объяснений.

Шаги к воспроизведению / Результат / Ожидаемый результат

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

Например:

Шаги к воспроизведению
1. Войдите в системы: Пользователь Тестер1, пароль xxxXXX
—> Вход в систему осуществлен
2. Кликните линк Профайл
—> Страница Профайл открылась
3. Введите Новое имя пользователя: Тестер2
4. Нажмите кнопку Сохранить
Результат
На экране появилась ошибка. Новое имя пользователя не было сохранено
Ожидаемый результат
Страница профайл перегрузилась. Новое значение имени пользователя сохранено.

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

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

Определение серьезности
Очень часто происходит либо завышение, либо занижение серьезности дефекта, что может привести к неправильной очередности при решении проблемы.

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

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

Заполнение полей баг репорта

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

Поле Ответственный за заполнение поля
Короткое описание (Summary) Автор баг репорта (обычно это Тестировщик)
Проект (Project) Автор баг репорта (обычно это Тестировщик)
Компонент приложения (Component) Автор баг репорта (обычно это Тестировщик)
Номер версии (Version) Автор баг репорта (обычно это Тестировщик)
Серьезность (Severity) Автор баг репорта (обычно это Тестировщик), однако данный атрибут может быть изменен вышестоящим менеджером
Приоритет (Priority) Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт
Статус (Status) Автор баг репорта (обычно это Тестировщик), но многие системы баг трекинга выставляют статус по умолчанию
Автор (Author) Устанавливается по умолчанию, если нет, то указывается имя автора баг репорта
Назначен на (Assigned To) Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт
ОС / Сервис Пак и т.д. / Браузера + версия / … Автор баг репорта (обычно это Тестировщик)
Шаги воспроизведения (Steps to Reproduce) Автор баг репорта (обычно это Тестировщик)
Фактический Результат (Result) Автор баг репорта (обычно это Тестировщик)
Ожидаемый результат (Expected Result) Автор баг репорта (обычно это Тестировщик)
Прикрепленный файл (Attachment) Автор баг репорта (обычно это Тестировщик), а также любой член командной группы, считающий, что прикрепленные данные помогут в исправлении бага

Наверх

 

Баг (от англ. Bug) – сленговое обозначение ошибки программы. Баги выявляются в результате тестирования. Для их устранения необходимо заявить о проблеме разработчику, а значит – составить баг-репорт.

Какова цель баг-репорта?

  1. Воспроизвести обнаруженную проблему.
  2. Понять, в чём именно проблема и насколько она важна.

Чтобы воспроизвести проблему, необходимо описать шаги, выполнив которые, можно её увидеть. Поэтому не стоит заводить баг сразу же, как только вы увидели ошибку. Нужно сначала повторить её. Не удаётся повторить – значит, возможно, пропущены важные шаги. Вспоминаем, что делали. Как только выявлен порядок действий, который приводит к ошибке, необходимо минимизировать количество шагов: убрать лишние, не влияющие на исход. Затем заводим баг в системе баг-трекинга:

Кратко формулируем в Теме суть по принципу «Что? Где? Когда?»: что не правильно, где именно, при каком условии.

В Описании приводим шаги воспроизведения. Лишних не пишем, необходимых не пропускаем. Руководствуемся принципом “Что делали? Что получили? Что должны были получить?”

Если нужны исходные данные для воспроизведения – прикрепляем файлы. Если проблема визуального характера, то вставляем скриншот (для этого можно воспользоваться, к примеру, приложением Lightshot), а в качестве ожидаемого результата – ссылку на дизайн. На скриншоте нужно обязательно указать стрелочками/подписями, в чём проблема (желательно прямо на параллели со снимком дизайна):

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

Затем необходимо указать окружение, в котором появляется проблема: модель устройства, версия ОС, браузер. Если в нескольких – перечисляем все. Например: Win8 Chrome, MacOS 10.9 Safari, Sony Xperia Z Android 4.4.2 Chrome.

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

  • Blocker – проблема блокирует функционал.
  • High – серьезные проблемы функционала, задевающие основной сценарий/главные фичи, которые нужно исправить в первую очередь.
  • Normal – стандартные баги функционала/ верстки.
  • Low – опечатки, мелкие баги верстки.

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

Чего делать нельзя:

1. Нельзя заводить несколько проблем в одном баге.

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

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

Навигация по записям

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

2. Нельзя заводить как баг то, что не имеет отношение к Спецификации проекта.

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

Об эффективных багрепортах

Раздел: Тестирование > Тестовые Артефакты > Баг Репорт

Баг Репорт (Bug Report)

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

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

Предлагаем Вам комментарий одного разработчика:
Прочитав короткое описание бага (Bug Summary), я должен понять в чем состоит проблема, прочитав детальное описание бага (Bug Description) я должен знать строку кода, которую править.

С этим можно соглашаться или не соглашаться, но смысл этого высказывания в том, что вы должны делать все так, чтобы к вам меньше было вопросов по существу описанной в баг репорте проблемы. Так как каждый возвращенный вам баг репорт со статусом «Отклонен», «Не воспроизводится», «Требуется информация» (Rejected, Can’t Reproduce, More info) — это потеря времени, как вашего так и разработчика. А время, как известно — это деньги, которые мы получаем, за то что делаем нашу работу лучше всех!

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

Наверх

 

.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *