Lesson 1 of 85 min read
Why DevTools is a tester's best friend
Every Chrome browser ships with a free debugging toolkit. Testers who use it find the real cause of a bug, not just the symptom, and write bug reports developers can fix in minutes.
Key takeaways
- 1Open it with F12, Ctrl+Shift+I (Cmd+Option+I on Mac), or right-click any element and choose Inspect.
- 2The panels testers use most: Elements (page structure and styles), Console (errors and quick scripts), Network (every request the page makes), Application (cookies, local storage) and Lighthouse (speed and accessibility).
- 3DevTools tells you which side a bug is on: a 500 in Network means the server failed; a red error in Console with a 200 response means the front end broke.
- 4Dock it to the right or bottom with the three-dot menu; use Ctrl+Shift+P to open the command menu and search any feature by name.
Turn a vague bug into a precise one
Vague: "Save button doesn't work." With DevTools: 1. Open Network, click Save. 2. See POST /api/profile -> 422 Unprocessable Entity 3. Response: {"error": "phone must be 10 digits"} 4. UI shows no message at all. Bug title: "Profile save fails silently: API returns 422 for phone validation but no error is shown to the user"
Go deeper
Expert notes beyond the basics
- 01
The Issues panel finds problems for you
Chrome's Issues tab (next to Console) groups framework-detected problems that don't always throw a red Console error: third-party cookie warnings, CORS misconfigurations, mixed content, deprecated APIs and CSP violations. Each issue links to affected requests and an explanation of the fix. Testers who only watch Console miss these, because many show as blue info entries rather than errors. Checking Issues once per exploratory session is a fast way to catch problems that will matter once browsers tighten their defaults, such as third-party cookies being blocked.
- 02
The command menu is faster than menus
Press Ctrl+Shift+P (Cmd+Shift+P on Mac) inside DevTools to open the command menu, a searchable list of every DevTools feature. Instead of hunting through tabs, type 'screenshot', 'coverage', 'disable cache' or 'rendering' and press Enter. This is especially useful for features tucked away in sub-menus, like Capture full size screenshot or Show rendering options. Learning this one shortcut speeds up almost every lesson in this course.
- 03
Multiple DevTools windows and undocking
You can undock DevTools into its own window (three-dot menu > Dock side > undock icon), which is useful on a second monitor so the inspected page keeps its real width while you read Network or Console on another screen. You can also open DevTools for a background tab via chrome://inspect, useful when debugging an iframe or a popup window that steals focus from the main page.
- 04
DevTools settings worth changing on day one
Open Settings (gear icon or F1): enable 'Auto-open DevTools for popups', turn on 'Group similar messages in console' to cut noise, and under Experiments avoid enabling unstable features during real test sessions. Under Preferences, 'Disable cache (while DevTools is open)' is worth leaving on permanently if you test often, so you never mistake a cached response for a fresh bug fix.
Common mistakes to avoid
- - Only glancing at Console and never opening the Issues panel, missing CORS and cookie warnings.
- - Testing with DevTools closed, then reopening it after a bug happens and losing the network history.
- - Not realising a hard refresh (Ctrl+Shift+R) differs from a normal refresh when cache is suspected.
- - Reporting 'DevTools showed an error' without naming the panel, message or status code.
Try it yourself
Open any news or shopping website. Open DevTools, go to the Issues panel, and list every issue shown. For each, note its category (e.g. Cookie, CORS, Deprecation) and one sentence on what it means for the user.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
How do you use browser developer tools in your testing?
Model answer
I keep DevTools open while testing. I check the Console for JavaScript errors, the Network tab to see request payloads, status codes and response times, and Application for cookies and storage. That lets me tell whether a bug is front end or back end and attach the exact failing request to the bug report.
- Q2
What is the Issues panel used for?
Model answer
It groups browser-detected problems such as CORS failures, cookie and privacy warnings, deprecated APIs and mixed content, with links to the affected requests. It catches things that don't always appear as red Console errors, so I check it during exploratory sessions, not just Console.
- Q3
What is the difference between a normal refresh and a hard refresh?
Model answer
A normal refresh (Ctrl+R) may reuse cached files. A hard refresh (Ctrl+Shift+R) forces the browser to re-download everything, bypassing the cache, which is important when checking whether a deployed fix actually reached the browser.
- Q4
How do you decide if a bug is a browser quirk or a real product bug?
Model answer
I reproduce it in at least one other browser and check DevTools for the underlying cause, such as a deprecated API warning or a CSS feature with limited support. If it only fails in one engine, I note that in the bug report instead of assuming it's a general product bug.
Knowledge check
+5 points
You click Submit, nothing happens, and Network shows the request returned 500. Where is the bug most likely?