Chrome DevTools для тестировщика: Network, Console, Application и поиск багов

«Кнопка не работает» — плохое описание бага.

«После клика POST /api/v1/orders уходит с корректным CreateOrderRequest, backend отвечает 500, запрос воспроизводится вне UI» — уже инженерная диагностика.

Разница между этими двумя формулировками часто начинается с Chrome DevTools.

DevTools встроен в Chrome и позволяет видеть DOM, сетевые запросы, JavaScript-ошибки, cookies, local storage, кеш, производительность и многое другое. Для Manual QA не нужно знать каждый panel. Несколько инструментов закрывают большую часть ежедневных задач: Network, Console, Elements и Application.

И это не «дополнительный плюс». В актуальных вакансиях Manual QA умение работать с DevTools встречается рядом с API, Postman, Swagger и SQL. Чем сложнее продукт, тем меньше пользы от тестировщика, который видит только то, что нарисовано на экране.

Самый простой способ:

• ▸Windows/Linux: F12 или Ctrl + Shift + I;
• ▸macOS: Cmd + Option + I;
• ▸правый клик по элементу → Inspect.

Chrome официально описывает DevTools как набор инструментов для просмотра и изменения страницы, диагностики сетевой активности, JavaScript, storage и performance.

Для QA начнём с панели, которая даёт максимальный ROI.

Network показывает сетевую активность страницы. Браузер загрузил HTML? Запросил картинку? Отправил REST API request? Получил 401? Всё это видно здесь.

Важно помнить: Network начинает писать события, пока DevTools открыт. Поэтому при расследовании бага:

• ▸1. открой DevTools;
• ▸2. перейди в Network;
• ▸3. очисти список;
• ▸4. повтори действие пользователя.

Если переход между страницами очищает список запросов, включи Preserve log.

Современная страница может сделать сотни запросов. Для API-проверок чаще всего пригодится фильтр Fetch/XHR.

Пример на ShawarmaShop: пользователь оформляет заказ.

После клика в Network появляется:

1POST /api/v1/orders     200

Открываем строку и смотрим детали.

Увеличить

Headers

Здесь будут URL, method, status code, request headers и response headers.

Что полезно QA:

1Request URL
2Request Method
3Status Code
4Content-Type
5Authorization
6Origin
7Cookie
8Cache-Control

Ситуация: UI показывает «Ошибка оформления заказа».

Если API вернул 200, возможно, проблема во frontend-обработке ответа. Если API вернул 500, UI просто показывает симптом backend-ошибки.

Уже одна эта проверка экономит время всей команды.

Payload

Для POST/PUT/PATCH запросов DevTools показывает данные, отправленные серверу.

Например пользователь выбрал рецепт и количество 2:

1recipeId: 42
2qty: 2
3payment.method: CARD

а frontend отправил:

1{
2  "recipeId": 42,
3  "qty": 3,
4  "payment": { "method": "CARD" }
5}

UI может выглядеть абсолютно правильно. Но ошибка уже локализована: неверные данные появились до backend.

Response / Preview

Здесь видно тело ответа.

Например:

1{
2  "id": 7812,
3  "status": "PENDING",
4  "qty": 2,
5  "totalPrice": 890
6}

А UI показывает просто:

Что-то пошло не так.

Если backend вернул корректный OrderResponse, а UI показал неправильный статус, количество или сумму — это сильный сигнал в сторону frontend mapping/rendering.

Открой публичный стенд ShawarmaShop и попробуй связать действия UI с API.

• Открыть учебный стенд ShawarmaShop

  Реальный интерфейс приложения для практики UI и поиска запросов в DevTools.

• Открыть Swagger UI ShawarmaShop

  Контракт API, endpoints, request body, schemas и responses.

Сценарий:

• ▸1. открой DevTools → Network;
• ▸2. поставь Fetch/XHR;
• ▸3. выполни одно действие в интерфейсе;
• ▸4. найди новый запрос;
• ▸5. определи method;
• ▸6. посмотри request payload;
• ▸7. посмотри response;
• ▸8. найди status code;
• ▸9. попробуй объяснить, что именно сделал backend.

Для этого стенда у нас уже есть эталон из OpenAPI: создание заказа — POST /api/v1/orders, успешный ответ документирован как 200, новый заказ приходит со status=PENDING. Но смысл упражнения всё равно в том, чтобы увидеть этот вызов самостоятельно в Network и сравнить факт с контрактом.

После этого правый клик по запросу → Copy as cURL. Этот запрос можно перенести в Postman и повторить без UI. Продолжение практики есть в статье Postman для тестировщика: тестируем REST API с нуля.

Console выполняет две основные задачи: показывает сообщения/ошибки JavaScript и позволяет выполнять JavaScript вручную.

Представим баг: при клике «Оплатить» ничего не происходит.

В Console появляется:

1TypeError: Cannot read properties of undefined (reading 'id')

Network при этом пустой.

Это сильный сигнал: frontend упал до отправки запроса.

Для баг-репорта уже можно добавить:

• ▸шаги;
• ▸скрин/видео;
• ▸текст ошибки из Console;
• ▸отсутствие network request;
• ▸browser/version.

Разработчику намного проще начать расследование.

Console часто заполнена warnings от библиотек, расширений браузера и сторонних скриптов.

Смотри на время ошибки и воспроизводи баг после очистки Console. Если ошибка появляется ровно после действия — связь намного сильнее.

А ещё проверь сценарий в Incognito без расширений. Иногда «баг продукта» оказывается расширением браузера.

Elements показывает DOM страницы.

Для QA полезно проверять:

• ▸существует ли элемент в DOM;
• ▸скрыт он или удалён;
• ▸disabled ли кнопка;
• ▸какие атрибуты у элемента;
• ▸есть ли id, name, data-testid, aria-*;
• ▸что меняется после действия пользователя.

Например визуально кнопка недоступна. В DOM:

1<button disabled="">Pay</button>

Это реальный disabled state.

А другой вариант:

1<button class="opacity-50">Pay</button>

Она только выглядит disabled, но может оставаться кликабельной.

Так обнаруживаются неприятные UX и accessibility дефекты.

Если хочешь отдельно прокачать локаторы, у ThreadQA есть бесплатный XPath Practice Hub с реальными UI-компонентами и XPath/CSS примерами.

Application особенно полезен при тестировании авторизации, настроек и состояний пользователя. В OpenAPI ShawarmaShop авторизация описана как Bearer JWT, но спецификация не говорит, где именно frontend хранит token — cookie, localStorage, memory или иначе. Это implementation detail, который как раз и можно проверить через DevTools.

Там можно посмотреть:

• ▸Cookies;
• ▸Local Storage;
• ▸Session Storage;
• ▸IndexedDB;
• ▸Cache Storage;
• ▸Service Workers.

Chrome отдельно описывает Application как панель для диагностики storage, cache и других частей web app.

Проверка:

• ▸1. авторизуйся;
• ▸2. Application → Cookies / Local Storage;
• ▸3. зафиксируй, что появилось;
• ▸4. нажми Logout;
• ▸5. посмотри, какие данные исчезли;
• ▸6. обнови страницу;
• ▸7. нажми Back;
• ▸8. попробуй открыть protected URL напрямую.

Если UI сделал redirect на login, но auth token остался рабочим — это совсем другой класс проблемы, чем просто «кнопка logout странно работает».

Увеличить

У cookies есть важные атрибуты:

• ▸Secure;
• ▸HttpOnly;
• ▸SameSite;
• ▸Domain;
• ▸Path;
• ▸Expires / Max-Age.

Не нужно становиться security engineer, чтобы заметить подозрительное поведение. Например, сессионная cookie неожиданно живёт неделю после logout или отправляется не туда, куда ожидалось.

В Network можно включить Disable cache (пока DevTools открыт).

Это полезно, когда:

• ▸после релиза у одного пользователя старая версия JS;
• ▸UI не обновляется;
• ▸баг исчезает после hard refresh;
• ▸картинки/CSS ведут себя по-разному на разных машинах.

Сравни поведение с кешем и без него.

Не надо сразу писать «проблема в кеше». Зафиксируй различие и приложи данные.

QA часто тестирует на хорошем Wi-Fi и мощном ноутбуке. Пользователь — нет.

В Network можно эмулировать более медленное соединение.

Проверь:

• ▸есть ли loader;
• ▸можно ли нажать Submit дважды;
• ▸что произойдёт при долгом API response;
• ▸не исчезает ли форма;
• ▸появляется ли retry;
• ▸блокируется ли кнопка после первого клика.

Очень частый дефект:

• ▸1. запрос идёт 3 секунды;
• ▸2. кнопка остаётся активной;
• ▸3. пользователь нажимает её три раза;
• ▸4. backend создаёт три заказа.

При идеальной сети такой баг легко пропустить.

Нет универсального алгоритма, но Network даёт хороший старт.

Сценарий 1: кнопка нажата, запрос вообще не появился

Проверяй frontend: event handler, validation, JS error, disabled state.

Сценарий 2: запрос ушёл с неправильными данными

Вероятный frontend/client-side issue или проблема формирования payload.

Сценарий 3: запрос корректный, backend вернул 4xx

Нужно понять контракт: пользователь сделал невалидное действие или backend отклонил корректный запрос.

Сценарий 4: корректный запрос вернул 500

Сильный кандидат на backend defect.

Сценарий 5: backend вернул правильные данные, UI показал неправильные

Смотри frontend mapping/rendering/state.

Это не судебная экспертиза — окончательную причину подтвердит команда. Но хороший QA приносит не только симптом, а факты.

Вместо:

Не создаётся заказ.

Напиши:

При создании заказа UI показывает общий error toast. POST /... отправляется один раз, request body соответствует введённым данным. Backend отвечает 500; response содержит internal error. В Console frontend exceptions нет. Воспроизводится 5/5 на тестовом окружении.

И приложи:

• ▸HAR или screenshot Network, если это допускает политика проекта;
• ▸Request ID / Trace ID из response headers, если он есть;
• ▸response body без секретов;
• ▸timestamp;
• ▸окружение.

Важно: HAR и headers могут содержать cookies/tokens. Перед публикацией в публичных местах очищай секреты.

Посмотри, что мы уже сделали руками:

1UI action
2↓
3нашли POST в Network
4↓
5проверили payload
6↓
7проверили status + response
8↓
9повторили запрос отдельно

Автотест делает ту же цепочку без ручного клика.

Для API это может быть REST Assured:

1given()
2    .contentType(ContentType.JSON)
3    .body(request)
4.when()
5    .post("/api/v1/orders")
6.then()
7    .statusCode(200)
8    .body("status", equalTo("PENDING"));

Для UI — Selenide:

1$("[data-testid='order-button']").click();
2$("[data-testid='success-toast']")
3    .shouldHave(text("Заказ создан"));

Для проверки данных — JDBC/PostgreSQL. Например, id из POST /api/v1/orders можно найти в orders и сверить recipe_id, qty, total_price и status; после /pay — проверить связанную запись в payments и idempotency_key.

В Java QA Automation от ThreadQA эти части собраны в один маршрут: Java 21, REST Assured, Selenide, PostgreSQL, Kafka, WireMock, Allure, Docker и GitLab CI вокруг ShawarmaShop.

Не нужно сначала «перестать быть manual». Сильная автоматизация начинается как раз с умения хорошо расследовать систему руками.

Когда воспроизводишь web-баг, спроси себя:

• ▸появился ли request;
• ▸какой method;
• ▸какой status;
• ▸корректный ли payload;
• ▸что в response;
• ▸есть ли frontend error в Console;
• ▸изменились ли cookies/storage;
• ▸зависит ли проблема от cache;
• ▸воспроизводится ли на медленной сети;
• ▸можно ли повторить API request отдельно от UI.

Если ты регулярно умеешь ответить хотя бы на половину этих вопросов, ценность твоего баг-репорта уже сильно выше.

• ▸Postman для тестировщика: REST API с нуля
• ▸HTTP для тестировщика: методы, коды, headers и cookies
• ▸Swagger/OpenAPI для тестировщика
• ▸SQL для тестировщика: 20 рабочих запросов
• ▸XPath Practice Hub

Что должен знать тестировщик в Chrome DevTools?

Для начала достаточно уверенно пользоваться Network, Console, Elements и Application. Остальные панели добавляй под конкретные задачи.

Что смотреть в Network при баге?

Method, URL, status code, request headers, payload и response. Сравни ожидаемые данные с тем, что реально ушло на сервер.

Можно ли тестировать API только через DevTools?

DevTools отлично показывает запросы браузера, но для систематических API-проверок удобнее Postman/аналогичный клиент. DevTools помогает обнаружить запрос, а Postman — воспроизводить и изменять его.

Нужно ли Manual QA уметь JavaScript для Console?

На старте нет. Умения читать ошибки и выполнять простые выражения уже достаточно. JavaScript можно добавить позже.

DevTools пригодится в автоматизации?

Да. Даже если UI-тест написан на Selenide/Selenium, Network и Console остаются важными инструментами диагностики flaky-тестов и продуктовых дефектов.