Встречали ли вы баги, где было недостаточно информации для понимания про что это? А тикеты, в которых было сложно найти нужную информацию, хотя где-то она все-таки есть? Кажется, команды сами усложняют себе работу не используя стандарт заведения тикетов-багов. И я решила поделиться шаблоном, который используем мы.

На мой взгляд, если разработчик открывает любой тикет, и в любом тикете нужная информация в одном и том же месте – это ускоряет решение проблемы. Поэтому мы используем табличку, в которой поля зафиксированы и идут в строгом порядке.

Такую:

Мы разрабатываем мобильное приложение, поэтому тут есть специфичные поля про версию ОС, firebase и т.п.

Теперь пройдемся по каждому пункту шаблона:

Версия ОС

В мобильных приложениях периодические встречаются баги, связанные с тем, что в какой-то из версий операционных систем либо не поддерживается используемый метод, либо он работает не так, как ожидается. Причем бывают проблемы со старыми версиями из-за новых методов, с новыми из-за старых и даже с какими-то «в середине» из-за багов самой Оси. Поэтому мы всегда указываем на каких версиях воспроизвелся баг и, если воспроизводится только на одной, уточняем это отдельно.

Девайс

Здесь ситуация во многом схожая, с предыдущим пунктом. Баги происходят не только из-за специфики версии операционной системы, но и из-за особенностей устройства – оболочка, размер экрана, графический процессор, объем памяти и т.п.

Ссылка на билд

Нам важно знать, где воспроизводится баг. Есть он в какой-то конкретной фиче-ветке, только в деве или уже в проде и с какой версии. И чтобы не искать, где взять эту версию с багом – прикладываем сразу ссылку, откуда можно скачать.

Предварительно

Шаги предшествующие обязательным для воспроизведения. Тут может быть требование подключить мок на какой-то запрос, авторизоваться или еще что-то. 

Шаги

Сами степы для воспроизведения. Последовательность действий, приводящая к багу.

Результат

Фактический результат, тот самый баг, который описывается в тикете.

Ожидаемый результат

Описание того как должно быть. Желательно со ссылкой на спеку, контракт, макет, если возможно.

Воспроизводится в проде

Этот параметр позволяет лучше оценить критичность бага – встречаются ли с ним пользователи или он пока только на тестовых/дев сборках.

Воспроизводимость %

К сожалению, не всегда получается добиться 100% воспроизведения результата. Для нас это поле показывает насколько баг «плавающий».

Response

Это json ответа с бекенда, с которым воспроизводится баг. Без этого файла баги как раз часто могут перестать воспроизводится к тому времени как разработчик до них доберется. Например, бек в 8 утра, когда начал работать QA возвращает одно, а ближе к вечеру, когда девелопер добрался до тикета, ответ отличается. И без мока тикет может переходить из qa в reopen каждый день.

Ссылка на firebase

Опциональное поле, которое заполняется, если тикет заводится на креш. Там и логи, и частота падений, и возможность отследить, что креш пофиксился после исправления.