Качественный баг-репорт должен состоять из нескольких базовых пунктов:
1. Заголовок
2. Окружение
3. Приоритет и серьезность
4. Шаги воспроизведения
5. Ожидаемое поведение
6. Фактическое поведение
7. Сопроводительные аттачи (скриншоты/скринкасты)
Пойдем по порядку.
Заголовок
Это первое, что видит любой пользователь таск-трекера. Заголовок должен быть написан так, что прочитав, становится понятно, в чем проблема. В идеале ваш заголовок должен как можно короче ответить на 3 вопроса: Что? Где? Когда?
Что? Пропадает кнопка входа.
Где? В форме регистрации – иногда вопрос Где? становится избыточным, и его можно опустить.
Когда? При нажатии на поле ввода пароля.
Нельзя расписывать заголовок более чем на одно среднее предложение, это только тормозит работу – и вашу, и того, кому придется читать заголовок. На планированиях и грумингах менеджеры вместе с разработчиками разбирают завалы задач, выбирая, что взять в работу в ближайшее время, а что может подождать. Никто не любит эти встречи (поверьте!), так что пишите заголовки настолько коротко и понятно, насколько можете.
Окружение
Сюда входит все, что помогает локализовать ваши условия воспроизведения бага. На каком девайсе вы поймали ошибку? Какая iOS у вас установлена? Какая версия приложения используется? Если баг сетевой, какую сеть вы использовали? Может влиять и оператор связи, поэтому, укажите его, если подозреваете, что в этом кроется причина ошибки. Распишите как можно подробнее, и разработчику не придется задавать вам вопросы поверх вашего баг-репорта.
К окружению мы также относим предусловия. В предусловиях описываются действия, которые нужно выполнить, и параметры, которые нужно применить перед выполнением шагов, позволяющих воспроизвести баг. Это описание не имеет какого-то четкого формата, просто придерживайтесь логического порядка. Многие пишут предусловия отдельным пунктом, но мы предпочитаем объединять их с окружением для упрощения.
Приоритет и серьезность
Приоритет является атрибутом, определяющим необходимую скорость устранения бага.
Первоначально приоритет бага определяется инициатором, но затем он корректируется менеджером продукта. Именно менеджер имеет общее представление о тестируемой системе и понимает, насколько срочно нужно исправить тот или иной баг.