Встречали ли вы баги, где было недостаточно информации для понимания про что это? А тикеты, в которых было сложно найти нужную информацию, хотя где-то она все-таки есть? Кажется, команды сами усложняют себе работу не используя стандарт заведения тикетов-багов. И я решила поделиться шаблоном, который используем мы.
На мой взгляд, если разработчик открывает любой тикет, и в любом тикете нужная информация в одном и том же месте – это ускоряет решение проблемы. Поэтому мы используем табличку, в которой поля зафиксированы и идут в строгом порядке.
Такую:
Версия ОС |
|
Девайс |
|
Ссылка на билд |
|
Предварительно |
|
Шаги | 1. 2. |
Результат |
|
Ожидаемый результат |
|
Воспроизводится в проде | Да/нет |
Воспроизводимость % | X/5 |
Response |
|
Ссылка на firebase |
|
Мы разрабатываем мобильное приложение, поэтому тут есть специфичные поля про версию ОС, firebase и т.п.
Теперь пройдемся по каждому пункту шаблона:
Версия ОС
В мобильных приложениях периодические встречаются баги, связанные с тем, что в какой-то из версий операционных систем либо не поддерживается используемый метод, либо он работает не так, как ожидается. Причем бывают проблемы со старыми версиями из-за новых методов, с новыми из-за старых и даже с какими-то «в середине» из-за багов самой Оси. Поэтому мы всегда указываем на каких версиях воспроизвелся баг и, если воспроизводится только на одной, уточняем это отдельно.
Девайс
Здесь ситуация во многом схожая, с предыдущим пунктом. Баги происходят не только из-за специфики версии операционной системы, но и из-за особенностей устройства – оболочка, размер экрана, графический процессор, объем памяти и т.п.
Ссылка на билд
Нам важно знать, где воспроизводится баг. Есть он в какой-то конкретной фиче-ветке, только в деве или уже в проде и с какой версии. И чтобы не искать, где взять эту версию с багом – прикладываем сразу ссылку, откуда можно скачать.
Предварительно
Шаги предшествующие обязательным для воспроизведения. Тут может быть требование подключить мок на какой-то запрос, авторизоваться или еще что-то.
Шаги
Сами степы для воспроизведения. Последовательность действий, приводящая к багу.
Результат
Фактический результат, тот самый баг, который описывается в тикете.
Ожидаемый результат
Описание того как должно быть. Желательно со ссылкой на спеку, контракт, макет, если возможно.
Воспроизводится в проде
Этот параметр позволяет лучше оценить критичность бага – встречаются ли с ним пользователи или он пока только на тестовых/дев сборках.
Воспроизводимость %
К сожалению, не всегда получается добиться 100% воспроизведения результата. Для нас это поле показывает насколько баг «плавающий».
Response
Это json ответа с бекенда, с которым воспроизводится баг. Без этого файла баги как раз часто могут перестать воспроизводится к тому времени как разработчик до них доберется. Например, бек в 8 утра, когда начал работать QA возвращает одно, а ближе к вечеру, когда девелопер добрался до тикета, ответ отличается. И без мока тикет может переходить из qa в reopen каждый день.
Ссылка на firebase
Опциональное поле, которое заполняется, если тикет заводится на креш. Там и логи, и частота падений, и возможность отследить, что креш пофиксился после исправления.