Как описать баг пример

clothing store 984396 1920 Советы на день

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

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

Если кратко, то хороший баг-репорт позволяет:
1. воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. понять, в чем проблема и какова ее важность.

Как написать хороший баг-репорт?
Для начала надо подготовиться. Если вы обнаружили баг, не стоит моментально бежать в баг-трекер и писать «ничего не работает!». Воспроизведите ошибку. Воспроизвелась? Отлично. Не воспроизвелась? Значит, что-то вы не учли. Вспоминайте, что делали.

Снова воспроизвелась? Ура! А теперь минимизируйте количество шагов для воспроизведения, удостоверьтесь, что нет ничего лишнего.
Если используются какие-то входные данные, удостоверьтесь, что и они не содержат лишнего (действительно ли весь этот здоровенный кусок текста роняет редактор, а не один символ из него?).
Когда вы поняли, какие именно данные и какие ваши действия приводят к проблеме, кратко сформулируйте ее суть — придумайте заголовок баг-репорта. Опишите проблему настолько подробно и конкретно, насколько позволяет заголовок, при этом не увлекаясь его длиной 🙂
Пример плохого заголовка: «Все виснет, когда я вставляю текст из буфера обмена»
Пример «более хорошего» заголовка: «Редактор зависает при вставке текста, содержащего символ N, из буфера обмена по Ctrl+V»
Allenary: Можно еще упомянуть принцип «Что? Где? Когда?». В большинстве случаев это помогает написать удачный заголовок/подробное описание, Например,
Что: неправильный расчет данных
Где: на странице NNN
Когда: после ввода а поле Y отрицательного значения.

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

Теперь откройте баг-трекер, начните заполнять форму баг-репорта.
Запишите заголовок.

В каких-то баг-трекерах поля «Подробное описание» и «Шаги для воспроизведения» различаются, в каких-то — нет.

Если поле «Подробное описание» есть, опишите в нем проблему более подробно — уточните те детали, которые пришлось опустить в заголовке. Если вы понимаете, в чем причина проблемы (используется устаревшая формула для расчетов, не учитывается какое-то значение и т.д.) — тоже пишите все здесь. Если не знаете — лучше не гадайте.
Если в форме записи об ошибке нет отдельного поля Affect version (версия продукта, в котором проявляется проблема), то укажите версию здесь.

«Шаги для воспроизведения» — основное поле для заполнения в баг-репорте.
Запишите шаги, которые вы определили. Как уже было сказано, шагов должно быть необходимо и достаточно для воспроизведения проблемы. Лишние не пишите. Необходимых тоже не пропускайте 🙂
После описания шагов обязательно напишите результат — что получилось.
Далее здесь же опишите ожидаемый результат, если это необходимо. Конечно, не стоит писать «Редактор не падает», но если, например, результаты расчетов не соответствуют ожидаемым, то это надо указывать.
Таким образом, описание шагов для воспроизведения должно выглядеть как-то так:

Шаги для воспроизведения:
1. Открыть…
2. Кликнуть…
3. Ввести в поле… значение N1
4. Ввести в поле… значение N2
4. Кликнуть кнопку Calculate

Результат:
В поле Result отображается V1.

Ожидаемый результат:
В поле Result отображается V2.

Если требуются исходные файлы, данные, дампы и пр. — сразу приаттачьте. Само собой, файлы должны содержать только информацию, необходимую для воспроизведения ошибки. Подчистите все лишнее.
Если проблема с визуальным отображением, то скриншот обязателен — можно будет понять ошибку и без воспроизведения шагов. Khizhnyak: На скриншотах лучше указывать место с ошибкой. Стрелочкой или просто полосой контрастного цвета. Здорово ускоряет «чтение» скриншота.

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

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

По остальным полям.
Severity, Priority.
Наличие этих полей и значения в этих полях отличаются от багтрекера к багтрекеру.
Severity — это критичность бага с точки зрения тестировщика: фича, опечатка в тексте, мелкая проблема, значительная проблема, падение продукта, блокирующая проблема и пр.
Priority — приоритет, с которым проблема должна быть исправлена.
Если есть оба поля, то тестировщик, как правило, выставляет только Severity, а Priority — старший тестировщик/старший программист/менеджер или любой другой ответственный за это дело человек.
Если есть только одно поле, то выставляем его.
«Какой приоритет ставить багу?» На этот вопрос нет однозначного ответа, все зависит от каждого конкретного случая. Но старайтесь не увлекаться и не ставить всем багам подряд высокий или критичный приоритет, реально оценивайте их критичность для проекта.

В какой версии исправить, на кого назначить — зависит от политики внутри компании. Не знаете, что поставить? Спросите коллегу.

Статья дополнена правильными замечаниями из комментариев.

Источник

Распространенные ошибки при составлении баг-репортов

На Хабре достаточно много написано про хороший стиль программирования, naming convention. А про хороший стиль написания баг-репортов?

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

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

1. Очень общий заголовок баги

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

2. Очень подробные pre-steps, очень краткое описание.

Пример: Я забил гвоздь в стену. Потом работал с болтами, гайками и листовым железом. Проблема: космолет не летает.

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

3. На каждое проявление ошибки создать отдельный баг-репорт

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

4. Большое количество аттачей и ссылок

У такой баги обычно есть только заголовок. Шаги воспроизведения представляют собой ссылку на test-case (кстати, возможно у программиста нет прав доступа на такой ресурс), ожидаемый результат — ссылка (или аттач) 50-страничной документации. В комментарии может быть приписка что шаги воспроизведения подробно расписаны в дефекте № NNN. В качестве дополнения — лог. Весь. За все 2 недели тестирования. Все 50 мегабайт. Ну и скриншоты каждого шага бонусом.

5. Не указано, в чем именно ошибка.

Да, бывает и такое. Редко (по-этому и не первое в списке), но бывает

Пример:
Заголовок: Javascript ошибка на странице. Далее идут шаги, как добраться до этой самой страницы, но нигде не указано само сообщение об ошибке и даже нет скриншотов.

6. Использование специфических сокращений и аббревиатур

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

7. Обо всем и ни о чем

Коментарий от 57DeD: Не вошёл в список наиболее распространённый (по крайней мере из тех, с которыми я работал) горе-багрепорт: «У вас программа медленно грузится, иконка не того цвета, при вводе текста ошибка случается, пункт меню — не скажу какой-именно — не работает. Да и погода к тому же плохая — дождь идёт». (видимо, от разработчкаи требуется написать Not Reproduced — дождь уже кончился)

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

1 Правильно настроить обязательные для заполнения поля в баг-трекинговой системе, запретить аттачить большие файлы (если это не видео воспроизведения ошибки)
2. По аналогии с code-review: Просите иногда коллег посмотреть на свежесозданный отчет об ошибке. Возможно, они подскажут, что стоит добавить и/или исключить из описания бага.
3. Проверяйте багобазу перед созданием нового отчета — возможно, такой «зверь» уже записан.
4. Золотая середина нужна везде. Пытайтесь писать не пропуская важных шагов, но и не разжевывая очевидные вещи
5. И не забывайте про золотое правило — пишите отчеты об ошибках так, чтоб вам их было приятно читать

Источник

Баг-репорт

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

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

Виды багов

Структура баг-репорта

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

2077

image1 4

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

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

Приоритет — это срочность выполнения задачи. Всего выделяется три уровня приоритетов:

На курсе вы начнете писать собственные тест-кейсы
и пользоваться баг-трекером. Дополнительная скидка 5% по промокоду BLOG.

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

Статус бага в репорте определяется его «жизненным циклом», который состоит из четырех основных стадий:

Кроме основных есть еще несколько статусов:

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

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

На что стоит обратить внимание при описании дефекта?

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

Провести проверку на разных устройствах. Если проблема есть в десктоп-версии, то она может возникнуть и на мобильных устройствах, поэтому стоит проверить.

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

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

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

Источник

Отчеты о дефектах (баг репорт). Шаблон отчета об ошибке

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

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

Шаблон отчета о дефекте, который отвечает запросам тестировщика и программиста, выглядит следующим образом:
1. Заголовок ошибки
2. Описание ошибки
3. Начальные условия
4. Шаги воспроизведения
5. Ожидаемый результат
6. Фактический результат
7. Вложения

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

Теперь рассмотрим структуру шаблона подробно на конкретном примере. Допустим, мы тестируем сайт. На сайт есть раздел Контакты. В этом разделе находится Форма обратной связи.

2x4bl k1 XUБаг на сайте

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

Данный баг мы и будем описывать по шаблону.

Заголовок ошибки (Title)

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

Наиболее эффективным описанием считается описание, которое отвечает на три вопроса:
— Что произошло?
— Где появилась ошибка?
— Когда или при каких условиях найден дефект?

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

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

Пример плохого заголовка: Ошибка, когда нажимаю «Отправить сообщение».
Пример хорошего заголовка: При нажатии на кнопку «Отправить сообщение» в форме обратной связи сообщение не отправляется.

Описание ошибки (Summary)

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

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

Пример плохого описания: Жму «Отправить сообщение», а в ответ тишина.
Пример хорошего описания: При нажатии на кнопку «Отправить сообщение» в заполненной форме обратной связи ничего не происходит. Аналогичное поведение, если форма не заполнена.

Начальные условия (Precondition)

В случае, если есть специфичные действия или шаги воспроизведения достаточно объемные, то указываются начальные условия. Например:
1. Быть авторизованным в системе.
2. Находиться на главной странице.

Пример плохих начальных условий: Находиться на сайте.
Пример хороших начальных условий:
1. Страница «Контакты»,
2. Платформа и устройство не имеют значения.

Шаги воспроизведения (Steps To Reproduce)

Шаги, при которых повторяется найденная ошибка. Например:
1. Нажать на кнопку “Войти”
2. Ввести “Имя пользователя” и “Пароль”
3. Нажать на кнопку “Ок”

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

Пример плохих шагов: 1. Зайти на сайт, 2. Зайти на страницу обратной связи, 3. Поставить курсор в поле Имя, 4. Ввести имя, 5. Поставить курсор в поле e-mail, 6. Ввести действующий e-mail, 7. Навести курсор на Отправить сообщение, 8. Щелкнуть по Отправить сообщение.
Пример хороших шагов:
1. Заполнить поля формы обратной связи,
2. Нажать на копку «Отправить сообщение»

Ожидаемый результат (Expected Result)

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

Пример плохого ожидаемого результата: Что-то должно произойти.
Пример хорошего ожидаемого результата: Сообщение отправляется либо система сообщает о невозможности его отправки.

Фактический результат (Actual Result)

Указывается результат, который получил тестировщик при выполнении описанных шагов. Также может отвечать на три вопроса “Что? Где? Когда?”.

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

Вложения (Attachments)

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

Источник

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

Больше интересного на эту тему

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

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

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

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

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

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

По критичности баги делят на:

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

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

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

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

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

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

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

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

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

1 247

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

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

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

Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.

Название тестируемого проекта

Компонент приложения (Component)

Название части или функции тестируемого продукта

Номер версии (Version)

Версия, на которой была найдена ошибка

Наиболее распространена пятиуровневая система критичности:

S1 Блокирующий (Blocker)

S2 Критический (Critical)

S3 Значительный (Major)

S4 Незначительный (Minor)

S5 Тривиальный (Trivial)

Статус бага. Зависит от используемой процедуры и жизненного цикла бага. Например:

Создатель баг репорта

Назначен на (Assigned To)

Имя сотрудника, назначенного на решение проблемы

Информация об окружении, на котором был найден баг: операционная система, сервис пак, имя и версия браузера, версия ПО чипа, версия библиотеки и т.д.

Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.

Прикрепленный файл (Attachment)

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

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

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

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

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

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

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

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

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

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

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

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

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

2 1396

При использовании системы тест менеджмента TestIT существует возможность интеграции с системами баг-трекинга. В нашей компании это JIRA. Достаточно нажать “save and create bug” и мы получаем почти готовый баг репорт в JIRA.

Frame%2020 1920

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

frame 20 1 1920

В разделе Description уже есть разделы steps, actual result and expected result, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.

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

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

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

Источник

Оцените статью
Добавить комментарий

Adblock
detector