Сфера тестирования приложений и различных продуктов довольно многогранная и сложная. Ведь главной задачей тестировщика является всестороннее изучение продукта, особенностей его работы на разных операционных системах, смартфонах, ПК, планшетах, лэптопах, а также составление отчетной документации, в рамках которой специалисту необходимо отметить все выявленные проблемы и баги системы. И одним из таких частей отчетности является баг репорт.
Тот ещё жук: как начинающему тестировщику составить хороший баг‑репорт
Встречали ли вы баги, где было недостаточно информации для понимания про что это? А тикеты, в которых было сложно найти нужную информацию, хотя где-то она все-таки есть? Кажется, команды сами усложняют себе работу не используя стандарт заведения тикетов-багов. И я решила поделиться шаблоном, который используем мы.
Та же фигня, причём какой бы сейв не грузил, всё одно и то же. Возможное решение в том что ты на каком то из фабрикаторов не закончил свои действия из-за это и происходят баги по этому стоит пройтись по всем фабрикаторам и скрафтить что нибудь и всё будет ок. Можно попробовать убрать лишние предметы около лотка фабрикатора.
Перед началом описания элементарного жизненного цикла бага предлагаем рассмотреть следующую блок-схему, показывающую основные статусы и возможные переходы от статуса к статусу в процессе его существования:. Допустим вы нашли баг и зарегистрировали его в баг трекинг системе. Тестировщик, ответственный за валидацию новых баг репортов, или координатор проекта в зависимости от распределения ролей в вашей команде может перевести его в один из следующих статусов:. Хотим отметить, что данная схема сильно упрощена.