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

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

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

Если кратко, то хороший баг-репорт позволяет:
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 — старший тестировщик/старший программист/менеджер или любой другой ответственный за это дело человек.
Если есть только одно поле, то выставляем его.
«Какой приоритет ставить багу?» На этот вопрос нет однозначного ответа, все зависит от каждого конкретного случая. Но старайтесь не увлекаться и не ставить всем багам подряд высокий или критичный приоритет, реально оценивайте их критичность для проекта.

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

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

Источник

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

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

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

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

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

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

Баг на сайте

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

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

Заголовок ошибки (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)

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

Источник

10 правил хорошего тона при описании багов

Здравствуйте, меня зовут Наталья, я инженер по тестированию компании Docsvision.
Иногда, когда я просматриваю ошибки, записанные новенькими (а иногда и старенькими) тестировщиками, рука машинально тянется к лицу. В голове возникает только одна мысль:

«Что? Что я сейчас прочитала?»

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

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

«В контроле файлов при наличии достаточного числа файлов, имена некоторых не отображаются полностью.
Создаём любой документ УД. На вкладке Регистрация в поле Добавьте файл, правым кликом мышь, и выбираем несколько файлов. Второй вариант, перетащить несколько файлов в данное поле. В резутате, если несколько файлов, названия не помещаются полностью. Только если развернуть карточку на весь экран можно увидеть всё полностью. Строка с файлом должна переноситься на следующую строку в контроле, но этого не происходит.»
(Орфография и пунктуация сохранены).

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

Вот ТОП-10 правил хорошего тона, которых я придерживаюсь сама и которые рекомендую коллегам:
1) Сначала глагол.
2) Принцип «Что-Где-Когда».
3) Обезличенность.
4) Простые конструкции.
5) Без лишних слов.
6) Сократить очевидное.
7) Упростить описание сложного действия.
8) По пунктам.
9) Однозначность.
10) Перечитать.

1. Сначала глагол

Магистр Йода из «Звёздных войн» говорил так, что его было непросто понять с первого раза. Его речь строилась по принципу «объект-глагол-субъект».
«Когда и тебе 900 лет исполнится, тоже не молодо будешь выглядеть ты».
В нашей речи глагол стоит в начале (если он есть).

Пример:
Плохо – «Скопированную карточку открыть на редактирование».
Хорошо – «Открыть на редактирование скопированную карточку».

2. Принцип «Что-Где-Когда»

Этот принцип общеизвестный – сначала надо написать «что», а уже потом «в каком месте» и «при каких условиях». Лучше всего работает при составлении краткого описания ошибки.
Что происходит? – «Не создаётся карточка», «Выдаётся необработанное исключение», «Не создаётся база данных».
Где происходит? – «В виртуальной папке», «На вкладке История», «В контекстном меню».
Когда происходит? – «По нажатию кнопки», «После смены состояния карточки», «При сохранении изменений».

Пример:
Плохо – «В отчёте при добавлении файла комментария текстовый комментарий стирается».
Хорошо – «Стирается текстовый комментарий в отчёте при добавлении файла комментария».

3. Обезличенность

Описание ошибки – это не летопись ваших действий, а руководство для другого человека. Уберите себя из описания.

Пример:
Плохо – «Нажимаем кнопку», «Открываю страницу».
Хорошо – «Нажать кнопку», «Открыть страницу».

4. Простые конструкции

Сложносочинённые и сложноподчинённые предложения, причастные и деепричастные обороты осложняют восприятие текста. Чем проще будет построено предложение, тем лучше.

Пример:
Плохо – «На панели инструментов есть кнопка с шестерёнкой, открывающая меню из двух пунктов, при наведении на которую не появляется всплывающая подсказка».
Хорошо – «Навести мышку на кнопку с шестерёнкой на панели инструментов – не появилась всплывающая подсказка».

5. Без лишних слов

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

Пример:
Плохо – «По какой-то причине смена значений в поле работает довольно странно – по сути обновление поля происходит через какой-то промежуток времени».
Убрать слова «По какой-то причине», «довольно», «странно», «по сути». Они не содержат ценной информации и могут быть удалены из описания без потери смысла. Словосочетание «какой-то промежуток времени» может быть заменено на более короткий синоним.
Хорошо – «Обновление значений в поле происходит с задержкой».

6. Сократить очевидное

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

Пример:
Плохо – «Найти ярлык приложения на рабочем столе, кликнуть по нему 2 раза левой кнопкой мыши».
Хорошо – «Открыть приложение по ярлыку».

7. Упростить описание сложного действия

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

Пример:
Плохо – «Согласовать документ», «Выполнить синхронизацию свойств».
Хорошо – «Нажать кнопку «Согласовано» на панели инструментов карточки документа», «Выбрать команду «Синхронизировать свойства» в контекстном меню объекта».

Да, это увеличивает объём описания. Зато уменьшает время воспроизведения за счёт сокращения количества вопросов типа «А как это сделать?» к автору ошибки.

Важно! То, что очевидно для вас, не всегда очевидно для другого человека.
Лично я использую 2 приёма оценки очевидности своего описания:
1) Представить, что видишь интерфейс впервые;
2) Спрогнозировать вопросы, которые могут появиться у читателя.

8. По пунктам

Хорошая практика – разбить шаги воспроизведения на пункты. Это даёт 2 главных преимущества:
1) Упрощается прохождение шагов воспроизведения.
2) Появляется возможность сослаться на некоторый пункт.

Пример:
1) Открыть справочник категорий.
2) Добавить новую категорию. Сохранить, закрыть справочник.
3) Повторить пункты 1 и 2.

Или
1) Создать карточку документа.
2) Создать карточку документа другого вида.
3) Открыть карточку, созданную на шаге 1.

Сколько действий должен содержать один пункт? Вопрос, на который все тестировщики отвечают по-разному.
Я считаю, что общее количество пунктов должно быть не более 5-6, последующие пункты уже воспринимаются сложнее, первое преимущество теряется.
Один пункт должен содержать набор действий, позволяющий достичь некоторой точки. Такой точкой может быть возникновение системного сообщения, создание некоторого артефакта в системе – всё, на чём можно приостановить воспроизведение.

9. Однозначность

Речь наша богата синонимичными словами и словосочетаниями, одни из них уместны и понятны всем, другие – не очень. Я придерживаюсь следующих трёх принципов.
Первый принцип – избегать жаргонных слов и слов с размытым смыслом.

Пример:
Плохо – «система ругается», «клацнуть в молоко», «окно уезжает за экран», «кансельнуть».
Хорошо – «выдаётся необработанное исключение», «кликнуть в пустое место окна», «окно перемещается за пределы экрана», «отменить».

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

Важно! Если разные коллеги говорят по-разному (кто-то «хинт», кто-то «подсказка»), для эффективности дальнейшего поиска такой ошибки лучше при описании употребить и то, и другое слово.

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

10. Перечитать

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

Дополнительно я советую почитать книжку Ли Лефевера «Искусство объяснять. Как сделать так, чтобы вас понимали с полуслова».

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

P.S.: Убийца – дворецкий, а тот «невероятный кусок текста» из начала статьи должен был выглядеть вот так:

«Не помещаются полностью названия файлов в файловом контроле документа при наличии нескольких файлов.
1) Создать любой документ УД. Оставить в режиме окна, не переходить в полноэкранный.
2) Добавить более 1 файла на вкладке Регистрация в файловый контроль (командой контекстного меню или перетаскиванием).

Результат: Названия файлов видны не полностью. Недостаточно места для отображения названий файлов при размере окна по умолчанию.
Ожидаемый результат: Названия файлов должны отображаться полностью.»

Источник

Что такое правильный баг репорт и по какому шаблону его оформить: базовые правила

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

В этом материале о багах вы узнаете:

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

Баг репорт — это документ, который создает тестировщик, когда он обнаружил баг или ошибку. Дословно с английского Bug Report переводится как «отчет об ошибке».

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

Хотите научиться распознавать баги писать правильные баг репорты на примерах? Вам помогут наши менторы-тестировщики!

Шаблон и правила оформления баг репортов

Вот примерная форма и шаблон:

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

В таблице, которая расположена выше, есть две строки, которые мы обещали раскрыть подробнее. Степени серьезности и приоритетов.

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

Хотите научиться писать идеальные баг репорты на примерах? Вам помогут наши менторы-тестировщики!

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

Понятия степени серьезности и степени приоритета связаны напрямую. Степень приоритета определяется исходя из степени серьезности.

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

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

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

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

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

По умолчанию после обнаружения он попадает на стадию «Новый». После завершения всех по работ по нему, он переходит в стадию «Закрытый».

Между этими крайними стадиями есть еще 5 стадий, в которых он может побывать:

Эту схема проще понять, если представить ее визуально. Схема жизненного цикла бага:

Источник