Отчеты о дефектах (баг репорт). Шаблон отчета об ошибке
Чтобы упростить работу тестировщикам и программистам, был разработан и стандартизирован отчет о дефектах. С одной стороны его задача — быть простым и понятным, а с другой стороны — быть эффективным.
Важно, чтобы программист при изучении данного отчета мог с легкостью воспроизвести описанный баг и понять ход мыслей тестировщика.
Шаблон отчета о дефекте, который отвечает запросам тестировщика и программиста, выглядит следующим образом:
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): оформление и пример
Баг репорт (bug report) – это документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Bug report c определением в самом общем случае – это несоответствие требованиям или функциональным спецификациям (или здравому смыслу). То есть это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
В данной статье мы рассмотрим основные моменты, связанные с созданием баг репорта, а также в конце предоставим баг репорт пример с возможностью скачивания.
Содержание
Определения понятия баг
Для лучшего понимания, того что такое баг репорт, нужно тать и определение понятию что такое баг. Следует отметить, что однозначного и исчерпывающего определения Bug не имеет, поэтому перечислим наиболее распространенные.
Мы будем использовать простое определение:
Дефект (баг, глюк, ошибка; defect, bug) – это несоответствие требованиям или функциональным спецификациям.
Также следует помнить, что к багам относится любое некорректное поведение программы, не соответствующее оправданным ожиданиям пользователя, даже в том случае, если это поведение не документировано в требованиях и спецификациях.
Баги могут встречаться в любой документации, в архитектуре и дизайне, в коде программы и т.д.
Иногда баг на самом деле является не ошибкой в программе, а результатом неверного конфигурирования программы и/или окружения.
Управление инцидентами перед оформлением баг репорта
Инцидент (incident) — это любое событие, требующее исследования.
Любое существенное, незапланированное событие, которое происходит во время тестирования, что требует дальнейшего исследования и / или коррекции:
Если есть расхождения между фактическими и ожидаемыми результатами, то прежде чем делать send bug report (отправь баг репорт), баг должны быть зарегистрированы как инциденты.
Инцидент (Test Incident) – любое событие, наблюдение, найденное в рамках тестирования, требующее исследования. Инцидент может возникнуть:
Виды инцидентов
Есть практика выделять два вида тестовых инцидентов: дефект и запрос на улучшение. Если давать определения этим понятиям, то можно назвать следующее
Документирование инцидента
Как мы отмечали выше, прежде чем отправь баг репорт, найденные во время тестирования инциденты должны быть специальным образом задокументированы. Это может быть:
Для управления и контроля над тестовыми инцидентами и баг репортами используются специализированные программы о них и поговорим ниже.
Инструмент управления дефектами и инцидентами
Оформление баг репорта или отчета об инциденте удобно делать если есть специальный инструмент управления дефектами (Defect Management Tool, Bug or Issue Tracker Tool) – инструмент, обеспечивающий фиксирование дефектов и изменений, а также поддержку их состояний. Часто имеет процессно-ориентированные возможности для поддержки и контроля распределения, исправления и повторной проверки дефектов, а также возможности отчетности. Помимо стандартной функциональности, хороший инструмент управления дефектами должен иметь возможности:
В свою очередь хороший отчет о дефекте (баг репорт) должен обладать рядом свойств и характеристик, о которых давайте поговорим ниже.
Оформление баг репорта: основные принципы
Определения для понятия bug report мы навали выше, поэтому начнем с характеристик, которыми должен обладать отличный баг репорт. Качественное оформление баг репорта должно отвечать на следующие вопросы:
Инженер по тестированию должен уделять большое внимание качеству создаваемых отчетов о дефектах. Чем лучше он описан тем менее вероятна ситуация отклонения дефекта или неверной трактовки дефекта другими участниками проекта.
Цель баг репорта
Целью составления отчета о дефекте является ее исправление, поэтому не имеет смысла создавать отчеты ради отчетов. Чем больше хорошо задокументированных отчетов поступает от команды тестирования, тем больше доверия к тестированию. Целью отчёта об ошибке (bug-report) является:
Отчёт об ошибке – один из основных результатов работы тестировщиков. И, к слову, именно этот результат работы видят коллеги (другие тестировщики и люди, не входящие в команду тестировщиков), при этом заказчики видят работающий продукт.
И если подводить черту под смыслом написания баг репорта, то основная цель написания отчёта об ошибке – устранение ошибки.
Поэтому стоит помнить, что хороший тестировщик – не тот, кто написал за день 1000 бесполезных и бессмысленных отчётов, а тот, по чьим отчётам (вне зависимости от их количества) было исправлено большое количество ошибок.
Баг репорт: пример полей для заполнения (атрибуты)
Ниже предоставлен список основных полей отчета о дефекте. Будем перечислять возможные атрибуты, а также останавливаться и объяснять наиболее важные. Звездочками помечены обязательные поля для заполнения.
Название проекта * (Project) – официальное название проекта
Здесь, в принципе, все понятно и каких-либо дополнительных объяснений не нужно.
Уникальный номер отчета * (ID) – идентификатор отчета о дефекте
У каждого отчёта об ошибке должен быть уникальный идентификатор. Как правило, системы управления ошибками (bug tracking systems) позволяют формировать идентификатор в виде некоторого шаблона, например аббревиатура проекта + дата + порядковый номер
Либо, каким-нибудь другим видом, при этом ID, будет позволять идентифицировать баг.
Дата создания * (Created Date) – дата создания отчета
Опять-таки, здесь все предельно понятно.
Дата обновления (Update Date) – дата обновления (изменение, закрытие)
Данный атрибут не всегда является обязательным, и в дополнительном толковании не нуждается.
Краткое описание * (Summary, Title, Subject, Synopsis) – заголовок отчета
Важный атрибут любого баг репорта. Нужно емко и по существу передать информацию о проблеме. Характеристика хорошего заголовка – прочитав только заголовок понятен смысл ошибки. Хорошее краткое описание, как и баг репорт вцелом, должно давать ответы на три вопроса:
Например:
Краткое описание иногда предваряется префиксом, указывающим область работы с приложением, для которой актуален баг, например:
Примечание:
Текущий статус * (Status) – состояние инцидента
Набор статусов зависит от выбранного процесса разработки. Базовые статусы:
О правилах переходов из состояния в состояние будет сказано в статье про жизненный цикл бага.
Резолюция (Resolution) – пояснение к статусу
К примеру, дефект может быть закрыт, но причины закрытия могут быть разными: сделан, дубликат, отклонен. Набор резолюций зависит от выбранного процесса разработки. Базовый набор возможных резолюций:
Подробнее о резолюциях будет сказано в отдельной статье.
Приоритет (Priority) – свойство, указывающее на очередность выполнения задачи или устранения дефекта
Также является важным атрибутом bug report, чем выше приоритет сущности, тем быстрее нужно приступить к ее реализации. Набор приоритетов завит от выбранного процесса разработки и зачастую, данную информацию отражает тест план. Базовый набор приоритетов:
Приоритет может выставляться инженером по тестированию, но, как правило, приоритет редактируется менеджером проекта.
Строгость (Severity) – техническая оценка инцидента
Набор степеней строгости дефектов завит от выбранного процесса разработки и договоренностей между участниками проекта. Базовый набор:
Тип инцидента (Incident Type) *
Принято выделять два вида тестовых инцидентов:
Категория инцидента (Category)
Данное свойство отображает, к какой характеристике проекта относится инцидент. Базовый набор категорий:
Компонент (ы) (Component)
Здесь отображается область объекта тестирования, к которой относится инцидент.
Версия приложения, для которой инцидент актуален (Affects Version)
Версия приложения, в которой инцидент найден. И версии, на которых инцидент воспроизводится. Важно понимать, что если мы находим дефект на поздних версиях приложения, то, возможно, он воспроизводится и на более ранних версиях. Для десктоп приложений важно знать все версии, где дефект воспроизводится. Иногда детальное отображение всех версий, где воспроизводится дефект, требуется для сбора метрик. На большинстве веб-проектов достаточно указывать только версию, в которой нашли инцидент.
(Fix Version)
Версия приложения, в которой инцидент был закрыт.
Создатель отчета * (Reporter)
Этот атрибут хранит в себе имя создателя отчета. Создателем отчета не обязательно должен быть специалистом по тестированию, им может быть любой участник проекта или даже пользователи.
На кого назначен отчет (Assignee)
Здесь отражается имя сотрудника, назначенного на решение задачи.
Метки (Labels)
Метки используются для систематизации информации. В дальнейшем метки служат для сбора метрик, поиска дефектов и т.п.
Окружение (Environment)
Окружение, на котором найден дефект – операционная система, браузер, версия браузера, сервер и т.п. Если дефект воспроизводится на всех окружениях, то ставится соответствующий комментарий.
Описание * (Description)
Также чрезвычайно важный атрибут. Описание должно быть лаконичным и ясным, как и Summary, но в более развернутой форме. Если есть альтернативные шаги, то их также нужно указать. В описание можно оставлять любые полезные примечания – повторяемость, уточнения и т.п. Пример Description в баг репорте:
Если администратор заходит на страницу приветствия, то логотип пропадает.
Actual result: логотипа нет. (Реальный результат)
Expected result: логотип в правом верхнем углу. (Ожидаемый результат)
Requirement ID: #45 (пункт требований)
Reproduced on: Win10, IE11, 1200x800dpi (на чем воспроизводиться)
Workaround: Да, логотип отображается, если обновить страницу повторно
For more details, please, see attached files:
Как видно из примера Описание (Description) имеет набор атрибутов, которые входят в его состав, давайте некоторые поясним
Приложения (Attachments)
Любая информация, которая поможет воспроизвести ситуацию:
Воспроизводимость (reproducible, reproducibility)
Это поле показывает, воспроизводится ли баг всегда («always») или лишь иногда («sometimes»). Баги, воспроизводящиеся всегда, гораздо проще диагностировать.
Примечание:
Рекомендация: пройдитесь по своим шагам воспроизведения хотя бы 2-3 раза прежде, чем писать, что баг воспроизводится всегда.
Помните, что это задача тестировщика – доказать, что баг есть. Поэтому сразу же, как увидели баг, делайте скриншот. Даже если вам самому больше не удастся воспроизвести баг, возможно, программист по скриншоту поймёт, в чём дело.
Возможность «обойти баг» (workaround)
Это поле косвенно влияет на важность и срочность устранения ошибка. Если некое действие можно выполнить в обход сценария, приводящего к ошибке, поле принимает значение «да» («yes»), в противном случае – поле принимает значение «нет» («no»).
Шаги воспроизведения (steps to reproduce, STR)
Данная информация в отчёте об ошибке является крайне важной. Именно она позволяет разработчику быстро воспроизвести и устранить проблему. Это поле следует заполнять максимально подробно, т.к. будучи незнакомым с внутренней структурой приложения, тестировщик не может знать, какие из выполненных им действий наиболее существенны для диагностирования данной ошибки (steps в тест кейсе, в какой-то степени, похожи STR).
Несколько рекомендаций:
Пример:
Дополнительная информация (additional info)
В это поле можно писать всё то, что вы считаете необходимым отметить, но что не подходит для размещения в других полях.
Требования, тест-кейсы, среда нахождения ошибки, билд, рассуждения, комментарии, мысли, анализ возможных причин появления бага и путей его устранения – всё это пишется здесь.
Симптом (symptom)
Это поле показывает, к какой категории относится ошибка. Наиболее широко распространённые симптомы:
Примечание: Может ли у ошибки быть сразу несколько симптомов? Да, может. Но выбирать лучше самый важный (наиболее показательный).
Должен ли баг репорт содержать весь набор атрибутов?
Вроде бы, мы рассмотрели наиболее распространенные атрибуты для bug report. Все из перечисленных полей(атрибутов) заполняются создателем отчета. Поле приоритет редактируется менеджером проекта.
Отвечая на вопрос, нужно ли пользоваться всеми атрибутами, можно сказать, что в зависимости от требований и контекста ситуации конкретного проекта, выбранного процесса разработки набор полей отчета об инциденте может быть иным. Часто возникает необходимость добавления новых полей в отчет для сбора требуемых метрик. Процесс изменения состояний инцидентов также зависит от множества факторов. Названия полей в разных инструментах могут отличаться от описанных полей, но смысл остается прежним.
Основы тестирования. Как правильно составить баг-репорты
Зачем нужен хороший баг-репорт?
Это может повредить рабочему настрою тестировщиков, затронуть их профессиональную гордость, их эго.
Каковы качества хорошего баг-репорта в разработке программного обеспечения?
Любой может написать баг-репорт. Но не каждый может написать эффективный бар-репорт.
Вы должны уметь хорошо различать баг-репорт среднего качества и хороший баг-репорт. Как отличить хороший и плохой баг-репорты? Это очень просто, примените следующие характеристики и методы, чтобы качественно сообщить об ошибке.
Характеристики и методы включают в себя:
1) Наличие четко определенного номера ошибки:
Всегда присваивайте уникальный номер каждому сообщению об ошибке. Это, в свою очередь, поможет вам четко идентифицировать запись об ошибке. Если вы используете какой-либо инструмент автоматического формирования баг-репортов, то этот уникальный номер будет генерироваться автоматически каждый раз, когда вы делаете отчет.
Запишите номер и краткое описание каждой ошибки, о которой вы сообщили.
2) Воспроизводимость:
Если найденная вами ошибка не воспроизводима, то она никогда не будет исправлена.
Вы должны четко указать шаги для воспроизведения ошибки. Не принимайте и не пропускайте ни одного шага воспроизведения. Ошибку, которая описана шаг за шагом, легко воспроизвести и исправить.
3) Будьте конкретны:
Не пишите очерк о проблеме.
Пишите конкретно и по существу. Попытайтесь описать обнаруженную проблему минимальным количеством слов и максимально эффективным способом. Не объединяйте описания нескольких багов в одном отчете, даже если они кажутся похожими. Напишите разные отчеты для каждой проблемы.
Эффективный баг-репортинг
Отчеты об ошибках являются важным аспектом тестирования программного обеспечения. Эффективный баг-репорт хорошо понимается командой разработчиков и позволяет избежать путаницы или недопонимания.
Правильно составленный текст отчета про найденный баг очень важен для регистрации ошибки. Один из важных моментов, которые должен иметь в виду тестер, — это не использовать командный тон в отчете. Такой тон нарушает моральное состояние коллектива и создает нездоровые рабочие отношения. Используйте нейтральный тон.
Не думайте, что если разработчик допустил ошибку, то вы можете использовать грубые слова. Прежде чем сообщать, не менее важно проверить, был ли уже баг-репорт по этой ошибке ранее или нет.
Дубликаты ошибок — это постоянная проблема в цикле тестирования. Проверяйте весь список обнаруженных багов. Иногда разработчики могут знать о наличествующей проблеме и игнорировать ее в будущем выпуске. Используйте специальные инструменты, такие как Bugzilla, который автоматически ищет дубликаты ошибок. Тем не менее, лучше всего дополнительно вручную искать дубликаты ошибок.
Тема связана со специальностями:
Четко указывайте информацию об ошибке: «Как?» и «Где?». Отчет должен ясно показывать, как был выполнен тест и где именно произошел дефект. Читатель отчета должен легко воспроизвести ошибку и найти ее.
Кроме того, имейте в виду, что отчет об ошибках будет сохранен для будущего использования и должен быть хорошо написан и содержать необходимую информацию. Используйте содержательные предложения и простые слова, чтобы описать найденные ошибки. Не используйте запутанные утверждения, которые тратят время читателя.
Сообщайте о каждой ошибке как о отдельной проблеме. В случае описания нескольких багов в одном отчете, вы не сможете закрыть его, пока все проблемы не будут решены.
Следовательно, лучше всего разбить большие проблемы на отдельные баги. Это гарантирует, что каждая ошибка может быть обработана отдельно. Хорошо написанный баг-репорт помогает разработчику воспроизвести ошибку на своем терминале. Это помогает им также правильно диагностировать проблему.
Как сообщить об ошибке?
Используйте следующий простой шаблон баг-репорта:
Это простая форма баг-репорта. Его содержание может варьироваться в зависимости от используемого вами инструмента отчетов об ошибках. Если вы пишете баг-репорт вручную, то необходимо упомянуть некоторые поля, например номер ошибки, который должен быть назначен вручную.
Составитель отчета: Ваше имя и адрес электронной почты.
Продукт: В каком продукте вы нашли эту ошибку.
Версия: Версия продукта с ошибкой, если таковая имеется.
Компонент: Основные подмодули продукта.
Платформа:
Укажите аппаратную платформу, на которой вы обнаружили эту ошибку. Различные платформы, такие как «ПК», «MAC», «HP», «Sun» и т. д.
Операционная система:
Укажите все операционные системы, в которых вы обнаружили ошибку. Операционные системы, такие как Windows, Linux, Unix, SunOS, Mac OS. Упомяните разные версии ОС, такие как Windows NT, Windows 2000, Windows XP и т. д., если это применимо.
Приоритет:
Серьезность ошибки:
Описывает влияние ошибки.
Статус ошибки:
Когда вы регистрируете ошибку в любой системе отслеживания ошибок, то по умолчанию статус ошибки будет «Новый».
Позднее ошибка проходит через различные этапы, такие как «Исправлено», «Проверено», «Повторно открыто», «Не исправлено» и т. д.
Назначить разработчику:
Если вы знаете, какой разработчик отвечает за тот конкретный модуль, в котором произошла ошибка, вы можете указать адрес электронной почты этого разработчика. В противном случае оставьте это поле пустым, так как это присвоит полю авторства ошибки значение владельца модуля, если менеджер не назначит ошибку разработчику.
URL страницы, на которой произошла ошибка.
Краткое резюме:
Добавьте краткое описание ошибки. Ориентируйтесь на 60 слов или меньше. Убедитесь, что составленное резюме отражает проблему и место, где она находится.
Описание:
Подробное описание ошибки.
Это важные шаги в отчете об ошибках. Вы также можете добавить «Тип отчета» как еще одно поле, которое будет описывать тип ошибки.
Видео курсы по схожей тематике:
Автоматизация тестирования мобильных приложений
Unit тестирование в C#
Типы отчетов включают в себя:
1) Ошибка в коде
2) Ошибка проектирования
3) Новое предложение
4) Проблема с документацией
5) Аппаратная проблема
Важные фичи в вашем отчете об ошибках
Рассмотрим несколько составляющих отчета о найденном баге
Ниже приведены важные элементы баг-репорта:
1) Номер ошибки/идентификатор:
Номер ошибки или идентификационный номер (например, xyz007) значительно упрощает составление баг-репорта и поиск места ошибки. Разработчик может легко проверить, исправлена ли конкретная ошибка или нет. Это делает весь процесс тестирования и повторного тестирования более плавным и легким.
2) Наименование ошибки:
Заголовок ошибки читается чаще, чем любая другая часть баг-репорта. Стоит указать в нем всё о том, что входит в баг.
Название ошибки должно быть достаточно осмысленным, чтобы читатель мог его понять. Четкий заголовок ошибки облегчает понимание, и читатель легко сможет проверить, было ли сообщение об ошибке ранее и была ли она исправлена.
3) Приоритет:
В зависимости от серьезности ошибки, для нее может быть установлен приоритет. Ошибка может быть Blocker, Critical, Major, Minor, Trivial или предложением по улучшению функционала. Приоритет ошибки от P1 до P5 может быть задан так, чтобы важные из них просматривались первыми.
4) Платформа / Среда:
Указание конфигурации ОС и браузера необходимо для большей точности в баг-репорте. Это лучший способ сообщить о том, как можно воспроизвести ошибку.
Без точной платформы или среды приложение может вести себя по-другому, и ошибка на стороне тестировщика может не повторяться на стороне разработчика. Поэтому лучше четко указать среду, в которой была обнаружена ошибка.
5) Описание:
Правильное описание ошибки помогает разработчику понять ошибку. Оно описывает возникшую проблему. Плохое описание создаст путаницу и потратит время разработчиков и тестеров.
Необходимо четко сообщить об эффекте в описании. Всегда полезно использовать полные предложения. Рекомендуется описывать каждую проблему отдельно, а не разрушать их полностью. Не используйте такие термины, как «я думаю» или «я считаю».
6) Шаги для воспроизведения ошибки:
Хороший отчет об ошибке должен четко указывать шаги для воспроизведения. Шаги должны включать действия, которые вызывают ошибку. Не делайте общих заявлений. Будьте конкретны в следующих шагах.
Хороший пример правильно написанной пошаговой процедуры приведен ниже:
7) Ожидаемый и фактический результат:
Описание ошибки будет неполным без указания ожидаемых и фактических результатов. Необходимо обрисовать в общих чертах, каков результат теста и что ожидал бы пользователь в случае корректной работы программы. Читатель отчета должен знать, какой результат теста будет корректным. Ясно упомяните, что произошло во время теста и каков был результат.
8) Скриншот:
Одна картинка стоит тысячи слов. Сделайте скриншот с примером сбоя с соответствующими выделениями, чтобы указать дефект. Выделите неожиданные сообщения об ошибках светло-красным цветом. Это привлекает внимание к необходимой области.
Некоторые дополнительные советы, для написания хорошего баг-репорта
Ниже приведены некоторые дополнительные советы, чтобы написать хороший отчет об ошибке:
1) Немедленно сообщите о проблеме:
Если вы обнаружите какую-либо ошибку во время тестирования, не нужно ждать, чтобы написать подробный отчет об ошибке позже. Вместо этого напишите отчет об ошибке немедленно. Это обеспечит хорошее качество отчета и воспроизводимость шагов получения ошибках. Если вы решите написать отчет об ошибке позже, есть большие шансы пропустить важные детали в баг-репорте.
2) Воспроизведите ошибку три раза перед написанием баг-репорта:
Ваш баг должен быть воспроизводимым. Убедитесь, что ваши шаги достаточно четкие, чтобы воспроизвести ошибку без какой-либо двусмысленности. Если ваша ошибка не воспроизводима каждый раз, вы все равно можете подать ошибку, указав периодическую природу бага.
3) Протестируйте эту же ошибку на других похожих модулях:
Иногда разработчик использует один и тот же код для разных похожих модулей. Таким образом, вероятность того, что ошибка в одном модуле возникнет и в других подобных модулях, выше. Вы даже можете попытаться найти более серьезную версию найденной ошибки.
4) Составьте хорошее резюме ошибки:
Краткое описание ошибки поможет разработчикам быстро проанализировать природу ошибки. Низкое качество отчета излишне увеличит время разработки и тестирования. Правильно взаимодействуйте с вашим баг-репортом. Имейте в виду, что сводка об ошибках используется в качестве справочной информации для поиска ошибки в инвентаре ошибок.
5) Прочитайте несколько раз отчет об ошибке, прежде чем нажать кнопку «Отправить»:
Прочитайте все предложения, формулировки и шаги, которые используются в баг-репорте. Посмотрите, не создает ли какое-либо предложение двусмысленность, которая может привести к неправильной интерпретации. Следует избегать вводящих в заблуждение слов или предложений, чтобы составить четкое сообщение об ошибке.
Бесплатные вебинары по схожей тематике:
Мануальное тестирование API
QA практикум. Техники тест дизайна. Часть 2
QA практикум. Техники тест дизайна. Часть 1
6) Не используйте оскорбительные выражения:
Приятно, что вы проделали хорошую работу и обнаружили ошибку, но не используете это для критики разработчика или нападок на какого-либо человека.
Заключение.
Мы рассмотрели некоторые особенности составления отчета про найденный баг. Нет сомнений, что ваш баг-репорт должен быть качественным документом.
Сосредоточьтесь на написании хороших отчетов об ошибках и потратьте некоторое время на выполнение этой задачи, потому что именно качественный баг-репорт является основной точкой связи между тестером, разработчиком и менеджером. Менеджеры со своей стороны должны объяснить своей команде, что составление хорошего отчета об ошибках является основной обязанностью любого тестировщика.
Ваши усилия по написанию хорошего отчета об ошибках не только сохранят ресурсы компании, но и создадут хорошие отношения между вами и разработчиками.
Для лучшей производительности команды стремитесь написать лучший отчет об ошибках.