В самом начале карьеры тестировщика я сталкнулся с тем, что не смог найти нормального примера оформления баг-репорта. Почти все советы в интернете на столько общие и размытые, что толку от них никакого. Пришлось потратить дофига своего времени на тупую работу – просмотреть все эти рекомендации и шаблоны чтобы отжать "воду" и собрать свой шаблон баг-репорта.
Итак, баг-репорт – это запись о найденом дефекте в программе. Вещь очень нужная для всех: разработчикам понятно что не так с приложухой, а мне баг-репорт нужен чтобы через неделю я смог вспомнить что тут вообще происходило. Для менеджеров на первый взгляд баг-репорты не важны, но это не так. Они им тоже нужны чтобы владеть информацией об актуальном качестве продукта и дальше менеджерить исходя из этих данных.
Перечислю поля, которые сам считаю важными.
• ID – номер бага в вашем баг-трекере. Почти везеде (JIRA, RedMine, YouTrack) он присваивается автоматически при создании любой новой задачи в трекере;
• Автор – имя того, кто багу завёл (=нашел). Тоже присвается автоматом;
• Дата – имя поля говорит само за себя;
• Название проекта – название проекта, в котором эта бага обнаружена. Тоже присвается автоматом;
• Версия билда. Почти наверняка вы разрабатваете спринтами. И что бы точно знать имя билда где этот баг 100% присутствует надо это поле заполнить.
• Описание. В этом поле надо подробно по шагам описать сценарий воспроизведения бага. Уделите этому пункту своё внимание. Когда проект большой или у вас несколько проектов, то вы точно забудете что это за баг вообще и как его воспроизводить тем более. То что записано уже не забудется.
• Ожидаемый результат и Фактический результат. Думаю, тут понятно что нужно писать в каждом из полей. Не ленитесь описывать эти поля. Потому что требования могут изменяться и вам в будущем будет проще доказывать свою правоту перед коллегами, когда у вас будет такой аргумент.
Дальше я выделил необязательные поля, но каждое из них может быть очень нужно для какой-то конкретной баги или даже проекта целиком:
• Тестовая среда. Напрмер, название браузера или его версии, название почтового клиента, разрешение экрана, модель ОС или название БД к которой вы цепляетесь;
• Приоритет. То на сколько заказчику важен функционал, в котором есть эта бага.
• Критичность. То на сколько рушит эта бага ваше приложение. Не путайте приоритет и критичность.
• И последнее: скриншоты и видео-пруфы.
Подписывайтесь на мой канал в Телеграме https://t.me/protesting
