На кого оформлять баг, если кнопка не работает: на фронтендера или бэкендера?

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

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

Как отвечать

Правильный ответ начинается с отказа гадать. Кнопка не работает это симптом, а не диагноз, и диагноз ставится за минуту:

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

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

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

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

Второе: заводят заявку без артефактов. Без времени, окружения и идентификатора запроса бэкендер не найдёт запись в логах, и задача вернётся с формулировкой «не воспроизводится».

Третье: считают код ответа приговором. Ответ 200 с телом об ошибке внутри это баг бэкенда, а 400 на валидном теле это баг валидации, а не клиента. Код статуса подсказка, а не доказательство.