как пишется баг репорт

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

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

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

Шаблон отчета о дефекте, который отвечает запросам тестировщика и программиста, выглядит следующим образом:
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)

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Как пишется баг репорт

Что пишут в блогах

В этом видео Крутов рассказал про инструменты Moon и Moon Cloud. Обсудили новые фичи: поддержка Selenium 4, Playwright, Cypress.

29-30 октября в Москве пройдет международная конференция по тестированию SQA Days!

Продолжу хвастаться статусом книги.

Онлайн-тренинги

Конференции

Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Баги, баги, баги! Нельзя обсуждать разработку ПО, не затрагивая тему багов. Поначалу термин «баг» может казаться странным жаргоном для «дефекта». По коду и машинам что, бегают жучки и паучки? Как правило, нет, но иногда таки да! В 1947 году Грейс Хоппер нашла мертвого мотылька, застрявшего в реле гарвардского компьютера Mark II, и в отчете о «жучке» шутила, что нашла настоящего жука за компьютерным дефектом. Несмотря на то, что изобретатели вроде Томаса Эдисона использовали термин «баг» для описания технологических глюков задолго до 1947 года, именно этот мотылек зафиксировал терминологию для компьютеров и ПО.

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

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

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

Когда надо писать баг-репорт?

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

Заметьте, я использую термин «проблема», а не «дефект». Всем проблемам нужны решения, но не все проблемы – это действительно дефекты. Иногда сообщивший о проблеме пользователь не знает, как должна работать фича. Иногда дело в неправильно сконфигурированном окружении. Член команды, выявивший проблему или получивший жалобу от клиента, должен провести небольшое расследование, чтобы убедиться, что проблема действительно выглядит как дефект ПО. Первоначальное расследование нужно проводить немедленно, пока еще жив контекст.

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

Что, если проблема неясна? Если я не уверен, баг это или другой тип проблемы, я спрашиваю коллег. Я пытаюсь задавать вопросы вроде «Выглядит ли это правильным? Что может вызывать такое поведение? Может, я что-то сделал не так?» Слепо плодить баг-репорты для каждой проблемы – вести себя как мальчик из сказки, который кричал «Волки»: команда будет менее чувствительной к предупреждением о реальных, важных багах. Небольшое расследование демонстрирует ваши хорошие намерения и во множестве случаев избавляет команду от лишней работы позднее. Несмотря на это, в случае сомнений создать репорт лучше, чем не создать. Небольшое количество ложноположительных результатов лучше риска реальных проблем.

Зачем нужны баг-репорты?

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

Баг-репорты помогают сделать исправление багов частью процесса разработки. Они привлекают к багам внимание, и их непросто игнорировать или проморгать.

Что входит в баг-репорт?

Вне зависимости от инструмента или процесса, хорошие баг-репорты содержат следующую информацию:

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

Как обращаться с баг-репортом?

Одним словом: профессионально. Обращайтесь с баг-репортами профессионально. Что это значит?

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

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

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

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

Хорошие баг-репорты – это важно.

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

Источник

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 файла на вкладке Регистрация в файловый контроль (командой контекстного меню или перетаскиванием).

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

Источник