Кого можно привлечь для решения конфликта с разработчиком, если он отказывается признавать дефект

Что проверяют

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

Как отвечать

Сначала выясните природу спора, от неё зависит, кого звать. Обычно это одно из трёх: разработчик не может воспроизвести, считает поведение правильным или согласен, что это баг, но не хочет чинить сейчас.

Первый шаг всегда ваш. Уточните окружение, версию сборки, тестовые данные, фича-флаги, приложите логи, запись экрана, запрос и ответ из DevTools или Charles. Потом покажите баг разработчику вживую: пять минут у экрана снимают половину споров.

Если не помогло, привлекайте по сути вопроса:

• аналитик или владелец продукта: когда спор о том, как система должна работать. Баг это расхождение фактического поведения с ожидаемым, а ожидаемое определяют требования и критерии приёмки;
• дизайнер: если речь о расхождении с макетом;
• техлид или ведущий разработчик: когда спор технический, например «так работает библиотека» или «это ограничение API»;
• QA лид: если нужна поддержка в оценке серьёзности или договорённость о процессе;
• триаж или менеджер проекта: когда баг признан, но нет согласия по приоритету и сроку.

Итог фиксируйте в трекере: статус вроде «Won't fix» или «Works as designed» с комментарием, кто и почему так решил. Если требование было неясным, заведите задачу на его уточнение, чтобы спор не повторился.

Где спотыкаются

Идут к менеджеру раньше, чем поговорили с разработчиком. Это воспринимается как жалоба и портит отношения на весь проект.

Спорят о правоте, а не о требованиях. Когда требования молчат, решает не QA и не разработчик, а владелец продукта.

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