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.
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.
8 Self-Check
Click each question to reveal the answer.
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.