Browser DevTools for Testers

Why it matters

The screen shows a failure; the defect behind it is in the page's code, the server or the data. A report that says "Save does not work" makes a developer start from zero. "Save sends PATCH /api/v1/profile, the server answers 422 and the page still shows success" already tells the team that the server rejected the input and the page ignored the rejection.

DevTools also reveals failures the interface hides: a script error behind a button that does nothing, a request that fails silently, a session cookie that survives logout. Knowing the question each panel answers turns guessing into evidence.

One question per panel

Six panels cover most testing work. This lesson uses their names in Chrome; the DevTools in Edge are built from the same Chromium code, so names and layout match almost everywhere. Firefox and Safari have the same tools, in places under other names: Inspector for Elements in Firefox, Storage for Application and Responsive Design Mode for the device toolbar in both. Open the panel whose question matches the symptom in front of you.

• Elements: what is on the page right now, and why does it look like this?
• Console: did the page's code fail, and what did it say?
• Network: what did the browser send, what came back, and how long did it take?
• Application: what does this site store in my browser?
• Performance: where does the time go during a load or a click?
• Device toolbar: how does the layout respond to a phone-sized screen and to touch?

Elements and Console: the page and its code

Elements shows the live DOM, as in the lesson on the DOM. Select a node and the Styles pane lists the CSS rules that apply to it, with overridden declarations struck through: that is how you see why a button is grey or a label is cut off. The Accessibility pane shows its computed role and its accessible name, the name a screen reader announces.

You can edit text and styles in place to probe a problem, for example paste a long Arabic word into a label to see whether it overflows. Edits stay in your tab and vanish on reload: they show where a defect might be, not that the product works.

The Console lists JavaScript errors and warnings, failed resource loads and security messages, most of them linked to the file and line or the URL they come from. You can also type expressions to ask the page questions, as below. Never paste code you do not understand: it runs with your logged-in session. One limit: Chrome reduces navigator.userAgent to the major version followed by .0.0.0 and a fixed OS version, so take the exact browser version from its About page.

$0                            // the element selected in Elements
$0.disabled                   // is that button disabled right now?
$$('img:not([alt])').length   // images without an alt attribute
navigator.userAgent           // browser and OS; Chrome gives the major version only

Try it: User-Agent Parser

Network: what was sent and what came back

The Network panel records every request made while DevTools is open, with its status code, type, initiator, size and time. Click one to see its headers, the payload the page sent, the response and the timing.

One request tells you which side to suspect. Wrong data in the request: look at the page. Right request, wrong response: look at the server. Both right but the screen is wrong: look at how the page handles the response. A request that got no answer shows (failed) instead of a status code.

Open the panel before you reproduce the problem; earlier requests are not listed. Then use:

• Preserve log, to keep the list when the page navigates, for example after a form submits.
• Disable cache, so requests skip the browser's HTTP cache while DevTools is open. Cookies, stored data and any service worker stay, so for a first-time visitor's view use a private window.
• Throttling, to simulate a slow connection or going offline and see the loading and error states.
• The Fetch/XHR filter, to hide static files and keep the calls that carry data.
• Copy as cURL, which turns the request into a command for curl, a command-line program that sends HTTP requests, so a developer can replay exactly what was sent. The command contains your cookies and the Authorization header: remove them before you share it.
• Export HAR, to save every listed request in one file for the bug report. Chrome leaves out the Cookie, Set-Cookie and Authorization headers by default, but request and response bodies can still hold personal data.

Try it: cURL Parser Try it: HTTP Headers Parser Try it: JSON Formatter

Application, Performance and the device toolbar

Application shows what the site stores in your browser: cookies with their attributes (HttpOnly, Secure, SameSite, expiry, explained in the lesson on cookies and web storage), local and session storage, IndexedDB and service workers. You can edit or delete entries, or clear the site data to start fresh. A typical check: after logout, is the session cookie, the one that keeps you logged in, gone?

Performance records a load or an interaction and shows what the browser's main thread was doing. Long tasks, those over 50 ms, are marked in red and layout shifts have their own track, which explains a click that responds late or content that jumps. Results from your laptop are lab measurements, not your users' experience.

The device toolbar emulates a phone or tablet viewport, its pixel ratio, touch events and, with a device preset, its user agent. It is a fast first layout check, but the engine, CPU and fonts are still your desktop browser's; confirm important findings on a real device. The lesson on responsive testing goes through its limits in "What the device toolbar can and cannot tell you".

Try it: Cookie Analyzer

Worked example: "Profile saved", but nothing was saved

On staging, a tester changes the phone number to +966 50 123 4567, clicks Save and sees "Profile saved"; after a reload the old number is back. Instead of filing "Save does not work", she turns on Preserve log, filters on Fetch/XHR and repeats the steps:

• The PATCH request (the HTTP method for changing part of a resource) carried the new number: the form collected the input correctly.
• The server answered 422 (Unprocessable Content in RFC 9110), a refusal of the data: nothing was saved, as the GET after the reload confirms.
• The page showed success anyway, so it does not check the response status; as in the lesson on JavaScript basics, a 4xx answer does not make fetch() fail. That is a defect in the page.
• Are spaces allowed in a phone number? The requirement decides whether the server's validation has a second defect.
• The report describes the page defect, raises the phone-format question and attaches the screenshot, the request and the response, without the session cookie.

Console   (no errors)

Network   Fetch/XHR, Preserve log on
  PATCH  https://staging.example.com/api/v1/profile
  Status:    422
  Payload:   {"phone":"+966 50 123 4567"}
  Response:  {"field":"phone","message":"Invalid phone format"}

  GET    https://staging.example.com/api/v1/profile    (after reload)
  Status:    200
  Response:  {"name":"Sara","phone":"+966501112233"}

Try it: HTTP Status Code Lookup

Frequently asked questions

References

• What are browser developer tools? — MDNMDN Web Docs (Mozilla)An introduction to the developer tools built into browsers — the inspector, the JavaScript console and the debugger — for examining a page while testing it.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• Using HTTP cookies — MDNMDN Web Docs (Mozilla)Cookie lifetime, scope, the Secure/HttpOnly/SameSite attributes and their security implications.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.