DevTools and network debugging

Every tester eventually hits a bug that only shows up in the browser, not in the test framework's output. The test says the click happened, the assertion says the element exists, but something visibly broke and nobody can explain why from the automation logs alone. DevTools is where that gap closes. Reading the network tab, throttling a connection, replaying a request, and catching a console error the test swallowed is the fastest feedback loop a tester owns. It is faster than filing a ticket and waiting for a developer to look. Speed of diagnosis is most of what makes a tester look senior to the rest of the team.

The network tab tells you what actually happened

The network tab records every request the page made: the URL, the method, the status code, the response body, and the timing. When a test fails because "the data never loaded," the network tab answers in seconds whether the request was sent at all, what it returned, and how long it took. A 200 with an empty body is a different bug than a 500. A request that never fired is a third bug entirely, and none of these show up the same way in a test's pass or fail output.

Filtering by type, XHR/Fetch for API calls, Doc for the page itself, cuts the noise fast on a page loading dozens of resources. Sorting by time surfaces the slowest request, which is often the one blocking everything visually downstream of it. This overlaps with the environment layer covered in cloud basics, since a request pointed at the wrong host shows up here first.

Replaying a request without rerunning the whole test

Right-click any request in the network tab and copy it as a cURL command, or copy it as fetch to paste into the console. This lets you replay the exact request, headers and all, outside the test entirely. It is the fastest way to tell whether a failure is in the backend response or in how the frontend handled that response.

If the replayed request returns the correct data, the bug lives in the frontend's handling of the response, not the API. That single check saves a round trip to the backend team and points automation debugging at the right layer immediately.

Throttling reveals timing bugs a fast connection hides

DevTools can simulate a slow 3G connection. Consider what this catches: an entire class of bug that never appears on a developer's fiber connection. A race condition where a component renders before its data arrives, a loading spinner that never shows because the request usually resolves too fast to notice, a timeout set too aggressively for a real user's network.

For instance, consider a QA engineer at a small logistics startup who once chased an intermittent test failure on a dashboard page. The test passed nine times out of ten. Throttling the network to "Slow 3G" reproduced the failure every single time. It turned out the dashboard fired two API calls in parallel and assumed the first to resolve was always the user's data, when a slow network made the order unpredictable. Throttling turned an intermittent flaky test into a deterministic, always-reproducing bug in under a minute.

Catching the console error the test swallowed

A test can pass while the browser console fills with errors, because most test frameworks only fail on the assertions you wrote, not on every console error. A component can throw, get caught by an error boundary, and render something visually acceptable while logging a stack trace nobody reads.

Checking the console for red text after every failing test, and periodically during a passing run, catches bugs before they compound. This matters even more once a page involves client-side hydration or shadow DOM quirks, where an error thrown mid-render can silently degrade the page without failing any single assertion. Consider a page that logs a hydration mismatch warning on every load without a single visible glitch, the kind of thing a test suite never catches because nothing actually broke on screen.

Three habits catch most of what a passing test still misses, and running them against real container-based environments such as those covered in Docker and Compose closes most remaining gaps:

• Check the console for uncaught errors and warnings after every test run, not just failing ones.
• Filter network requests by status code to spot a silent 4xx or 5xx hiding behind a successful-looking page.
• Throttle to a slow connection at least once per feature, since most bugs a fast connection hides are timing bugs.

FAQ