Психология общения в баг-трекере

Или как не поссориться с разработчиком

Привет, охотники! 🏹

У меня есть несколько постов про взаимодействие внутри команды, теперь давайте перейдем к более конкретным ситуациям. Например, спор баг/не баг между тестировщиком и разработчиком

Для меня оказался важным совет лида: если кажется, что баг есть, то заведи на это задачу. Лучше его обсудить и закрыть с комментарием “Отклонен”, чем потом жалеть о том, что раньше его не подсветила

У тестировщиков есть еще один прекрасный способ себя оградить от лишних споров: документация и аналитики. Ссылка на нужную документацию обычно решает большинство проблем, но если это не помогает, то на помощь приходит аналитик, который эту функциональность продумывал.

Тут есть несколько исходов: 1 Аналитик об этом нюансе даже не подумал, что-то не было сделано / было сломано. Тогда либо баг чинят с комментарием “Ошибка документации”, либо превращают баг в отдельную задачу на доработку функционала

2 Аналитик знает об этом баге и уже положил задачу в бэклог/это починится в какой-то другой задаче “само”

3 Аналитик говорит, что это не баг, а фича. Задачку закроют с комментарием “Отклонено. Так и должно быть”

Отдельная рекомендация: лучше все обсуждения, договоренности фиксировать в комментариях к задаче.

Лично у меня комбо из понятно описанного бага и обсуждения с аналитиком сводит любые споры с разработчиками к нулю