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 starting out, three are enough: Console, Network, and Elements. 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.

A couple more useful things

  • 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.
  • Application tab. There you can see what the page is storing locally (cookies, local storage). Useful later, for more in-depth checks.

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).

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.