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

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

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

Виды багов

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

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

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

ID	Идентификационный номер, который присваивается конкретному багу
Краткое описание (также может называться Title или Summary)	Раздел, который кратко передает суть бага одним предложением. Отвечает на вопросы «Что?», «Где?», «При каких обстоятельствах?» Неправильно: «Проблемы с кнопкой» Правильно: «При нажатии на кнопку “Зарегистрироваться” на главной странице не открывается форма регистрации»
Проект	Название проекта, программы или приложения, в котором выявлен баг
Версия	Точная версия ПО, содержащая баг. Например, последняя версия iOS (операционной системы iPhone) — V 14.7.1
Серьезность бага	Параметр, который определяет влияние бага на работу программы по шкале от S0 до S4
Приоритет	Параметр, который определяет срочность исправления бага по шкале от P1 до PЗ
Статус	Определяется в зависимости от того, на какой стадии находится баг: открыт, в работе, исправлен, отклонен, отсрочен и т.д.
Автор	Создатель баг-репорта
Исполнитель	Разработчик, который будет устранять баг
Шаги к воспроизведению	Точная последовательность действий, которая приводит к тому, чтобы воспроизвести баг
Фактический результат	К чему приводит воспроизведение шагов, как сейчас работает программа
Ожидаемый результат	Как должна работать программа на самом деле и к чему должны приводить действия, описанные в пункте «Шаги к воспроизведению»
Дополнения	Ссылки, скриншоты, видео и другие материалы, которые помогут исполнителю лучше понять суть проблемы

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

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

• 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) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

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

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

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

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

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

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

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

Любая компания по разработке программного обеспечения стремится к тому, чтобы продукт, который она создаёт, был высочайшего качества. Для того, чтобы этого добиться, 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

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

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

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

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

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

Каналы поступления багов

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

• В процессе тестирования — функционального и нефункционального.
• Обращение клиента (заказчика) с информацией о возникшей проблеме.
• Баги, выявленные пользователями. Соответствующая информация может быть передана как разработчикам, так и заказчику.
• Ошибки полученные при помощи систем мониторинга, например Sentry, Errbit, Crashlytics.

Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму. Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.

Направления работы отдела QA

С каналами поступления информации о багах мы определились. Теперь перейдем к направлениям работы QA инженеров. Их несколько:

• Веб-приложения;
• Мобильные приложения (iOS и Android);
• API (как часть мобильного или веб-приложения или или же в качестве самостоятельного проекта);

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

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

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

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

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

Чего делать нельзя? Нельзя информировать сразу о нескольких проблемах в пределах одного баг репорта. Закон джунглей: один bug report = одна проблема. Не ленитесь.

Чем плох баг репорт с несколькими проблемами в пределах одной задачи? Это значительно замедляет процесс их устранения. Следите за руками: после починки дефекта разработчик переназначает задачу на QA специалиста для проверки. Если мы имеем несколько проблем в одной задаче – разработчик не сможет отдать их на проверку, пока не устранит каждую из них. Чувствуете как утекает время? Когда же все баги упакованы в отдельную задачу, QA специалист может приступить к проверке исправлений значительно раньше. Таким образом, жизненный цикл бага (переоткрытие, закрытие) проходит быстрее, и программное обеспечение быстрее продвигается к релизу.

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

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

К слову, баг репорт состоит не только из описания. Любое сообщение о дефекте включает в себя два элемента:

• заголовок;
• описание.

Рассмотрим каждый из них в отдельности.

Заголовок

При составлении заголовка мы используем золотое правило: “Что? Где? При каких условиях?”. Заголовок — это первое, что увидят разработчики, менеджер проекта или ваши коллеги — QA специалисты. Сделав его максимально простым, точным и понятным, вы сразу же зададите верное направление. Итак, заголовок отчета об ошибке должен:

• Содержать предельно краткую, но в то же время достаточную для понимания сути проблемы информацию о баге;
• Ответить на три вопроса: Что? Где? И при каких условиях? (или хотя бы на те 1-2 вопроса, которые применимы к конкретной ситуации);
• Быть достаточно коротким, чтобы полностью помещаться на экране (имеются в виду баг-трекинговые системы, где заголовок обрезается или приводит к необходимости скроллинга);
• Содержать информацию об окружении, под которым был обнаружен баг (в зависимости от типа проекта);
• Быть законченным предложением русского или английского языка, построенным в соответствии с правилами грамматики.

Давайте рассмотрим работу с заголовком на простом примере:

1. Ситуация: поле описания товара в веб-приложении должно допускать ввод максимум 250 символов. В процессе тестирования выяснилось, что необходимое ограничение отсутствует (вводится хоть миллион символов).
2. Суть проблемы: исследование показало, что ни на клиентской, ни на серверной стороне нет никаких механизмов, проверяющих и/или ограничивающих количество символов, вводимых в поле описания товара.
3. Используем золотое правило. Что: отсутствует проверка и ограничение длины вводимого текста. Где: поле описания товара. При каких условиях: при любых, то есть — всегда.
4. Формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле описания товара.
5. Сокращение (итоговое summary): Нет ограничения максимальной длины поля «Описание».
6. Англоязычный вариант: No check for max length of Description field.

Небольшой комментарий к информации об окружении и проектных традициях. Приведем простой пример. Мы имеем дело с проектом, в пределах которого разрабатывается мобильное приложение под две платформы: iOS и Android. В зависимости от того, к какой платформе привязан баг, в заголовке указываем: iOS или Android. Например, “iOS. Application accepts dates of birth from the future.”.

Дополнительный вариант — использование так называемых ярлыков (labels). Некоторые системы отслеживания ошибок предоставляют соответствующий функционал.

Описание

Переходим ко второму компоненту bug report. Описание должно содержать следующую информацию:

1. Подготовительные операции, то есть действия, обеспечивающие возможность воспроизведения проблемы.
2. Шаги воспроизведения. Сразу заметим: везде нужна золотая середина. Категорически запрещается пропускать важные шаги. Но в то же время не следует разжевывать очевидные вещи. Например, вставлять скриншоты в каждый отчет об ошибке совершенно не обязательно. Не плодите лишние сущности. Если они ничем не помогут в воспроизведении проблемы — не тратьте время на их изготовление.
3. Актуальный результат.
4. Ожидаемый результат.
5. Дополнительная информация: различного рода уточнения, логины, пароли и прочее. Все, что может понадобиться в процессе воспроизведения проблемы.
6. Уровень проблемы. Чаще всего используются следующие уровни (это не панацея, в зависимости от традиций компании или типа используемой системы отслеживания багов, названия уровней могут меняться):

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

При работе с Pivotal Tracker мы привыкли маркировать уровни проблемы цифровым значением от 1 до 4, это значение указывается в качестве label. По уровням градация следующая: 1 — это Blocker и Critical, 2 — это Major, 3 — это Minor и 4 — это Trivial. Такая градация уровня проблемы используется на всех проектах, которые ведутся в Pivotal Tracker.

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

• Подготовительные операции. Самый простой пример: авторизация перед совершением каких-либо действий в панели управления.
• Шаги воспроизведения проблемы. Последовательность действий, приводящих к возникновению (проявлению) дефекта. Шаги могут сопровождаться скриншотами или видео. Однако наличия набора медиафайлов недостаточно. Текстовое описание шагов должно присутствовать всегда и в обязательном порядке.
• Актуальный результат — ошибка или поведение ПО, не соответствующее описанию в спецификации проекта.
• Ожидаемый результат — описание типового поведения ПО, без ошибки и соответствующего описанию в спецификации проекта.
• Информация об окружении, если она необходима для воспроизведения бага (версия приложения и/или браузера, операционная система, разрешение экрана, логин и пароль, примеры файлов, локализация)
• Уровень проблемы (minor, major, critical или blocker).

Примеры

Пример #1

Один из баг репортов для мобильного приложения. Проект ведется в Pivotal Tracker. Уровню проблемы присваивается значение в диапазоне от 1 до 4, где наиболее важные моменты — это “1” и далее по убыванию. Приложение разрабатывалось сразу под две платформы — Android и iOS. Поэтому мы решили прописывать платформу в заголовок задачи.

Переходим к составляющим баг репорта:

Заголовок — Android. About Track screen. Nothing happens after tap on the Label. Как было сказано выше, мы указываем платформу, тем самым  отвечая на вопрос “где?”. То есть: на платформе Android, на экране About Track. Далее мы отвечаем на вопросы “что?” и “когда?” — Nothing happens after tap on the Label.

Так как отдельных полей о тестовом окружении в Pivotal Tracker не предусмотрено, мы добавляем информацию о билде (Build v2.0.6) и версии Android, на которой был воспроизведен баг (Android 6.0), в поле Description.

В этом же поле прописываем шаги воспроизведения бага:

1. Open a track with related Label (as the example EDX — My Friend Extended Mix)
2. Tap on the Info icon (top right corner)
3. Tap on the Label name, nothing happens

И ожидаемый результат: Expected behaviour: Label screen should be opened.

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

Пример #2

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

Кликните на изображение для увеличения

Проект также велся в Pivotal Tracker, поэтому уровень проблемы был указан с помощью label. Использовалась аналогичная шкала (от 1 до 4). Мы присвоили проблеме уровень “2”, так как отсутствие данной в ответе метода не позволяло выполнить некоторые операции в профиле пользователя.

Итак, заголовок — The method «View User Profile» should return information about user’s location. Мы совершенно отчетливо указываем на метод и проблему. Далее в поле Description мы даем понять, что речь идет о стейджинге.

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

     Email:
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript

     Password: qwerty

     Token: xVjowqgm-FHjNwB9tAbG

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

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

Expected attributes:

• Location name (location_name)
• location ID (location_id)
• location type (location_type).

Выводы

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

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

Использование общих шаблонов и практик дизайна отчетов об ошибках в пределах компании позволяет существенно сократить время коммуникации между разработчиками и QA специалистами. Дело в том, что согласование задач (то есть случаи, когда разработчики возвращают тестировщикам задачи со статусами rejected, can’t reproduce, more info) зачастую существенно затягивается. Соблюдение же правил написания bug reports позволяет решить эту проблему. В результате мы экономим кучу драгоценного времени. Даже не сомневайтесь, что заказчики и пользователи ПО оценят это положительно.

Обсудить в форуме

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

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

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

Если кратко, то хороший баг-репорт позволяет:
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.
Интерпретируемый язык? Версию интерпретатора — обязательно!
Для веб-проектов — браузер, установленные плагины, если это влияет на работу проекта. Если что-то не работает в одном браузере, то проверьте, работает ли в остальных.

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

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