Comments 10
Не надо писать о том о чём вы не имеете представления.
1. Заполнять баг нужно в соответствии со стандартами отдела QA. Может быть это нумерованный список, может ещё что. Главное следовать принятой практике, не пороть отсебятину.
2. Severity это Custom field, его в самой Jira нет. И уж точно не рядовой QA должен его заполнять. Равно как и спринт и Priority. По сути всё что нужно это Summary и Description.
3. Assignee должен назначаться менеджером во время планирования спринта. Или вовсе скриптом. Но уж никак не QA.
4. Версия это хорошо, но ещё лучше если это будет номер билда, так программистам проще.
Часто спринты планируются покомпонентно. Лучше если компонента была известна на момент создания бага.
Спасибо за комментарии.
По первому пункту - это и так понятно, но стандарт, вы должны понимать, что во всех компаниях он свой, например то, как оформляется шапка. Стиль описания и шагов воспроизведения может немного отличаться у каждого qa в одной компании) главное, чтобы было всем понятно.
По второму пункту. Не согласен. В Jira имеется встроенное поле "Severity" (Степень серьезности), которое используется для оценки и классификации серьезности проблемы или ошибки в рамках проекта. Поле Severity может быть настроено и настраиваемо в соответствии с требованиями конкретного проекта или команды, и его значения могут варьироваться в зависимости от контекста. Спринт и приоритет мы заполняем и конечно же при необходимости все согласуется, поэтому мы имеем право установить.
По третьему пункту. Тут зависит от договоренности внутри команды. Мы например имеем право установить ответственного за баг, например во время стабилизации или на другом этапе при согласовании с тем же менеджером.
Если уж на то пошло, п.1 относится и к остальным пунктам комментария: у кого-то может не быть ни спринтов, ни менеджера, итд :)
По самой статье:
про summary — если нет других указаний, мне нравится формат описания "что где когда"
про связи: неплохо было бы рассказать, как их добавлять и какие бывают
Спасибо за комментарии. Согласен. Возможно, Добавлю думаю для конкретики какой то.
Summary должно быть таким чтобы Assignee быстро понял о чём идёт речь. Например
Submit button is grey on Comments screen
Когда лучше оставить в Description. Где это видимо версия или build. Что - это компонента.
Если планируется делать отчёт по багам лучше версию и компоненту заполнять в соответствующих полях Jira.
Я не говорю, что это универсальное правило, просто шпаргалка для тех, кто [только начинает и] не знает, как лучше сформулировать.
Исключения можно придумать для любого формата, у всех разные продукты и процессы.
Что я имел в виду на примере вашего примера: "[Что] Кнопка отправки неактивна [Где] на странице комментариев [Когда]после обновления страницы"
Так это логичное правило. Далее по факту уже решаешь, как лучше сделать. Просто человек придирается и возможно, думает, что если у него так работают в команде, то и везде так работают.
Как составить баг репорт начинающему тестировщику? Пример из приложения Jira