Чтобы написать bug report(отчет об ошибке) в Jira необходимо выполнить несколько действий, которые ты узнаешь на примере «боевой» жиры. Уверен, что общую концепцию поймешь.
Далее ты узнаешь:
Что такое Jira?
Шаги для составления баг репорта
Что такое Jira?
Jira - это система управления проектами и отслеживания задач, которая используется командами разработки программного обеспечения.
Она позволяет создавать, отслеживать и управлять задачами разработки, контролировать прогресс выполнения, планировать версии и релизы, обеспечивать коммуникацию и сотрудничество в команде, а также предоставляет отчетность и аналитику для анализа производительности проекта.
Jira помогает командам разработки эффективно управлять проектами и обеспечивать успешную доставку программного обеспечения.
Шаги для составления баг репорта:
1). Перейдите в Jira и нажмите кнопку «Создать».
2). Выберите тип проблемы «Ошибка» из списка вариантов.
3). Заполните поле сводки кратким описанием проблемы(summary), например такой шаблон: «путь до бага» - «какая проблема?», «когда?», «где?». Заголовок можно по разному строить.
4). В поле описания предоставьте подробное объяснение проблемы, и любые отображаемые сообщения об ошибках, например добавить логи и/или веб сокеты. Также можно прикрепить видео, скрины и другие файлы с необходимой информацией. Тут же можно указать окружение, где воспроизвелось или в ином специальном поле.
5). Напишите шаги для воспроизведения в специальное поле. Рекомендую в виде пронумерованного списка.
6). Прикрепите к проблеме любые соответствующие файлы, например снимки экрана и/или файлы журнала(логи, иные файлы), возможно еще какие либо ярлыки, компоненты.
7). Установите уровень приоритета проблемы в зависимости от серьезности ошибки и срочности ее исправления.
8). По серьезности (Severity) бага в большинстве случаев, на практике, остаются пустым, по моему опыту, потому что тут разрабу виднее и то даже они часто оставляют это поле пустым.
9). Назначьте проблему на разработчика или на другого члена команды, ответственному за дальнейшую судьбу ошибки (поле Assignee) на определенном этапе её решения. Заполните поле сводки кратким описанием проблемы.
10). Добавить информацию о спринте, также ниже версию приложения, где был найден баг и в какой версии будет исправляться он, если это известно. Чаще всего этот вопрос решает аналитик, поэтому у него можно уточнить.
11). Можно установить связь с другой задачей, если такова имеется и присутствует необходимость, например можно установить связь с таской, которую тестировали и в ней нашли баг.
12). Нажмите кнопку «Создать», чтобы отправить отчет об ошибке.
Это основные шаги для работы с баг репортом, но шагов может быть больше.
Важно предоставить, как можно больше подробностей в отчете об ошибке, чтобы помочь разработчику понять и воспроизвести проблему. Если вы знаете фронт или бэк, а именно умеете или хотя б немного понимаете в разработке, то можете добавить свое предложение по решению проблемы или например загуглить проблему и дать ссылку на решение.
Также необходимо быть как можно более конкретными при описании шагов по воспроизведению ошибки, так как это поможет разработчику определить основную причину проблемы и быстрее ее исправить. Если что-то в багах не понимаете, то уточняйте у разрабов/аналитиков.
Samhuawei
Не надо писать о том о чём вы не имеете представления.
1. Заполнять баг нужно в соответствии со стандартами отдела QA. Может быть это нумерованный список, может ещё что. Главное следовать принятой практике, не пороть отсебятину.
2. Severity это Custom field, его в самой Jira нет. И уж точно не рядовой QA должен его заполнять. Равно как и спринт и Priority. По сути всё что нужно это Summary и Description.
3. Assignee должен назначаться менеджером во время планирования спринта. Или вовсе скриптом. Но уж никак не QA.
4. Версия это хорошо, но ещё лучше если это будет номер билда, так программистам проще.
Часто спринты планируются покомпонентно. Лучше если компонента была известна на момент создания бага.
VasiliiV Автор
Спасибо за комментарии.
По первому пункту - это и так понятно, но стандарт, вы должны понимать, что во всех компаниях он свой, например то, как оформляется шапка. Стиль описания и шагов воспроизведения может немного отличаться у каждого qa в одной компании) главное, чтобы было всем понятно.
По второму пункту. Не согласен. В Jira имеется встроенное поле "Severity" (Степень серьезности), которое используется для оценки и классификации серьезности проблемы или ошибки в рамках проекта. Поле Severity может быть настроено и настраиваемо в соответствии с требованиями конкретного проекта или команды, и его значения могут варьироваться в зависимости от контекста. Спринт и приоритет мы заполняем и конечно же при необходимости все согласуется, поэтому мы имеем право установить.
По третьему пункту. Тут зависит от договоренности внутри команды. Мы например имеем право установить ответственного за баг, например во время стабилизации или на другом этапе при согласовании с тем же менеджером.
Samhuawei
iBljad
Если уж на то пошло, п.1 относится и к остальным пунктам комментария: у кого-то может не быть ни спринтов, ни менеджера, итд :)
По самой статье:
про summary — если нет других указаний, мне нравится формат описания "что где когда"
про связи: неплохо было бы рассказать, как их добавлять и какие бывают
VasiliiV Автор
Спасибо за комментарии. Согласен. Возможно, Добавлю думаю для конкретики какой то.
Samhuawei
Summary должно быть таким чтобы Assignee быстро понял о чём идёт речь. Например
Submit button is grey on Comments screen
Когда лучше оставить в Description. Где это видимо версия или build. Что - это компонента.
Если планируется делать отчёт по багам лучше версию и компоненту заполнять в соответствующих полях Jira.
iBljad
Я не говорю, что это универсальное правило, просто шпаргалка для тех, кто [только начинает и] не знает, как лучше сформулировать.
Исключения можно придумать для любого формата, у всех разные продукты и процессы.
Что я имел в виду на примере вашего примера: "[Что] Кнопка отправки неактивна [Где] на странице комментариев [Когда]после обновления страницы"