Every browser has built-in developer tools — DevTools. Open them with F12 (or right-click → "Inspect"). The name says "developer," but a tester needs these tools almost as much as a developer does: they turn testing from "clicking around on the outside, guessing" into grey-box testing, where you can see what's actually happening under the hood of the page.
You don't need to go through every tab. For a tester four are enough: Console, Network, Elements and Application (storage). Let's walk through each one.
Console — page errors
The Console tab shows messages that the page outputs for developers — and, most valuable for you, errors. They usually appear in red.
Why a tester needs this: if something on the page behaves strangely (a button doesn't fire, data won't load), the console often has a red error explaining why. Even if you don't understand the full error text, a screenshot of that error in a bug report is gold for a developer — they can immediately see where to look.
Practical rule: noticed a bug — peek at the console before filing it. There's a red error — attach it.
Network — requests to the server
The Network tab shows every request the page makes to the server: for data, for images, when submitting a form. Each row is one request. To see them, open Network and refresh the page or perform an action (for example, click "Log in").
What a tester looks at here:
- Request status. A number like 200 means success; 400/404 means something is wrong with the request; 500 means an error on the server. Red rows with status 500 are a sure sign of a server-side bug.
- What was sent and what came back. By clicking on a request you can see what data the page sent to the server and what it responded with. This helps you understand where things broke: on the page's side (it sent the wrong thing) or the server's side (it responded incorrectly).
A practical example: a form "silently" doesn't save. In Network you see: the request went out, and the server responded with status 500. So the bug is on the server, not in the button — and that's a valuable detail for the report.
Elements — the structure of the page
The Elements tab shows the HTML structure of the page — what it's built from — and lets you temporarily change it right in the browser (for yourself only, not for everyone).
What's useful for a tester:
- See what's actually there. For example, a field looks empty, but in the markup you can see a value is present, it's just not displayed.
- Check texts and labels — do they match the design mockup exactly.
- Quickly test long text: temporarily type a very long string into a field right in the markup to see whether the layout breaks.
A beginner doesn't need to dig deep into Elements, but being able to look and see the structure is a useful skill.
Application — what the page stores locally
Some bugs don't reproduce in a clean browser and live "only on my machine": everyone has their own saved state. Everything the page has put aside sits in the Application tab (in Firefox — "Storage"), and that is where you delete it piece by piece.
Four shelves in the browser with different lifetimes: SessionStorage dies with the tab, a session cookie with the browser, LocalStorage lives until someone clears it, and the cache is dropped by a hard reload. Hence the different symptoms: "logged out" is about cookies, "shows the old version" is about the cache.
Cookies are small "name — value" pairs that the browser attaches to every request to this domain by itself: a session id, the chosen language, a consent mark. Besides name and value a cookie has an expiry (Expires) and two flags worth checking: HttpOnly — the cookie can't be reached by the page's scripts, only the browser sends it; Secure — the cookie travels over HTTPS only. A session cookie must have both, and an empty cell in that table is a defect.
LocalStorage and SessionStorage are bigger stores that the page fills and reads itself; they never travel to the server. The one difference is lifetime: LocalStorage survives a reload and a browser restart until someone clears it; SessionStorage lives until the tab is closed, and in a neighbouring tab it isn't there at all. What sits in them is a form draft, collapsed panels, the chosen filter, sometimes a token. Hence a check: whatever was promised to be "remembered" has to live in LocalStorage — otherwise it was remembered only until the tab closes.
Lower in the same tab is the cache: saved page files and server responses.
Cookies vs cache
They get mixed up, though they are different shelves. Cookies are data about you: who logged in, which language, what is in the cart; the browser attaches them to requests. The cache is copies of files and responses, kept so they don't have to be downloaded twice. The symptoms differ accordingly: cookies gone — you are logged out and the cart is empty; the cache kicked in — you see an old version of the page while the server already serves a new one.
The second one makes a false bug easy to file: the fix has been deployed, but yesterday's script file is sitting in your browser — "nothing got fixed". For that case Network has a "Disable cache" checkbox: it works while DevTools are open, and checks of a fresh deployment are done with it on. The second trick is a hard reload (Ctrl+Shift+R, on Mac Cmd+Shift+R): the page and its files are downloaded again.
The rule is simple: before filing a bug about "it didn't apply" or "it shows the old thing", repeat the scenario with the cache disabled or in a private window. It repeated — the bug is real; it didn't — that was your cache.
The CORS error in the console
Red text like "blocked by CORS policy" scares people more than anything else and looks like a browser failure. In fact it is a security rule: a page on one address cannot read a response from another until that other one allows it. The permission arrives as the Access-Control-Allow-Origin header in the response — which means it is fixed on the server, not in the browser.
In Network it looks like this: the request went out, the response may even be 200, but the page never got it and showed nothing. A common cause is that the front end of a test environment is opened at one address while the API answers at another, and the address of the environment was left out of the allowed list.
A bug report takes the page address, the request address, the method, the full error text from the console and the response headers — that is enough to see which domain was not allowed. Fixing this with an extension that disables the check is not an option: the bug hides for you and stays for the user.
Device emulation
DevTools has a mode that shows the page as it would look on a phone of a given size — handy for a quick responsiveness check, though it doesn't replace a real device.
Where this applies
DevTools is the shift from "I'm tapping on the outside and guessing" to "I can see what happened." Practically every non-obvious bug is worth checking with the tools open: a red error in the console or a failed request in Network often points directly at the cause and makes your bug report many times more useful. This is one of the main skills that sets apart a junior who "just clicks" from one who understands what's happening.
Where beginners stumble:
- Not opening DevTools at all and filing bugs like "the form doesn't work," when the console has the cause spelled out right there.
- Being intimidated by unfamiliar error text. You don't need to understand everything — just attach a screenshot; the developer will figure it out.
- Not knowing where things broke. Network helps you tell apart: the page sent the wrong thing (client) or the server responded incorrectly (500).
- Filing a bug on your own cache. "Nothing changed after the deployment" is often cured by the "Disable cache" checkbox and a hard reload — check that before writing the report.
What to learn next. Network showed that the page communicates with the server via requests. You can also check those requests directly, without the UI — that's API testing basics in Postman.