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

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

На Хабре достаточно много написано про хороший стиль программирования, 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. И не забывайте про золотое правило — пишите отчеты об ошибках так, чтоб вам их было приятно читать

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

Ошибка №1. Использование принципа «что, где, когда» в ситуации, когда «где» и «когда» должны быть пропущены

По правде говоря, внутри темы, не всегда обязательно использовать ответы только на вопрос «что?».

Некоторые ситуации требуют пропуска «где и когда», но только в случае, если они точно не могут нести в себе никакой информативности.

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

Неверный вариант / Корретный вариант

Одно из изображений слайдера не отображается на слайдере при входе на сайт. / Одно из изображений слайдера не отображается на слайдере.

Ошибка №2. Нет префикса внутри темы баг-репорта

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

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

Ошибка №3. Избыточность текста в предусловиях

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

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

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

Ошибка №4. Полное отсуствие важных дополнительных данных или шагов для воспроизведения дефекта

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

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

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

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

Ошибка №5. Нет описания или отсутствует ссылка на главный домен в теле тестового шага

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

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

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

Ошибка №6. В шагах внесены ссылки на определенные страницы веб-сайта

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

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

Ошибка №7. Подробное описание ошибок в последнем тестовом шаге

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

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

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

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

Ошибка №8. Один из результатов описан в форме отрицания другого

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

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

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

Неверный вариант

Фактический результат: отображение системной ошибки на форме регистрации в поле ввода пользовательского номера телефона.

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

Корректный вариант

Фактический результат: отображение ошибки на форме ввода телефона после ввода валидного значения в соответствующее поле.

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

Ошибка №9. Лишние атрибуты на скриншоте или отсутствие требуемых

Фото или видеофайл должны полностью отображать видимость используемой части веб-страницы в браузере с адресной строкой.

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

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

Ошибка № 10. Присутствие на видеозаписи посторонних или отвлекающих звуков и шумов

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

Одна из частых ошибок при записи видео – наличие постороннего звука.

Подобные вещи решаются очень просто: при записи видео необходимо отключать возможность записи аудиодорожек.

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

Ошибка №11. Постоянное отображение ненужных уведомлений на скриншоте или видео

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

Ведь такие объекты могут отвлекать от багов и могут (но не всегда) содержать конфиденциальную информацию пользователей.

Ошибка №12. Наличие «простого» скриншота при сложном описании функционального дефекта

Для любого функционального бага, порой, недостаточно одного простого скриншота с отмеченной ошибкой.

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

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

Ошибка №13. Наличие нескольких акцентов на скриншотах

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

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

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

Ошибка №14. Фиксирование бага на скриншоте цветом, который не контрастный с цветом дизайна

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

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

Ошибка №15. Отсутствие видео крэшов с устройств и файла логов во вложении к описанию бага

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

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

Завершение

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

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

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

Баг-репорт включает обязательные и необязательные элементы.

Обязательные поля:

• ID — идентификационный номер баг-репорта, должен быть уникальным. Помогает быстро найти нужный баг-репорт.
• Заголовок — передает суть ошибки; помогает быстро понять, в чем дело.
• Шаги воспроизведения — пошаговая инструкция о том, как воспроизвести ошибку.
• Результаты — описание фактического результата и ожидаемого результата.
• Окружение — операционная система, браузер, устройство (в случае мобильного приложения), версия приложения.
• Приоритет — показывает степень критичность ошибки и срочность ее исправления.

Необязательные поля:

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

Пример правильно составленного баг-репорта:

Теперь давайте поговорим о каждом пункте немного детальнее.

Заголовок баг-репорта

Задача заголовка — в достаточной мере описать суть проблемы. Грамотно написанный заголовок помогает коллегами сразу понять суть, не тратя время на прочтение всего баг-репорта целиком. Заголовок должен отвечать на три вопроса: «Что? Где? Когда?», при этом не должен быть слишком длинным. Заголовок должен отражать реальный результат.

Примеры удачных заголовков:

• Клик по слову «Регистрация» на странице подписки приводит к ошибке 400.
• При переходе по ссылке «Заказ» на главной странице экрана открывается страница Контакты вместо страницы Мои заказы.

Шаги

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

Приоритет и серьезность

Приоритет (priority) отражает степень важности проблемы и срочность выполнения задачи, включает 3 уровня: 

• Высокий (high) — необходимо исправить в первую очередь, так как с данной ошибкой продукт не выполняет свой бизнес-задачи: например, не работает кнопка заказа в интернет-магазине.
• Средний (medium) — ошибка менее критичная, пользователь может достигнуть цели, однако ПО работает не так, как от него ожидается. Например, в корзине интернет-магазина не отображается блок сопутствующих товаров.
• Низкий (low) — не мешает пользователю достигнуть цели, можно починить после критических ошибок. Например, опечатки в тексте.

Серьезность (severity) показывает степень влияния на работу системы. 

• Блокирующий (blocker) — программа не работает. Например, сайт выдает ошибку 500.
• Критический (critical) — не работает важная часть системы, приложение не выполняет своей функции. Например, невозможно добавить товар в корзину незарегистрированному пользователю.
• Серьезный (major) — приложение работает, функциональность не пострадала, однако работает некорректно. Например, не позволяет пользователю выбрать марку авто в приложении по заказу такси.
• Незначительный (minor) — приложение работает правильно, но вызывает какие-либо неудобства. Сюда можно отнести ошибки навигации и другие ошибки UX-характера.
• Тривиальный (trivial) — ошибка, которая не оказывает никакого влияния на работу приложения. Например, опечатки в тексте.

Окружение

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

Вложения (вспомогательные материалы)

Помогают дополнить информацию о проблеме, визуализируют ошибку. К баг-репорту можно прикрепить:

• Скриншоты и скринкасты
• Логи, дампы
• Переписки
• Документацию

Не забывайте давать вложениям понятные названия. Можно использовать маску {ID баг-репорта}_{суть ошибки}.

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

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

Один из примеров ― баг-репорт (от англ. bug report ― отчёт об ошибке), который содержит описание всех найденных дефектов в работе приложения. Не имеет значения, тестируете ли вы компьютерную игру, приложение для банка или сайт онлайн-магазина ― составление правильного отчёта является залогом продуктивного QA-процесса.

Баг-репорт содержит ответы на следующие вопросы:

• что идёт не так;
• где проявляется дефект;
• когда ошибка воспроизводится.

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

Разберёмся, как добиться этого сочетания.

Как выявляют баги?

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

1. во время проведения тестирования ПО;
2. при обращении заказчика с описанием ошибки;
3. из сообщений пользователей, которые столкнулись с проблемами во время использования программного продукта.

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

Какой инструмент используют для документирования дефектов?

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

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

Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.

Каких правил придерживаться при написании баг-репорта?

Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.

Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.

Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.

Правило №4: удостоверьтесь в воспроизводимости ошибки до заведения баг-репорта, повторите свой алгоритм действий и по возможности сократите число шагов.

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

Если всё в порядке, можно переходить к описанию.

Из каких элементов состоит баг-репорт?

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

Summary (заголовок)

Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Где? Что? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.

Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:

«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».

При тестировании мобильных приложений важно внести и название платформы, iOS или Android.

Заголовок готов. Можем двигаться дальше.

Description (описание)

Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:

1. переход на сайт menyaemsya.com;
2. вход или регистрация;
3. нажатие кнопки «Добавить объявление»;
4. ввод символов в поле «Описание».

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

«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».

Actual/expected result (фактический/ожидаемый результат)

Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.

Пример заполнения данного раздела:

«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».

Attachments (вложения)

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

Priority (приоритет)

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

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

• P1 High (высокий приоритет);
• P2 Medium (средний приоритет);
• P3 Low (низкий приоритет);

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

Severity (серьёзность)

Ошибки имеют и другую характеристику ― степень серьёзности влияния на систему.

• Blocker — это статус для проблем, которые прерывают работу приложения.
• Critical — такой баг значительно влияет на работоспособность, но не приводит к блокировке.
• Major — ошибка, которая не способствует фундаментальным изменениям, но может привести к незначительным искажениям отображения информации или выполнения некоторых функций.
• Minor — не влияет на работу системы. К этой категории можно отнести ошибки в текстовых блоках или визуальных решениях.

Status (статус)

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

• New – новый баг;
• Feedback – требуется обратная связь;
• Acknowledged – с содержанием документа ознакомились;
• Accepted – ошибка воспроизвелась и была подтверждена;
• Assigned – исправление ошибки назначено;
• Resolved – изменения были внесены;
• Closed – дефект больше не воспроизводится.

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

• Environment/platform – среда, платформа или операционная система;
• Fix version – этап разработки ПО на момент выявления бага;
• Assignee – пользователь, которому предстоит утвердить или исправить дефект;
• Lable – категория ошибки (текст, визуальные элементы и прочее).

Резюмируем

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

• убедиться в воспроизводимости ошибки;
• оценить поведение системы на разных платформах (при необходимости);
• проверить дефект на уникальность в баг-трекинговой системе.

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

Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!

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

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

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

2. Данные на форме «Профайл» не
   сохраняются после нажатия кнопки
   «Сохранить».

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

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

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

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

• Когда?: В какой момент работы
  программного продукта, по наступлению
  какого события или при каких условиях
  проблема проявляется.

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

Серьезность

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

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

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

Например:

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

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

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

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

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

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