Один багрепорт сообщение об ошибке должен содержать

Профессия тестировщика ПО очень многогранна, ведь она требует внимания к деталям, креативности, коммуникативных навыков и усидчивости. Последнее качество особенно пригодится для такой части работы 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-процесса, который позволяет ускорить устранение дефекта и подготовить качественное ПО к выходу на рынок. До начала написания документа важно:

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

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

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

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

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

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

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

• Где возникла проблема?
• Что именно работает не так, как ожидалось?
• Какие действия нужно выполнить, чтобы воспроизвести ошибку?

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

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

Основные компоненты баг-репорта.

Давайте рассмотрим каждый раздел отчёта об ошибке и поговорим о том, на что стоит обращать внимание при написании. 
‍

Заголовок.

Заголовок — это та часть репорта, которую разработчики видят первой. Он должен представлять собой краткое описание бага. Общие заголовки вроде «Поиск не работает» не очень полезны. Что именно не работает? Система выдаёт результаты, не соответствующие запросу? Поиск длится слишком долго? Вариант «При нажатии на кнопку поиска функция не срабатывает» более информативен. Хорошие заголовки снижают вероятность появления дублирующихся репортов, а также позволяют разработчику быстрее найти нужный ему отчёт.   
‍

Описание бага.

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

• Шаги для воспроизведения бага. 

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

1. Перейти на страницу входа в систему.
2. Ввести правильное имя пользователя.
3. Ввести неправильный пароль.

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

• Фактические и ожидаемые результаты. 

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

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

Фактический результат: Не удаётся войти в учётную запись. Появляется сообщение об ошибке «Неверное имя пользователя”.

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

Приложения 

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

Критичность и приоритет (Severity, Priority)

Эти разделы подсказывают, насколько серьёзные последствия может вызвать обнаруженная ошибка и как срочно её нужно устранить. Обычно багам присваивается один из 6 уровней критичности: блокирующий, критический, серьёзный, незначительный, тривиальный, предлагаемое улучшение. В зависимости от критичности проблемы ей назначается высокий, средний или низкий уровень приоритета. 
‍

Программно-аппаратное окружение (Environment) 

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

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

Инструменты для отслеживания ошибок или баг-трекеры. 

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

• Создавать баг-репорты. 
• Присваивать ошибкам приоритет.
• Менять статус бага на разных этапах его жизненного цикла (например, новый, открыт, отклонён, исправлен и т.д.).    
• Назначать ответственных за выполнение той или иной задачи. 
• Искать, фильтровать и сортировать ошибки по различным параметрам: по названию, критичности, идентификационному номеру и т.д.

Вот краткий обзор десяти популярных инструментов для отслеживания ошибок. 
‍

JIRA

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

Bugzilla

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

Trello

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

Asana

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

Redmine

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

FogBugz

FogBugz — веб-система управления проектами с функциями для отслеживания ошибок, управления задачами и учёта рабочего времени. 

YouTrack

YouTrack — это веб-система для отслеживания ошибок и управления проектами, разработанная компанией JetBrains. Она позволяет фиксировать дефекты, планировать спринты, управлять задачами и составлять отчёты о проделанной работе. 

Backlog 

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

Zoho Bug Tracking

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

BugHerd

BugHerd — инструмент, который позволяет собирать отчёты о работе сайта прямо на его страницах. 

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

О чём стоит помнить при составлении баг-репортов? 

Вот несколько принципов, которых стоит придерживаться:

• Один отчет — одна ошибка. Даже если вы обнаружили проблемы в одном и том же месте, создавайте отдельные репорты для каждого бага. Если описывать несколько в одном отчёте, это только запутает читателя и он может упустить какой-то из дефектов. Кроме того, статус такого репорта невозможно будет изменить, пока разработчики не исправят все перечисленные в нём ошибки. И разобраться, как продвигается работа, будет сложнее.
• Избегайте дубликатов. Прежде чем создавать новый баг-репорт, проверьте, если проблема уже не была описана ранее.  
• Воспроизведите ошибку несколько раз, чтобы убедиться, что вы не пропустили ни одного важного шага в инструкциях для разработчиков. Если у вас не получается повторить проблему каждый раз, упомяните об этом и укажите коэффициент воспроизводимости (например: 7/10 раз баг воспроизводится).
• Придерживайтесь фактов и не стройте предположений о том, что могло стать причиной дефекта. Это может задать разработчикам неверное направление мысли и отсрочить устранение ошибки.  
• Всегда будьте вежливы, не обвиняйте и не критикуйте коллег. Ваша работа как тестировщика заключается в обеспечении высокого качества продукта, а не в оценке чьей-то работы. 
• И наконец, перечитайте свой отчёт, прежде чем отправить его. Он должен быть кратким, понятным и содержать всю необходимую информацию. 

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

Полезные ссылки

https://www.atlassian.com/software/jira

https://www.bugzilla.org/ 

https://trello.com/en

https://asana.com/

https://www.redmine.org/ 

https://fogbugz.com/ 

https://www.jetbrains.com/youtrack/ 

https://backlog.com/ 

https://www.zoho.com/bugtracker/ 

https://bugherd.com/

Запись на курс Manual QA

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

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

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

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

Environment — есть во всех баг-трекерах. Это программно-аппаратное окружение, в котором проявляется проблема.
Укажите версию операционной системы, наличие сервис-паков, разрядность.
Если ваш проект зависит от каких-то компонентов — их наличие и версии обязательно! .NET, JRE/JDK и прочие SDK.
Интерпретируемый язык? Версию интерпретатора — обязательно!
Для веб-проектов — браузер, установленные плагины, если это влияет на работу проекта. Если что-то не работает в одном браузере, то проверьте, работает ли в остальных.

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

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

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

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

Виды багов

• Функциональные. Возникают, когда фактический результат работы не соответствует ожиданиям: не получается опубликовать комментарий на сайте, добавить товар в корзину или открыть страницу.
• Визуальные. Это случаи, когда приложение выглядит иначе, чем задумано: кнопка накладывается на текст, не отображаются картинки или текст выходит за пределы окна.
• Логические. Баг, при котором что-то работает неправильно с точки зрения логики, — например, когда можно указать несуществующую дату (31 февраля) или поставить дату рождения из будущего (2077 год).
• Дефекты UX. Приложение или программа неудобны в использовании: при просмотре ленты новостей пользователя постоянно отбрасывает к началу, слишком близко расположены кнопки и вместо одной нажимается другая.
• Дефекты безопасности. Случаи, когда из-за ошибки в коде данные пользователей (почты, пароли, фото, информация о платежах) могут быть доступны третьим лицам.

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

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

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

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

• S0 Trivial (Тривиальный) — баг не влияет на работу программы, поэтому для его исправления могут не выделить отдельную задачу, а исправить попутно при исправлении других, похожих ошибок. Например, при заполнении анкеты в поле «Дата рождения» по умолчанию отображается не актуальный год, а 1999-й.
• S1 Minor (Незначительный) — баг почти не нарушает логику процессов, поэтому с ним программа может нормально работать. Например, неудобная навигация в интерфейсе.
• S2 Major (Серьезный) — баг создает неудобства в использовании, но еще не нарушает функционал программы.
• S3 Critical (Критический) — баг мешает приложению выполнять основные функции: калькулятор расходов неправильно считает бюджет или в текстовом редакторе невозможно вводить текст.
• S4 Blocker (Блокирующий) — ситуация, когда программа не работает в принципе: сайт выдает «ошибку 404» или не запускается приложение.

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

• P1 Высокий — исправляется в первую очередь, так как баг ломает работу приложения.
• P2 Средний — обязательный к исправлению баг после критического.
• P3 Низкий — не требует немедленного решения.

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

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

• Открыт (Open) — тестировщик выявил баг и добавил в репорт.
• В работе (In Progress) — о баге сообщили исполнителю, и он занимается исправлением.
• Исправлен (Ready for check) — исполнитель закончил работу по исправлению бага и передал проект на повторную проверку тестировщику.
• Закрыт (Closed) — баг устранен и больше не воспроизводится.

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

• Отклонен (Rejected) — исправлению бага помешала ошибка в репорте, например неверный алгоритм в пункте «Шаги к воспроизведению».
• Отсрочен (Deferred) — баг признан неприоритетным и исправление переносится.
• Переоткрыт (Reopened) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

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

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

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

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

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

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

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

• Заголовок
• Описание
• Устройство / Браузер
• Окружение
• Прикрепления
• Приоритет/Серьезность

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

Многие могут сказать, что оформить баг-репорт очень просто и не требует специфических знаний, но так ли это просто на самом деле?

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

Давайте рассмотрим элементы баг-репорта по очереди и узнаем, как написать действительно классный репорт!

Заголовок (Title)

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

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

Рассмотрим следующий тайтл: «Проблема с кнопкой настроек».

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

Теперь сравните с этим: «Кнопка настроек становится неактивной после клика по ее праовму краю».

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

Описание (Description)

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

Наиболее важными элементами описания являются:

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

Почему мы обратили внимание на релевантность информации в описании? Потому что слишком много информации тоже может быть проблемой. Давайте рассмотрим следующий пример:

Шаги для воспроизведения:

• Откройте приложение и перейдите в «Личный кабинет»
• Откройте страницу настроек пользователя и измените аватар
• Сохраните аватар
• Попытайтесь установить дату рождения в будущем
• Увидев сообщение об ошибке, закройте страницу настроек пользователя
• Закройте приложение
• Снова откройте приложение
• Перейдите в «Личную кабинет»
• Кликните на правый край кнопки «Настройки»
• Результат: Кнопка «Настройки» переходит в неактивное состояние, хотя должна оставаться активной.

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

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

Шаги для воспроизведения:

• Откройте приложение и перейдите в «Личный кабинет»
• Кликните на правый край кнопки «Настройки»
• Результат: Кнопка «Настройки» переходит в неактивное состояние, хотя должна оставаться активной.

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

Устройство / Браузер

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

То же самое касается браузеров — это не только название, но и версия, тип операционной системы, в которой работает браузер, разрешение экрана, установленные расширения — все может быть важно!

Окружение (Environment)

Это поле имеет отношение к среде, в которой проводилось тестирование, т.е. staging, development, UAT, production — и любой ее подтип/версия (в зависимости от проекта). Не забудьте добавить версию приложения! Хороший баг-репорт также будет содержать информацию о том, является ли баг проблемой регрессии (т.е. впервые возникла в последней версии приложения) или это проблема, которая существовала в предыдущих версиях, но не была обнаружена при тестировании прошлых версий. Это очень важно знать. Если ошибка возникла только что, то легче выяснить, что ее вызвало (т.е. одно из последних изменений), но если ошибка не новая (уже существовала в предыдущих версиях), то поиск и исправление могут быть не такими оперативными.

Прикрепленные файлы — скриншоты, видео, логи и т.п. (Attachments)

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

При добавлении вложения действует то же правило, что и для описания: не прикрепляйте нерелевантную информацию! Представьте себе 5-минутное видео, в котором показан весь процесс регистрации пользователя, работы с приложением, воспроизведения множества сценариев, только для того, чтобы в последние 5 секунд показать, что кнопка «Настройки» становится неактивной! Прикрепите только тот 5-секундный фрагмент видео, который имеет отношение к делу.

Приоритет / Серьезность (Priority / Severity)

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

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

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

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