Что можно делать на вкладке Network в DevTools

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

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

Как отвечать

Опишите вкладку через задачи тестировщика, на примере Chrome DevTools:

• список и фильтры: типы Fetch/XHR, Doc, JS, WS, строка фильтра с status-code:500, method:POST, domain:, larger-than:. Поиск по Ctrl+F ищет и по телам ответов;
• детали запроса: Headers (URL, метод, статус, куки, CORS-заголовки), Payload (что реально ушло с формы), Preview и Response (что вернул сервер), Initiator (какой код вызвал запрос);
• Timing: где потрачено время. Долгий Waiting for server response (TTFB) указывает на медленный бэкенд, долгий Content Download на тяжёлый ответ, Queueing и Stalled на очередь соединений;
• Preserve log и Disable cache: первый сохраняет запросы при переходах и редиректах, второй отключает кэш, пока открыты DevTools. Колонка Size покажет (memory cache) или (disk cache);
• Throttling: пресеты медленной сети и режим Offline для проверки лоадеров, таймаутов и повторных отправок;
• блокировка и подмена: Block request URL показывает поведение без скрипта или API, Overrides подменяют ответ и заголовки локально;
• экспорт: Copy as cURL для воспроизведения в терминале или Postman, HAR-файл для баг-репорта. Свежие версии Chrome по умолчанию выгружают HAR без чувствительных данных.

WebSocket-сообщения смотрят во вкладке Messages у соответствующего запроса.

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

Считают статус 200 признаком успеха. Многие API отдают 200 с {"error": ...} в теле, поэтому смотреть надо и на Response.

Ищут в Chrome «изменить и отправить заново». Такой функции там нет, Replay XHR повторяет запрос как есть. Правят через Copy as fetch в консоли или cURL в Postman, а в Firefox есть Edit and Resend.

Не включают Preserve log и теряют запрос, который ушёл прямо перед редиректом после логина.