Что делать, если разработчик отказывается признавать проблему и не хочет проверять код

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

Не характер, а процесс. Умеете ли вы сделать дефект неотвратимым фактом и знаете ли, кто на самом деле принимает решение чинить или не чинить. Конфликт в вопросе только декорация, за ней смотрят на качество вашего баг-репорта и понимание границ роли.

Как отвечать

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

Дальше сделайте воспроизведение минимальным и объективным:

• короткие шаги от чистого состояния, ожидаемый и фактический результат;
• номер сборки, окружение, время и сквозной идентификатор запроса;
• доказательство на уровне данных: запрос и ответ, лог, запись экрана, файл сетевой сессии;
• ссылка на требование, макет или описание API, с которым расходится поведение.

Разговор ведите про артефакт, а не про человека: не «ты ошибся», а «вот ответ сервиса, вот пункт спецификации, они расходятся». Предложите посмотреть вместе на стенде, это занимает минуты и снимает спор о воспроизводимости.

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

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

Несут дефект на словах, без данных. Разработчик не воспроизвёл за две минуты и закрыл задачу, и формально он прав.

Второе: спорят публично в общем канале. Человек начинает защищать репутацию, а не разбираться, и шанс на спокойную совместную проверку исчезает.

Третье: путают «это не баг» и «мы не будем это чинить». Первое решается требованиями, второе приоритетом, и адресаты у этих решений разные.