Баг репорт отчет об ошибке

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

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

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

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

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

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

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

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

Уровень сложности
Простой

Время на прочтение
3 мин

Количество просмотров 1.4K

Чтобы написать bug report(отчет об ошибке) в Jira необходимо выполнить несколько действий, которые ты узнаешь на примере «боевой» жиры. Уверен, что общую концепцию поймешь.

Далее ты узнаешь:

• Что такое Jira?

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

Что такое Jira?

Jira — это система управления проектами и отслеживания задач, которая используется командами разработки программного обеспечения.

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

Jira помогает командам разработки эффективно управлять проектами и обеспечивать успешную доставку программного обеспечения.

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

1). Перейдите в Jira и нажмите кнопку «Создать».

2). Выберите тип проблемы «Ошибка» из списка вариантов.

3). Заполните поле сводки кратким описанием проблемы(summary), например такой шаблон: «путь до бага» — «какая проблема?», «когда?», «где?». Заголовок можно по разному строить.

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

5). Напишите шаги для воспроизведения в специальное поле. Рекомендую в виде пронумерованного списка.

6). Прикрепите к проблеме любые соответствующие файлы, например снимки экрана и/или файлы журнала(логи, иные файлы), возможно еще какие либо ярлыки, компоненты.

7). Установите уровень приоритета проблемы в зависимости от серьезности ошибки и срочности ее исправления.

8.) По серьезности (Severity) бага в большинстве случаев, на практике, остаются пустым, по моему опыту, потому что тут разрабу виднее и то даже они часто оставляют это поле пустым.

9.) Назначьте проблему на разработчика или на другого члена команды, ответственному за дальнейшую судьбу ошибки (поле Assignee) на определенном этапе её решения.

Данный пункт, также зависит от договоренности внутри команды, потому что бывает данное поле остается пустым или назначается аналитик, PM, или сразу разработчик. В моем опыте было так, что я мог сразу бывает так, что несколько пр в сборку попало разработчика или аналитика(было, что человек был лицом совмещающий PM, PO и должность аналитика), а было назначаешь только менеджера или вообще пусто.

Заполните поле сводки кратким описанием проблемы.

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

Указывать номер билда и/или commit hash — НЕ обязательно. Тут не особо принципиально, потому что если в девелопе, то следующие билды тоже будут с багой. По хэшу коммита, а если их несколько в таске? Вряд ли угадаешь в каком косяк. Еще бывает так, что несколько PR в сборку попало. Данное требование может возникнуть в редких случаях, например удаленно надо подебажить разрабу. Но так не всегда. Тут скорее зависит от разработчика, потому что кому-то реально проще подебажить и найти по коммиту место, где поломалось.

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

12). Нажмите кнопку «Создать», чтобы отправить отчет об ошибке.

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

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

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

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

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

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

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

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

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

Откуда берутся баги

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

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

Виды багов

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

🧨 Синтаксические. Это опечатки в названиях операторов, пропущенные запятые или кавычки.

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

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

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

🧨 Арифметические. Бывает, в коде есть числовые переменные и математические формулы. Если где-то проблема — не указаны константы или округление сработало не так, возникает баг.

Почему важно сообщать об ошибках и кто это делает

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

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

Тестировщиком реально стать даже без опыта в IT. Для этого пройдите курс Skypro «Инженер по тестированию». Научитесь писать тестовую документацию и составлять отчеты, тестировать веб- и мобильные приложения и API, освоите нужные инструменты. Внутри — мастер-классы с реальными рабочими задачами, домашки и разборы от наставника. Создадите четыре проекта для портфолио и получите диплом гособразца.

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

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

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

👉 Заголовок — краткое обозначение проблемы, причина и тип ошибки.

👉 Описание — подробности и любые сведения, которые помогут локализовать и исправить ошибку.

👉 Вложения — любые визуальные или другие материалы.

👉 Критичность — комментарий, насколько баг мешает нормальной работе приложения.

Часто выделяют следующие уровни критичности ошибок:

☝ Блокирующий (Blocker) — полностью блокирует нормальную работу программы, нужно исправить как можно быстрее.

☝ Критический (Critical) — сильно искажает логику приложения и значительно осложняет работу с ним.

☝ Значительный (Major) — затрагивает только отдельные элементы программы, существенно мешает работать.

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

☝ Тривиальный (Trivial) — относится к визуальным недочетам в интерфейсе: опечатки, неудобные цвета и прочее.

Остальные элементы указывают, в зависимости от условий. Например, если софт на ставят на ПК, то нужна версия ОС. Если приложение браузерное, то указывают браузер.

Пример баг-репорта

Заголовок	Не срабатывает кнопка Start
Проект	Аванта
Компонент приложения	Кнопка запуска приложения. Начальное меню
Номер версии	0.9а
Критичность	Блокирующий
Приоритет	P1 Высокий
Статус	Новый
Автор	Картавых Игорь Сергеевич
Назначен на	Мудрых Андрей Иванович
Описание	ОС Win10, 19045.2728, Google Chrome 111.0.5563.65, 0.9а (0.9.11.5А). При запуске приложения, на главном экране. Отсутствие вывода Запуск приложения
Прикрепленный файл	N/A

Основные принципы: как не допускать ошибок в баг-репорте

Правильные отчеты помогают программистам быстрее исправлять ошибки. Форма баг-репорта зависит от типа багов. Но есть несколько основных принципов — что и как включать в баг-репорт, чтобы заранее снять вопросы разработчиков.

Указывайте:

1️⃣ Только одну ошибку на отчет. Это золотое правило, потому что так гораздо проще исправлять баги. Легче отслеживать статус отдельных отчетов и выставлять приоритеты задач, распределять работу между несколькими разработчиками. Да и меньшее количество информации проще запомнить и проанализировать.

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

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

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

5️⃣ Скриншот или запись экрана с ошибкой. Есть риск ошибиться, когда пишешь отчет об ошибке. Это значительно усложнит работу команды разработки. Визуальные материалы — более точный способ указать на проблему, чем просто описать ее.

6️⃣ Техническую информацию. То есть вашу операционную систему, браузер, тип устройства — персональный компьютер, мобильный телефон или планшет. А еще тип устройства ввода — клавиатуру, мышь, сенсорный экран и прочее. Будут полезны и параметры монитора, чтобы исправить ошибки в отображении пользовательского интерфейса.

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

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

9️⃣ Пробовали ли исправить проблему. Есть причина, по которой айтишник всегда спрашивает: «Вы пробовали выключить и снова включить?» или «Пытались ли обновить веб-страницу?». Перезагрузка может быть простым способом исправить проблему. Если она не исчезает — это дает много информации. Укажите, и это сэкономит время на последующее обсуждение проблемы.

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

Жизненный цикл баг-репорта

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

💡 Новый — только создан, ждет проверки разработчиком.

💡 Принят — отчет проверили, проблему подтвердили.

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

💡 Назначен — ошибку передали исполнителю.

💡 В работе — разработчик исправляет ошибку.

💡 Проверяется — исполнитель закончил работу, результат проверяет старший специалист.

💡 Закрыт — ошибку исправили, результат доступен пользователям.

Системы для отчетов об ошибках

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

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

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

К наиболее распространенным системам управления проектами относят:

• Jira.
• YouTrack.
• Redmine.

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

К основным системам управления исходным кодом относят:

• GitHub.
• GitLab.
• Bitbucket.

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

✔️ форма создания отчета об ошибке с полями для ввода основных элементов;

✔️ управление состоянием и параметрами;

✔️ форма обсуждения, в которой команда задает вопросы и оставляет комментарии, указывает дополнительные детали;

✔️ уведомление об изменениях через имейл или другую систему обмена сообщениями.

У части баг-трекеров есть публичное голосование. Пользователи голосуют за или против бага: так повышают или понижают его приоритет.

Главное: что такое баг-репорт

• Баг-репорт — специальный вид отчета о неисправности в программном обеспечении или веб-сайте. Баг-репорт готовят тестировщики или специалисты из команды по контролю качества.
• Ошибки в коде могут быть разными, например связанные с логикой программы. Или с математическими вычислениями — логические. Еще бывают синтаксические, ошибки взаимодействия, компиляционные и ошибки среды выполнения.
• Оформление баг-репорта сильно влияет на скорость, с которой исправят ошибки, на итоговый результат. Указывайте причину и тип ошибки, подробности, срок выполнения, критичность. Прикладывайте скриншоты или запись экрана.
• Прописывайте, пробовали ли исправить проблему, насколько она влияет на работу. Указывайте операционную систему, браузер, тип устройства, параметры монитора.
• Есть системы, с которыми проще создавать баг-репорты и управлять ими. Основные: Jira, YouTrack, Redmine, GitHub, GitLab, Bitbucket.

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

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

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

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

Определение

Чтобы дать наиболее точное определение, необходимо обратиться к стандартам. В нашем случае, к ISTQB.

Отчет о дефекте (bug report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]

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

С определением разобрались, поехали дальше.

Зачем необходимо правильно описывать ошибку

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

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

Таким образом, главными задачами отчета об ошибке являются:
1. Показать, в чем заключается ошибка.
2. Помочь исправить дефект с минимальными затратами.

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

Каким должен быть отчет

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

Полезные репорты это те, которые приводят к исправлению ошибки. Хороший баг-репорт должен быть:

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

Итак, баг-репорт — это основной инструмент, который помогает тестировщику объяснить программисту место поиска бага. А о том, как его составлять мы поговорим в следующей статье.

Как Вы думаете, какой навык тестировщика — самый важный?

---

Написание тест-кейсов?

Тест-анализ?

Может автоматизация тестирования?

Что-то из soft-skills?

Умение работать в команде?

Как насчет поиска багов?

---

Написание хороших баг репортов — это самый важный навык тестировщика!

Почему?)

Потому что хороший баг репорт это: 

• экономия времени и сохранение нервов разработчика (не нужно тратить время на “понимание” ошибки и раздражающие разговоры “это баг — нет, это не баг”)
• радость для бизнеса (исправления делаются быстро, повышается качество продукта)
• удовольствие для клиента (все мы хотим пользоваться качественными продуктами)

Ни один другой навык не приносит столько пользы, как этот)

Вы можете быть супер-аналитиком, находить по 100 багов за день, общаться и дружить со всеми разработчиками. Но, если Вы не умеете создавать баг репорты — баги не будут исправляться. А если баги не будут исправляться… Вы сами можете догадаться, что произойдет 🙂

---

Научиться писать качественные баг репорты — просто! 

Каким образом и что для этого нужно?

Читайте в этой статье)

Что такое Баг / Дефект?

Перед тем, как начать разговор о баг репортах, стоит очень хорошо разобраться, что такое “баг”, ведь его мы и будем описывать 🙂

Существует несколько определений бага:

1. Баг — это изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [3]
2. Баг — это проблема, которая может приводить к отказу приложения или получению неправильных результатов, если ее не исправить. [ISO 24765, перевод]
3. Баг — это недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа [4]

Данные определения описывают баги в коде и их сложно применить к багам в требованиях, UI / UX и т.п.

На этапе проверки требований у нас нет компонента, системы (см. определение 1,3) или приложения (определение 2). У нас есть только текст, который их описывает, если он вообще существует 😂

---

Более универсальное и доступное определение приведено в книге [4]:

Баг — это отклонение фактического результата от ожидаемого результата.

Здесь:

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

---

Давайте рассмотрим несколько примеров багов.

Баг в функционале:

1. Существует функция, которая возвращает сумму чисел.
   Передав ей значения sum(2, 2) мы должны получить 4 (ожидаемый результат)
2. Предположим, функция возвращает значение, отличное от 4, например 5 (фактический результат)
3. фактический результат ≠ ожидаемому результату (5 ≠ 4), значит это баг в логике функции

Баг в требованиях:

1. У нас есть требование, в котором указано, что дата регистрации клиента на сайте должна равняться 02.04.20 (фактический результат)
2. Здравый смысл подсказывает, что датой регистрации должна быть “текущая дата в момент регистрации” (ожидаемый результат)
3. Фактический результат ≠ ожидаемому результату, значит это баг в требованиях

Баг в UX:

1. Предположим, Вы открываете меню сайта на мобильном устройстве. Меню находится справа и занимает 70% ширины экрана. Слева появляется черный фон
2. Вы нажимаете на черный фон — ничего не происходит.
   Опыт подсказывает, что после клика на фон меню должно закрываться (ожидаемый результат), но по факту — ничего не происходит (фактический результат)
3. Фактический результат ≠ ожидаемому результату, значит это баг в UX

Откуда берутся баги?

Баги являются следствием ошибок.

В свою очередь, ошибка — это действие человека, которое приводит к неправильным результатам [4]. 

Причин возникновения ошибок множество [5]:

1. Стресс
2. Спешка
3. Усталость, болезнь
4. Непонимание задания
5. Отсутствие коммуникации
6. Невозможность сконцентрироваться
7. Некомпетентность
8. Чрезмерная сложность ПО
9. Отсутствие документации / информации
10. …

---

Ошибки делают все и делают их всегда. 

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

Лучшие спортсмены, ученые, инженеры, политики, актеры, музыканты — ошибаются. Бизнес-аналитики, разработчики, тестировщики, дизайнеры, администраторы, переводчики и т.п. — не исключение…

Заблуждение об отсутствии ошибок — это один из принципов тестирования.

Все ли баги нужно исправлять?

Нет, не все.

В идеальном мире — наверное да, но мы не знаем где он 🙂

Что мы знаем, так это то, что все люди ошибаются. Тестировщики тоже. Иногда Вы можете замечать вещи, которые багами не являются. 

Это может происходить потому что вы: 

1. Не знаете правильный ожидаемый результат (из-за плохой коммуникации / недостаточного описания требований / недостаточного опыта)
2. Допустили ошибку в ходе тестирования (например, перепутали порядок “шагов” проверки, или поменяли значение в базе данных не там, где нужно было)

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

Вряд ли кто-то будет заниматься ошибкой, исправление которой стоит $1000 в то время как она затрагивает всего 0.002% пользователей, не приносящих ценности компании.

Zero bug policy — отличный процесс работы с багами при использовании гибкой разработки

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

Каждый найденный баг всегда проходит через конкретные “этапы”, которые называются жизненный цикл бага. 

---

Давайте рассмотрим каждый этап и переходы между ними подробнее.

Этапы жизненного цикла бага

1. Открыт (Open) — баг создан, оформлен и передан разработчику / команде разработки

2. В Работе (In Progress) — ведутся работы по исправлению

3. Исправлен (Ready for check) — баг исправлен и передан тестировщику на повторную проверку

4. Закрыт (Closed) — баг проверен и больше не воспроизводится

Переходы бага между этапами жизненного цикла

Переходы между этапами жизненного цикла пронумерованы в соответствии с нумерацией списка ниже.

1. Открыт — Закрыт. Если баг — это “не баг”, он может сразу быть закрыт, без промежуточных операций. 

2. Открыт — В Работе. Баг подтвержден и передан разработчикам, которые начали работу над исправлением.

3. В Работе — Закрыт. Бывает, что в ходе исправления ошибки разработчик понимает, что это не ошибка, а что-то другое. (фича / неточность в требованиях, которую обсудили без тестировщиков и т.п.) В этом случае разработчик описывает, почему это не баг, и закрывает задачу.

4. В Работе — Исправлен. Ошибку локализовали и исправили, она передана тестировщику.

5. Исправлен — Открыт. Тестировщик проверил исправление, баг все еще воспроизводится, то есть не исправлен. Он возвращается разработчику (возможно с указанием каких-то дополнительных деталей)

6. Исправлен — Закрыт. Тестировщик проверил исправление, баг больше не воспроизводится.

7. Закрыт — Открыт. Если баг случайно закрыли, должна быть возможность его переоткрыть.

Теперь, когда мы разобрались с багами, причинами их возникновения и жизненным циклом — мы можем переходить к рассмотрению баг репорта 🙂

Что такое баг репорт (bug report)?

Баг Репорт (Bug Report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]

---

Мы уже знаем, что такое баг, поэтому определение можно упростить.

Баг Репорт (Bug Report) — документ, содержащий информацию о найденном баге.

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

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

---

Написание баг репортов — чрезвычайно полезный процесс, потому что:

1. Происходит фиксации факта существования бага

Есть репорт — есть прецедент для реакции.
Нет репорта — никто ничего не будет делать.

2. Баг репорт помогает разработчику

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

В докладе Егора Бугаенко Testing and Testers на TestCon 2020, именно об этом был 4-ый вопрос и объяснения, почему это важно. Рекомендую посмотреть 🙂

3. Появляется возможность приоритизации исправлений

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

4. Появляется возможность анализа ошибок

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

5. Тестировщик содействует устранению бага

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

6. Появляется возможность контроля этапа исправления бага

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

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

7. Появляется возможность оценки качества продукта в текущий момент времени

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

---

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

Именно поэтому навык написания хороших отчетов критически важен для любого профессионала-тестировщика и его нужно освоить в совершенстве 😉

Атрибуты баг репорта

Баг репорт — это технический документ. 

У него есть некий набор атрибутов (полей, параметров) для структуризации информации.

---

Атрибуты баг репорта можно разделить на 2 группы:

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

Основные поля

• ID — уникальный идентификатор бага
• Заголовок / Краткое описание / Тема / Summary / Title — четко и кратко описывает суть бага. Оформляется в виде одного предложения, состоящего из трех частей отвечающих на вопросы “Что? Где? Когда?”. Редко бывает, что ответ на вопрос “Где?” или “Когда?” может опускаться, если он не дает полезной информации. (примеры заголовков можно найти в разделе Серьезность)
• Шаги к воспроизведению — четкое, последовательное описание шагов / действий, которые необходимо совершить, чтоб воспроизвести баг со всей необходимой информацией
• Фактический результат — результат, который мы видим
• Ожидаемый результат — результат, который мы хотели / ожидали увидеть
• Серьезность — показывает, насколько серьезные последствия от дефекта с точки зрения влияния на систему (см. раздел Серьезность)

Дополнительные поля

• Скриншот / видео — изображение / видео, которое четко и наглядно демонстрирует баг. Если видео или скриншот сделан качественно, его может быть достаточно для понимания сути ошибки и ее исправления
• Требование — ссылка на требование, которое не соблюдено. Наличие этой информации в 99% случаев предотвращает разговор “баг — не баг” и испорченное настроение 🙂
• Тип бага — для анализа “слабых” мест в ПО, баги могут разделять на типы (см. Тип бага)
• Приоритет — очередь, в которой баг будет исправляться (Высокий -> Средний -> Низкий)
• Дополнительные файлы — файлы, которые нужны для воспроизведения бага (файлы определенного размера, типа, логи и т.п.)
• Окружение — информация об окружении, на котором воспроизводится баг (версия браузера, операционная система, размер экрана, тестовый сервер и т.п.)
• Статус — текущий статус бага в его жизненном цикле (Открыт, В работе…)
• Автор — человек, который создал баг (нужен для уточнения информации, если потребуется)
• Исполнитель — человек, которые работает над багом в данный момент времени
• Комментарии — обсуждение исправления ошибки
• Версия — версия ПО, в которой был обнаружен баг
• Версия исправления — версия ПО, в которую будет добавлено исправление бага

Серьезность бага (Bug Severity)

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

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

S4 | Blocker

Блокирующий — баг описывает ситуации, когда ПО не работает в принципе.

Примеры:

1. Не открываются страницы сайта (показывается белый фон / 404 / 50Х ошибка)
2. Не запускается мобильное приложение после нажатия на иконку на рабочем столе
3. Зависает интерфейс приложения после нажатия на кнопку «купить» (кнопки перестают нажиматься, приложение невозможно свернуть и т.п.)

S3 | Critical

Критический — баг влияет на критический функционал или критические данные.

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

Примеры критических функций в разных приложениях: 

1. Баннера на сайте Х (приведение новых клиентов на сайт Y с использованием баннеров — основная функция сайта Х)
2. Форма логина на сайте Y (без логина — клиент не может попасть на форму заказа и оформить его, а это одна из основных функция сайта Y)
3. Форма оплаты на сайте Y (без формы оплаты — клиент не сможет оплатить свой заказ — самый критический функционал сайта Y)

Помимо критического функционала, к критическим багам относятся:

1. “Дыры” в безопасности системы
2. Полная / частичная потеря работоспособности системы на ощутимый промежуток времени, вызванная падением сервера
3. Проблема, которую пользователь не сможет обойти своими силами
   1. например, если открытое модальное окно можно закрыть только нажатием на крестик, и нажатие не срабатывает на iOS

Примеры: 

1. Указана неправильная ссылка на баннере в сайдбаре на странице Х
2. Отсутствует ограничение максимальной длины вводимых в поле Name данных на странице Donate
3. Показывается сообщение о серверной ошибке (503) на странице /signin после попытки логина
4. Показывается сообщение NGINX 404 error на главной странице блога Y
5. Не закрывается меню сайта после нажатия на крестик / черный фон

S2 | Major

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

К этому уровню относятся баги, связанные с:

1. Некритическим функциональными требованиями
2. Некритическим нефункциональными требованиями 
3. Серьезными визуальными отклонениями в дизайне

Примеры:

1. Не отображается плашка New на странице /order-details
2. Не отображаются OG / Twitter microdata на странице X
3. Неправильный порядок блоков “What we do?” и “How about now” на странице Х

S1 | Minor

Незначительный — баг не влияет на бизнес логику приложения.

Чаще всего к этому уровню относятся баги в реализации UI (верстке), отсутствие переводов и т.п.

Примеры:

1. Не отображается ссылка /free-page в блоке “Free Products” в футере
2. Не переносится на новую строку / Не обрезается текст ссылки “Our TOP 20 projects” в блоке «How it works?» на странице Х
3. Не соответствует макету цвет текста в блоке Contact в футере  

S0 | Trivial

Тривиальный — баг никак не влияет на качество продукта.

Из-за того, что такие баги не влияют на качество продукта, преднамеренно их не исправляют (они не “окупаются”). Обычно, правку делают в ходе реализации смежной задачи.

Примеры:

1. Отсутствует точка в конце предложения “This is whatever“ на странице Х
2. Отображается не актуальный год в футере сайта Х

Типы багов

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

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

Приведенные ниже типы багов относятся к WEB сайтам.

UI (ошибка в верстке)

Баг в верстке — следствие ошибки в разметке (HTML) или стилизации (CSS) элемента страницы в специфическом окружении. 

Примеры:

1. Не отображается блок Х на странице Y (в дизайне блок есть, на странице — нет)
2. Неправильное расположение блока на странице X (в дизайне блок слева, на странице — справа)
3. Не переносится на новую строку / Не обрезается текст ссылки “Our TOP 20 projects” в блоке «How it works?» на странице Х

UX (ошибка в удобстве)

Баг в удобстве — неудобство / нелогичность работы с элементами / функционалом страницы.

Примеры:

1. Не получается с первого раза нажать на кнопку Х в футере на мобильном (очень маленькая зона клика, кнопку нужно сделать больше)
2. Удаляется заказ после нажатия на кнопку Х в модальном окне на странице Б (ожидаешь закрытия окна, а фактически удаляется заказ — UX путает)

Functional (ошибка в функционале)

Баг в функционале — несоответствие логики работы компонента заявленным функциональным требованиям.

Примеры:

1. Отображается неправильное количество ссылок в блоке Related Papers в sidebar
   1. требование: выводить 5 ссылок
   2. фактически: выводится 10 ссылок
2. Не происходит прокрутка страницы вверх после нажатия на кнопку To Top
   1. требование: происходит прокрутка страницы вверх после нажатия на кнопку To Top
   2. фактически: ничего не происходит
3. Не показалось сообщение об ошибке при вводе числа в поле Name
   1. требование: допустимые символы для поля Name = буквы (обязательны) + пробелы (не обязательны). При вводе других символов — показываем сообщение об ошибке.
   2. фактически: сообщение об ошибке не отображается
4. Не отображается модальное окно А после нажатия на кнопку Х
   1. требование: после нажатия на кнопку X показывается окно А
   2. фактически: после нажатия на кнопку X показывается окно С
5. Не отображается текст “Нет заказов” на профиле райтера, если количество заказов, назначенных райтеру = 0
   1. требование: отображается текст “Нет заказов“, если количество заказов на профиле райтера = 0
   2. фактически: не отображается текст “Нет заказов“, если количество заказов на профиле райтера = 0

SEO (ошибка в seo)

Баг в seo — ошибка, которая влияет на SEO (нарушение нефункциональных требований, касающихся seo).

Примеры:

1. Отображается неправильная структура заголовков блоков на странице Х
2. Найдены 4 ошибки на странице Х после проверки в w3c валидаторе
3. Указан неправильный title на странице Х
4. Закрыта для индексации страница Х 
5. Отсутствует атрибут ALT на изображении Z на странице Х

Алгоритм создания баг репорта

Предположим, Вы нашли баг и приступаете к написанию баг репорта. 

С чего начать?

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

1. Понять “суть” проблемы, а не ее проявление (если получится, но это требует технических знаний)
2. Воспроизвести дефект один-два раза (удостовериться, что он повторяется)
3. Проверить наличие найденного вами дефекта в системе управления дефектами (возможно, баг уже создали)
4. Написать заголовок (отвечает на вопросы “что? где? когда?”)
5. Написать основные поля отчета
6. Заполнить дополнительные поля отчета
7. Внимательно прочитать отчет. Убрать лишнее, добавить нужное!
8. Еще раз перечитать отчет! (самый важный пункт)
9. Сохранить отчет
10. Переназначить отчет либо проверяющему (если такой есть) либо разработчику (который будет исправлять ошибку)

---

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

Пример хорошего баг репорта (bug report example)

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

И Вы хотите создать отчет о найденном баге (нет перевода текстов ошибок). 

Итоговый вариант может выглядеть так:

Заголовок / Краткое описание / Тема / Summary / Title

Не переведены на украинский язык тексты ошибок (что?) на форме “Зворотний зв’язок” на странице https://itawards.ua/ua (где?) в UA версии сайта (когда?)

Скриншот / видео

Скриншот / ссылка на скриншот

Шаги к воспроизведению

1. Открыть страницу https://itawards.ua/ua
2. Проскролить к форме “Зворотний зв’язок”
3. Нажать на кнопку “Надіслати”
4. Обратить внимание на язык ошибок, которые появились под полями формы

Фактический результат

Отображаются ошибки на английском языке

Ожидаемый результат

Отображаются ошибки на украинском языке

Серьезность

S1 (minor)

---

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

Пример баг репорта в Jira

Jira является одной из самых распространённых систем управления проектами в мире и очень часто используется в ИТ.

Так может выглядеть описанный выше баг репорт в Jira:

---

Открыть полное изображение в новой вкладке

---

Здесь:

• красным отмечены основные поля
• синими отмечены дополнительные поля

Основные поля являются обязательными для заполнения при создании бага, без них задача просто не сохраниться 🙂

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

Создание хороших баг репортов требует определенных знаний, навыков и опыта. 

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

1. Заголовок не отвечает на вопросы “Что? Где? Когда?”
2. Заголовок содержит лишнюю информацию (версии, окружения, учетные данные пользователей и т.п.)
3. Отсутствуют шаги для воспроизведения
4. Шаги для воспроизведения излишне детализированы
5. Отсутствует фактический и / или ожидаемый результат
6. Отсутствует ссылка на требование, которое проверялось (если такое есть)
7. Отсутствие скриншота / видеозаписи для UI/UX багов (сюда можно также добавить отсутствие выделения ошибки на скриншоте)
8. Грамматические ошибки / Техническая безграмотность / Использование “жаргона”

Знание типичных ошибок помогает проверять самого себя (можно создать чек-лист) и позволяет создавать более качественные отчеты без возвратов на доработку!

Резюме

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

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

И именно правильное и качественное оформление баг репортов является ключевым навыком тестировщика.

---

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

---

Если у вас есть вопросы или предложения — пишите нам в Телеграм!

---

Если вам интересно тестирования и Вы хотите получать актуальную информацию по этой теме — подписывайтесь на наш Tелеграм канал. У нас очень интересно: статьи, видео, тесты, опросы, нет спама 😉 

Источники

1. Баг (значения) // ru.wikipedia.org URL: https://ru.wikipedia.org/wiki/Баг_(значения) (дата обращения: 28.10.2020).
2. Программная ошибка // ru.wikipedia.org URL: https://ru.wikipedia.org/wiki/Программная_ошибка (дата обращения: 28.10.2020).
3. ISTQB Глоссарий Терминов Тестирования 2.3 [https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB%20%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B8%CC%86%20%D0%A2%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%BE%D0%B2%20%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%202.3.pdf]
4. Куликов С. Тестирование программного обеспечения Базовый курс. — 3 изд. 2020. — 298 с.
5. Программа подготовки ISTQB Базового уровня 2018
   [https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CTFL_Syllabus_2018-RU.pdf]

FAQ

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

«Смысл написания отчета о проблеме (отчета об ошибке) состоит в том, чтобы исправить ошибки» — Джем Канер. Если тестировщик неправильно сообщает об ошибке, то программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима. Или потратит кучу лишнего времени на то, чтобы сделать вашу работу за вас. Едва ли такой тестировщик будет выгоден бизнесу, приятен коллегам и долго задержится на своем месте.