Как ответить на вопрос «Как понять, где баг: на фронтенде или на бэкенде» на собеседовании QA

Зачем это спрашивают

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

Интервьюер проверяет, есть ли у вас метод, а не интуиция. Ответ «по ощущениям» или «если красное в консоли» говорит, что вы не открывали вкладку Network осознанно. Заодно часто следует уточнение: что именно вы в этой вкладке смотрите.

Как построить сильный ответ

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

Правило трёх точек: отправлено — получено — показано

Любое действие пользователя в веб-приложении проходит три точки. Фронтенд формирует и отправляет запрос. Бэкенд обрабатывает его и возвращает ответ. Фронтенд показывает результат. Найдите нужный запрос в Network и сравните эти три точки с ожиданием.

Что смотреть во вкладке Network

• Фильтр Fetch/XHR, чтобы оставить только запросы к API, и поиск по адресу.
• В строке запроса — метод, адрес, статус, время.
• Headers — заголовки запроса и ответа, в том числе авторизация и тип содержимого.
• Payload — что именно отправил фронтенд в теле или параметрах.
• Preview и Response — что вернул сервер.
• Timing — где ушло время: ожидание ответа сервера или загрузка.
• Preserve log, чтобы запросы не пропадали при переходе между страницами, Disable cache и Throttling для медленной сети.
• Copy as cURL и сохранение HAR для баг-репорта.

Перепроверка в обход интерфейса

Если есть сомнение, повторите тот же запрос через Postman или curl. Сервер ответил так же неверно — проблема на бэкенде. Ответ правильный — значит, дело в том, как фронтенд формирует запрос или отображает результат.

Где правило требует аккуратности

• Ответ 200, а в теле ошибка — формально успех, но по смыслу сломан ответ сервера.
• Ошибка 4xx может означать, что фронтенд отправил неверный запрос: 400 при пустом поле, которое форма обязана была заполнить, — повод посмотреть на обе стороны.
• Кэш: устаревшие данные могут прийти из кэша браузера, а не с сервера, — проверьте с Disable cache.
• Ошибка CORS видна в Console, но чинится настройками сервера.

Пример ответа

Я иду по правилу «отправлено — получено — показано». Открываю DevTools, вкладку Network с фильтром Fetch/XHR и повторяю действие. Если запроса нет или он ушёл с неправильными данными — например, не тот id товара в Payload, — это фронтенд. Если запрос правильный, а сервер вернул неверные данные или пятисотую ошибку — бэкенд. Если ответ правильный, а на экране другое — снова фронтенд, ошибка в отображении. Когда сомневаюсь, повторяю запрос через Postman: так я исключаю интерфейс. В баг-репорт прикладываю метод, адрес, статус, тело запроса и ответа или cURL, предварительно убрав токены. И отдельно смотрю Console, но учитываю, что ошибки могут быть от расширений браузера.

Частые ошибки

• Решать по Console: «красное — значит фронтенд». Красное в Console бывает и от расширений, и от ответа 500, который вернул сервер.
• Смотреть только на статус. 200 не означает, что ответ правильный, а 400 не всегда вина сервера.
• Не проверять, ушёл ли запрос вообще. Кнопка, которая ничего не отправляет, — классический фронтенд-баг.
• Считать валидацию на форме достаточной и не проверять API в обход интерфейса.
• Прикладывать к репорту скриншот Network вместо текста запроса, ответа или cURL, а также оставлять в них рабочие токены.

Пример на MarketCove

Представьте ситуацию в учебном магазине https://shop.tomiddle.com: в истории заказов в профиле дата заказа, оформленного поздно вечером, отображается следующим днём. Где искать?

1. Откройте Network, включите Preserve log и обновите страницу профиля.
2. Найдите запрос к /api/orders и проверьте Headers: ушёл ли токен того пользователя, под которым вы вошли.
3. Откройте Response: какую дату и в каком формате вернул сервер — с часовым поясом или без.
4. Сравните с тем, что показано на странице.

Если запрос ушёл не с тем токеном — ищите на фронтенде. Если сервер вернул неверное время — бэкенд, и это можно подтвердить тем же запросом из Swagger на /api/docs. Если в ответе время верное, а на странице дата сдвинута — снова фронтенд: скорее всего, ошибка в переводе в местный часовой пояс. Каждый вариант даёт свой баг-репорт со своим исполнителем и своими доказательствами. Как такие доказательства оформить, разобрано в статье про баг-репорт.

Задание для практики

Возьмите любое действие в веб-приложении — добавление в корзину, сохранение профиля, вход — и разложите его на три точки. Выпишите адрес и метод запроса, что ушло в Payload и что вернулось в Response. Затем повторите тот же запрос через cURL из Copy as cURL и сравните ответ. Для тренировки придумайте три гипотетических бага — по одному на каждую точку — и для каждого напишите, какой команде он уйдёт и что вы приложите. Проверить формулировки поможет тренажёр баг-репортов.