Помимо обязательных частей, которые были описаны в предыдущей статье, хотелось бы обсудить пару необязательных (опциональных). Сразу хочу отметить, что термин "опциональный" в данном контексте не значит, что этими частями можно пренебречь, либо, что в них нет смысла. Данные части необходимо обязательно включать в баг-репорт, если информация, которую они в себе несут, позволит ускорить скорость воспроизведения дефекта и (или) упростит процесс решения дефекта.
Дополнительное описание
Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. Заполняется в случае наличия дополнений к заголовку. При этом напомню, что заголовок всё равно должен следовать правилу:
Заголовки должны быть написаны таким образом, чтобы не открывая баг-репорт, можно было понять суть ошибки.
Пример использования:
Заголовок: Отсутствуют иконки социальных сетей в футере страницы вакансий.
Описание: Не отображаются иконки соцсетей в футере. На месте иконки Facebook отображается иконка повреждённого файла.
Окружение (environment)
В этом пункте описывается среда, в которой произошла ошибка. Операционная система и ее версия, браузер и его версия, версия приложения, размер экрана (если необходимо). Если ошибка произошла на мобильном устройстве, также указывается тип устройства и его модель.
Пример:
Окружение: Google Chrome 80.0.3987.132
Windows 10 Версия 1903 Номер сборки 18362.657
Вложения (Attachments)
Файл с логами, снимок экрана, видеозапись, HAR-файл или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы.
Своим студентам при вложении снимков экрана я рекомендую делать захват тестируемой страницы целиком, а проблемную область выделять красным прямоугольником. Основано это на моём опыте работы на краудтестинговых площадках, большинство из которых имело данное требование.
Приоритет (Priority)
Часть, указывающая на очередность выполнения задачи или устранения дефекта. Обычно проставляется владельцем продукта, либо менеджером проекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
P1 Высокий (High)
Дефект является критическим для продукта и должен быть устранен как можно скорее.
P2 Средний (Medium)
Дефект не требует срочного решения и может быть исправлена в ходе обычной деятельности — например, во время очередного спринта.
P3 Низкий (Low)
Баг несерьезный, поэтому может быть устранен после исправления критических дефектов или вообще не исправлен.
Порядок исправления ошибок по их приоритетам:
High -> Medium -> Low
Также можно выделить следующие части, которые обычно проставляются баг-трекинговой системой автоматически:
- Проект (Project) - название тестируемого проекта
- Компонент приложения (Component) - название части или функции тестируемого продукта
- Автор (Author) - cоздатель баг-репорта
- Назначен на (Assigned To) - имя сотрудника, назначенного на решение дефекта
В конце статьи хотел бы попросить вас поразмышлять и придумать примеры дефектов со следующими показателями. Варианты буду ждать в комментариях.
1) Серьезность дефекта - trivial, приоритет - high;
2) Серьезность дефекта - blocker, приоритет - low;
3) Серьезность дефекта - minor/major, приоритет - medium.
