DevTools for Testers
You don't need to be a developer to use browser DevTools. These five tricks will help you find bugs that are invisible to the naked eye.
1 The Hook
A tester at an Auckland charity was checking a donation page. Everything looked fine. The form loaded. The buttons were clickable. The images displayed. But donations had dropped 40% since the last release.
She opened DevTools, clicked the Network tab, and tried to submit a $20 donation. The payment request showed a red 500 error. The server was failing every transaction. The page looked perfect, but the backend was broken. DevTools caught what visual inspection missed.
Every professional tester has DevTools open. Here's how to join them.
2 The Rule
What you see on the page is not always what the code is doing. DevTools lets you look under the hood.
Visual testing checks the surface. DevTools testing checks the structure, the errors, the network, and the accessibility. It's where half of all bugs hide.
3 The Analogy
A doctor's toolkit.
A doctor doesn't just look at you. They listen to your heart, check your blood pressure, and run tests. The patient might look fine but have a hidden problem. DevTools is the tester's stethoscope, blood pressure cuff, and X-ray machine — all built into the browser.
Senior engineer insight
The moment I stopped treating DevTools as a debugging tool and started treating it as a first-pass test tool, my defect-find rate doubled. Before I even read a test case, I open the Console and Network tabs and reload the page — if there are any red errors or failed requests, that's my first bug, found before I've written a single note. The thing that changed how I think: a silent JavaScript error can corrupt every user action downstream without throwing any visible indication to the user.
Most common Grad-level mistake: closing DevTools after checking the Console once at page load, then never re-opening it during user interactions where errors actually surface.
From the field
A Wellington government services team was testing a new form for benefit applications — the kind where real people's livelihoods depended on submissions going through. UAT sign-off was based entirely on visual testing: the form rendered, the button clicked, the success message appeared. The team assumed the job was done. On go-live day, the ops team spotted that zero submissions had reached the database in six hours. Opening the Network tab revealed that every POST to the API was returning a 413 Payload Too Large — the server was silently rejecting large file attachments while showing the user a fake success screen. Had anyone filtered Network by "Fetch/XHR" and clicked the submit button during UAT, that red response would have ended the story in minutes, not after six hours of production silence. The lesson: always confirm the network response, not just the UI reaction.
4 Watch Me Do It
Open any webpage. Press F12 (or Ctrl+Shift+I on Windows, Cmd+Option+I on Mac). Here's what to look at.
🔍 1. Elements Tab — Inspect HTML
Right-click any element and choose "Inspect." This shows the raw HTML. Use it to check:
• Is the image missing an alt attribute?
• Is the button actually a <button> or just a styled <div>?
• Are there hidden elements (display:none or visibility:hidden) that screen readers might still see?
• Does the heading structure make sense (h1, then h2, then h3)?
💡 2. Console Tab — Spot JavaScript Errors
Red text means JavaScript broke. Even one error can break an entire feature. Common red flags:
• Uncaught TypeError: Cannot read property... — something expected an element that wasn't there
• 404 Not Found — the page tried to load a missing file
• Failed to load resource — images, scripts, or stylesheets are missing
Rule: Any red error in the console is a bug until proven otherwise.
📡 3. Network Tab — See What the Page Loads
Reload the page with the Network tab open. Look for:
• Red rows — failed requests (images, APIs, fonts)
• Slow rows — anything over 1 second is worth investigating
• API calls — click a row to see the request and response
Pro tip: Filter by "Img" to see if any images fail to load. Filter by "Fetch/XHR" to watch API calls.
📱 4. Device Toolbar — Test Mobile
Click the phone icon (or press Ctrl+Shift+M) to simulate mobile. Check:
• Does the layout break at 375px width (iPhone SE)?
• Are buttons big enough to tap?
• Is text readable without zooming?
• Does the hamburger menu work?
♿ 5. Lighthouse — Run an Accessibility Audit
In DevTools, click the ">>" arrow and choose Lighthouse. Select "Accessibility" and click "analyse." In 10 seconds you get:
• Contrast ratio failures
• Missing alt text
• Incorrect heading order
• Missing form labels
Note: Lighthouse catches ~30% of a11y issues. It's a starting point, not a finish line.
Scenario 2: Network timing reveals performance issues
A user complains that checkout is slow. Your eyes see the page load instantly. But you open the Network tab and reload. You see:
| Request | Type | Time | Issue |
|---|---|---|---|
| payment-processor.js | Script | 3.2s | Slow third-party library |
| product-image.jpg | Image | 2.8s | Unoptimised image on checkout page |
| analytics.js | Script | 1.5s | Blocking analytics delaying checkout |
| checkout-api | XHR | 0.8s | OK |
The checkout API itself is fast, but third-party libraries and unoptimised assets make the page feel slow. DevTools revealed problems invisible to manual testing.
5 When to Use It / When NOT to Use It
✅ Open DevTools when...
- A feature looks broken but you can't see why
- You need to check alt text or heading structure
- A form submits but nothing happens
- You want to test mobile layout quickly
- You need a fast accessibility health check
❌ DevTools won't tell you...
- How a screen reader actually reads the page
- Whether the backend logic is correct
- How the page performs under heavy load
- If the database stored the right data
Before you apply this technique, ask:
- Is the issue visible in the browser's Network, Console, or Elements tab?
- Do you need to debug front-end logic or is this a back-end issue?
- Are you testing the actual user experience, or digging into technical implementation?
- Do you have time to open DevTools, or are you in a quick smoke test?
6 Common Mistakes
🚫 Ignoring yellow warnings
I used to think: Only red errors matter.
Actually: Yellow warnings often indicate deprecated features, security issues, or performance problems. Don't dismiss them.
🚫 Testing only in full-screen desktop
I used to think: If it works on my monitor, it's fine.
Actually: Over 60% of NZ web traffic is mobile. The Device Toolbar takes 2 seconds to open and will find layout bugs you'd never see otherwise.
🚫 Trusting Lighthouse blindly
I used to think: A 100 Lighthouse score means the site is fully accessible.
Actually: Lighthouse is automated. It can't judge whether alt text is meaningful, whether tab order makes sense, or whether colour choices are intuitive. Use it as a first filter, then test manually.
🚫 Over-relying on DevTools for real issues
I used to think: If DevTools shows no errors, the site works correctly.
Actually: DevTools finds front-end issues only. Back-end logic bugs, database errors, third-party API failures, and user experience problems rarely show in the console. DevTools is a supplement, not a replacement for manual testing.
When this technique fails
DevTools testing fails when you use it to diagnose issues that are invisible in the browser. Network tab shows timing but not user experience. Console shows JavaScript errors but not whether the logic is correct. If the issue is a missing network timing problem or a payment bug that only shows server-side, DevTools will mislead you. Always pair DevTools with manual user journey testing.
7 Now You Try
Task: Open this page in a new tab, press F12, and complete these three missions:
- In the Elements tab, find the
<h1>tag. What text does it contain? - In the Console tab, are there any red errors? (There shouldn't be — but check anyway.)
- In the Network tab, reload the page. How many requests does it make? Are any red?
This is a real skill, not a quiz. The goal is to build muscle memory.
Answers (may vary slightly by browser):
- The
<h1>contains "DevTools for Testers" (or the full title depending on element structure). - There should be zero red errors on this page. If you see any, that's a bug — report it!
- The page makes approximately 3-5 requests: the HTML document, style.css, bootcamp-core.js, guru-v2.js, and possibly favicon.png. None should be red.
Next step: Try the same exercise on a real website you use daily. You'll be surprised what you find.
Why teams fail here
- They check the Console at page load only — not during button clicks, form submissions, or navigation, which is when most JavaScript errors actually fire.
- They treat a
200 OKstatus in the Network tab as a pass without inspecting the response body — APIs routinely return 200 with an error payload embedded in the JSON. - They run Lighthouse once, see a score above 80, and skip manual accessibility checks — missing focus order issues, misleading alt text, and keyboard traps that automated tools cannot detect.
- They test mobile layout only on the Device Toolbar but never on a real device — the toolbar does not emulate touch events, system fonts, or network throttling the way a physical phone does, so layout and interaction bugs slip through to production.
Key takeaway
DevTools is not a debugging tool you reach for when something looks broken — it is the first tab you open before you even read the test case, because what the page shows the user and what the browser is actually doing are often two completely different stories.
8 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about DevTools for Testers at the Grad level.
Q1. How would you use browser DevTools to verify that an API call is being made correctly?
Strong answer: Open DevTools, go to the Network tab, perform the action that triggers the API call, and find the request in the network log. I check: the request URL (correct endpoint?), the request method (GET/POST/PUT/DELETE as expected?), the request headers (Content-Type, authorisation headers), the request body (correct payload?), the response status code (200, 201, or 4xx/5xx?), and the response body (correct data structure?). If I expect an API call and none appears, the client-side code has not triggered it.
Q2. What can the Console tab in DevTools tell you about the health of a page?
Strong answer: The Console shows JavaScript errors (red), warnings (yellow), network errors, and application log messages. A page with JavaScript errors may have broken functionality that does not visually appear broken. Console errors with stack traces help developers fix bugs faster. I always open the Console when testing a new feature — silent JavaScript failures are common, and only the Console reveals them. I also check for accidentally exposed sensitive data in console.log statements.
Q3. You notice a page is slow. How would you use DevTools to identify the cause?
Strong answer: I use the Network tab to check which resource is taking longest — images, JavaScript bundles, API calls, or web fonts. Large uncompressed images are a common cause. The Performance tab provides a timeline of rendering, scripting, and painting. The Lighthouse audit (in the Lighthouse tab) gives a structured performance report with specific recommendations. For API slowness, I note the response time in the Network tab and report it with the specific endpoint, response time, and whether it occurs consistently or intermittently.
Q1. A form looks fine but nothing happens when you click Submit. Which DevTools tab helps most?
The Console and Network tabs. Console shows JavaScript errors. Network shows whether the form's API request was sent and what response came back.
Q2. Why shouldn't you rely only on Lighthouse for accessibility?
Lighthouse is automated and catches only ~30% of issues. It can't judge whether alt text is meaningful, whether tab order is logical, or whether colour choices are usable. Manual testing is essential.
Q3. What's the fastest way to check if a page works on mobile?
DevTools Device Toolbar. Press Ctrl+Shift+M (or click the phone icon). Select "iPhone SE" or "Pixel 5" and reload. It takes 5 seconds.