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

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

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

Критичность и приоритет бага

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

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

S1 – Блокирующий (Blocker). Баг полностью блокирует выполнение программы, и не существует способа его обойти. Для понимания, можно привести пример из реальной жизни — все выходы из дома закрыты, и вы никак не можете покинуть помещение.
S2 – Критический (Critical). Дефект блокирует часть функционала, при этом существует способ его обойти. Рассмотрим пример по аналогии с предыдущим: входная дверь дома закрыта, однако вы можете покинуть помещение через окно. Допустимо, но на практике нерационально и неприемлемо для нового ПО.
S3 – Значительный (Major). Блокирует работу одной из основных логических цепочек программного обеспечения. Зачастую такой баг связан не с тем, что функция не работает, а с тем, что она работает не так как нужно.

S4 – Незначительный (Minor). Баг не влияет на функционирование основной логики программного обеспечения. С ним все работает корректно, без значительной потери качества. В качестве примера можно привести входную дверь с надписью «на себя», которая в реальности открывается в другую сторону.
S5 – Тривиальный (Trivial). Такой дефект никак не влияет на работу приложения, и чаще всего остается незаметным для конечного пользователя. Это могут быть небольшие грамматические ошибки в тексте, незначительное пересечение элементов меню и прочее.

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

Выделяют три уровня приоритетности:

P1 – Высокий (High). Баг требует немедленного исправление, поскольку является крайне важным для релиза программного обеспечения или оказывает глобальное влияние на функционирование всей системы.
P2 – Средний (Medium). Ошибка важна, но не нуждается в незамедлительном исправлении.
P3 – Низкий (Low). Незначительный баг, который исправляется в последнюю очередь, после отладки более приоритетных дефектов.

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

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

Заголовок (Summary) — небольшое и емкое описание бага, в котором отражается причина и тип возникшей ошибки.
Проект (Project) — полное название проекта.
Компонент приложения (Component) — часть или функция продукта, где была обнаружена ошибка.
Номер версии (Version) — версия продукта, в которой найден баг.
Критичность(Severity) — степень критичности бага по 5-уровневой системе, описанной выше: от S1 до S5.
Приоритет (Priority) — уровень приоритетности решения обнаруженной проблемы: P1, P2 или P3.
Статус (Status) — статус устанавливается в соответствии с принятым жизненным циклом бага, например: новый, открыт или закрыт.
Автор (Author) — имя сотрудника, составившего баг-репорт.
Назначен на (Assigned To) — имя сотрудника, который был назначен ответственным за отладку бага.
Описание (Description) — наиболее объемная часть баг-репорта, в которой подробно описана информация об окружении, где был найден баг: ОС, сервис-пак, версия библиотеки, название функции и прочее. В Description также указываются шаги, следуя которым можно воспроизвести ситуацию с возникновением ошибки, полученный результат (некорректный) и результат, ожидаемый после отладки.
Прикрепленный файл (Attachment) — скриншот, видео или любой другой документ, который поможет продемонстрировать причину возникновения ошибки или объяснит, почему полученный результат является некорректным.

Этапы оформления баг-репорта

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

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

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

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

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

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

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

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

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

Как стать тестировщиком

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