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

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

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

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

Поле	Комментарий	Ответственный за заполнение
Короткое описание (Summary)	Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.	Тестировщик
Проект (Project)	Название тестируемого проекта	Тестировщик
Компонент приложения (Component)	Название части или функции тестируемого продукта	Тестировщик
Номер версии (Version)	Версия на которой была найдена ошибка	Тестировщик
Важность (Priority)	Наиболее распространена пятиуровневая система градации важности дефекта: Блокирующий (Blocker) Критический (Critical) Значительный (Major) Незначительный (Minor) Тривиальный (Trivial)	Тестировщик, может быть изменена руководителем проекта
Статус (Status)	Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)	Меняется в ходе обработки бага
Автор (Reporter)	Создатель баг репорта	Тестировщик
Исполнитель (Assignee)	Имя сотрудника, назначенного на решение проблемы. Баг может менять исполнителя несколько раз, например, изначально все баги заводятся на руководителя проекта, который потом переназначает баг на конкретного разработчика	Руководитель проекта
Окружение (Environment)
ОС / Севрис Пак и т.д. / Браузера + версия / ...	Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования - имя и версия браузера и т.д.	Тестировщик
...
Описание (Description)
Шаги воспроизведения (Steps to Reproduce)	Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.	Тестировщик
Фактический Результат (Actual Result)	Результат, полученный после прохождения шагов к воспроизведению	Тестировщик
Ожидаемый результат (Expected Result)	Ожидаемый правильный результат	Тестировщик
Дополнения
Прикрепленный файл (Attachment)	Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы	Тестировщик

Важность и Приоритет Дефекта

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

Важность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.

Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.

В JIRA из соображений бизнес-требований в настоящий момент доступно лишь одно поле - Priority, которое содержит в себе значения, которые привыкли видеть в Severity, т.е. важности. С одной стороны, это может сбивать с толку тех, кто привык работать с другими системами (например, Bugzilla), которые содержат эти оба поля; с другой стороны, задача тестировщика состоит в том, чтобы обнаружить дефект и указать его важность, а очередность исправления - задача руководителя проекта. Так как данная статья посвящена именно JIRA, то в ней мы будем говорить Важность дефекта подразумевая поле Priority, которые приняты в этой системе, не претендуя на полноту (для тех, кто не готов идти на подобные компромисы, есть решение: поле Priority переименовать в Severity в языковых файлах и добавить custom field Priority, которому уже присвоить необходимые значения).

Градация Важности дефекта (Priority)

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

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

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

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

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

Написание баг репорта

Баг репорт - это технический документ и в связи с этим нужно отметить, что язык описания проблемы должен быть техническим. Должна использоваться правильная терминология при использовании названий элементов пользовательского интерфейса (editbox, listbox, combobox, link, text area, button, menu, popup menu, title bar, system tray и т.д.), действий пользователя (click link, press the button, select menu item и т.д.) и полученных результатах (window is opened, error message is displayed, system crashed и т.д.).

Требования к обязательным полям баг репорта

Отметим, что обязательными полями баг репорта являются: короткое описание (Bug Summary), важность (Priority), шаги к воспроизведению (Steps to reproduce), результат (Actual Result), ожидаемый результат (Expected Result). Также очень рекомендуется прикреплять к багу дополнительные файлы, помогающие программистам быстрее идентифицировать ошибку, например логи, тестовые файлы, скриншоты. Ниже приведены требования и примеры по заполнению этих полей.

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

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

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

Важность

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

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

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

Например:

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

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

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

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

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

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

Заключение

Предлагаем вам комментарий одного разработчика:

- Прочитав короткое описание бага (Bug Summary), я должен понять в чем состоит проблема, прочитав детальное описание бага (Bug Description) я должен знать строку кода, которую править.

С этим можно соглашаться или не соглашаться, но смысл этого высказывания в том, что вы должны делать все так, чтобы к вам меньше было вопросов по существу описанной в баг репорте проблемы. Так как каждый возвращенный вам баг репорт со статусом "Отклонен", "Не воспроизводится", "Требуется информация" (Rejected, Can't Reproduce, More info) - это потеря времени, как вашего так и разработчика. А время, как известно - это деньги, которые мы получаем, за то что делаем нашу работу лучше всех!

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