Chrome DevTools for testers: how to collect evidence for a bug report
Chrome DevTools is the set of tools built into Google Chrome that shows what a web page does behind the screen. A tester uses it mainly to collect evidence for a bug report: the error in the Console, the request the page sent and the server's response in the Network panel, and the values the site keeps in the browser in the Application panel. Open DevTools with F12 (Cmd+Option+I on a Mac) before you reproduce the bug, because the Network panel records only while DevTools is open.
- 4 kinds of evidence
- message, request, response, storage
- No code needed
- you read what the page did
- Built into Chrome
- nothing to install
How to collect evidence for a bug report, step by step
- Step 1
Open DevTools before you reproduce
Press F12 or Ctrl+Shift+I on Windows and Linux, Cmd+Option+I on a Mac, or right-click the page and select "Inspect". The Network panel records only while DevTools is open, so open it first.
- Step 2
Prepare the Network panel
Tick "Keep log" so the list survives a reload or a move to another page, and clear the list so it starts empty. Tick "Disable cache" when the bug may come from an old copy of a file.
- Step 3
Reproduce the bug once
Follow your steps exactly, with the same data. One clean run gives a short list of requests and messages that all belong to the bug.
- Step 4
Read the Console
Look for red lines: errors and failed requests, with the file and line on the right. Copy the text of each line that appeared during your steps.
- Step 5
Find the request and read the response
In Network, select "Fetch/XHR" to see only the page's data requests. Find the one your action sent, note its Status, then open it and read Headers, Payload and Response.
- Step 6
Check what the site stores
In Application, open Local storage and Cookies for the site's address and note any value that can change the result, such as the selected currency.
- Step 7
Attach it without leaking secrets
Paste text rather than screenshots where you can, crop the screenshots you keep, and remove sign-in tokens before anything leaves your computer.
The panels a tester uses
DevTools opens as a set of tabs along the top: Elements, Console, Sources, Network, Performance, Memory, Application, Security, Lighthouse and Recorder. Developers use all of them. For bug evidence, a tester needs four, and most days only the first two.
None of this needs programming. You read what the page did, copy it, and put it into the report next to your steps. The developer gets the facts, not your guess about the cause.
Console
Messages from the page's scripts and from the browser: errors, warnings, failed requests.
Network
Every request the page sent, its status, what it carried and what the server answered.
Application
What the site keeps in the browser: Local storage, Session storage, Cookies.
Elements
The page's HTML and styles. Useful to name an element exactly or to check a layout rule.
Reading the Console
The Console shows what went wrong inside the page. The drop-down at the top reads "Default levels": by default it shows Info, Warnings and Errors and hides Verbose. Errors are red, and each line has a link on the right to the script file and line that produced it. The "Filter" box narrows the list to lines that contain a word.
The browser also writes failed requests to the Console. Open a product that does not exist in Shelf, the practice shop the courses use, at https://<your Shelf address>/product/99999, and the Console shows a red line like GET https://<your Shelf address>/api/products/99999 404 (Not Found). The page says "This product is not on the shelf" and "There is no product with id 99999."
That red line is not a bug. There is no such product, and 404 is the right answer. A red line is a clue, and the expected result decides whether it is a defect. An error that appears during your steps on a screen that looks fine is worth a report of its own, with the text copied in.
By default the Console starts empty after a reload. If the bug happens right after a page change, open "Console settings" (the gear at the top right of the Console) and tick "Keep log". Older tutorials call this checkbox "Preserve log"; current Chrome labels it "Keep log", in the Console settings and in the Network toolbar.
The request and the response in Network
The Network panel lists every request the page sent while DevTools was open, with the columns Name, Status, Type, Initiator, Size and Time. A web page loads its HTML, styles, scripts and pictures, and then asks the server for data. The data requests are the ones that matter for most bugs, and the "Fetch/XHR" filter shows only them.
Select a request to open its details. Headers shows a "General" block with Request URL, Request Method and Status Code, then the response headers. Payload shows what the page sent; for a JSON body the block is called "Request Payload". Response shows what the server sent back, and Preview shows the same answer laid out for reading.
In Shelf, entering SPRING5 in "Coupon code" in the cart and selecting "Apply" sends one request. Here is what each tab shows. SPRING5 is not a Shelf coupon, so the refusal is the expected behavior.
Headers > General:
Request URL: https://<your Shelf address>/api/cart/coupon
Request Method: POST
Status Code: 422 Unprocessable Entity
Headers > Response headers: x-trace-id: <an id for this request>
Payload > Request Payload: {"code":"SPRING5"}
Response: {"error":{"code":"coupon_unknown",
"message":"There is no coupon SPRING5. Check the code and try again.",
"details":[{"field":"code"}]},"trace_id":"..."}Server or page: what the evidence tells the developer
The Network panel also tells you which side of the product is at fault. A web shop has two halves: the page in your browser and the server behind it. Read the request and you can usually say which half went wrong, and the right developer starts in the right place.
The defect below is invented for this guide; the labels and the server's answer are the shop's real ones. The server answered correctly, with the message the page should have shown, so the fault is in the page. Without the Network lines, the report would only say that nothing happened.
Title: Cart: no message under "Coupon code" for a code that does not exist Environment: Shelf web 1.4.2, Chrome on Windows 11, desktop Preconditions: Signed in. The cart holds 1 x Steel kettle 1.7 l. Steps to reproduce: 1. Open Cart. 2. In "Coupon code", enter SPRING5. 3. Select "Apply". Expected result: Under the field: "There is no coupon SPRING5. Check the code and try again." Actual result: Nothing appears under the field. Reproduced 3 of 3 times. Evidence: Network: POST /api/cart/coupon, Status 422 Unprocessable Entity Response: "message":"There is no coupon SPRING5. Check the code and try again." x-trace-id: <copied from Response headers> Console: no errors at Default levels Severity: Medium (the customer is not told why the coupon was refused)
No request at all
The page never asked the server. Look at the Console: a script error often stops the page before it sends anything.
A 4xx status
The server refused the request. Compare the Payload with what you typed: the page may have sent something else.
A 5xx status
The server failed. Shelf answers "Something went wrong on the server. Quote the trace id when you report it." Quote it.
Right answer, wrong screen
The Response holds the correct data or message, but the page shows something else. The fault is in the page.
What the site keeps in the browser
Some bugs depend on what the browser remembers. The Application panel shows it: under Storage, open "Local storage" and then the site's address to see a table of Key and Value. "Session storage" works the same way but is cleared when the tab's session ends. Cookies have their own table with Name, Value, Domain, Path, Expires / Max-Age and more.
Shelf keeps four keys in Local storage: shelf-token (the sign-in token), shelf-user (the signed-in user), shelf-currency and shelf-theme. With shelf-currency set to EUR, the Steel kettle 1.7 l that costs USD 24.00 shows as EUR 22.08, and the order itself stays in USD. A tester who reports a "wrong price" without noting the currency sends the developer the wrong way, so put such values in the environment line.
To repeat a bug from a clean state, use the "Clear site data" section under Storage: tick what to clear and select "Clear selected". It affects this site only. Clearing Local storage also signs you out of Shelf, because the token lives there.
Attaching the evidence without leaking secrets
Text beats a picture of text: a developer can search it and paste it. Right-click a request and open the Copy menu for "Copy response", "Copy request headers", "Copy response headers" and "Copy as cURL", which copies the request as a command that a developer can run again.
"Copy as cURL" includes the request headers, and for a signed-in user that means the line Authorization: Bearer followed by the token. Anyone with that token acts as you until it expires. Replace it with <token> before you paste. Treat the shelf-token value in Local storage the same way.
When a developer asks for the whole session, use "Export HAR (sanitized)..." in the Network toolbar. The sanitized file leaves out the Cookie, Set-Cookie and Authorization headers. For screenshots, crop to the request and the tab that shows the problem.
Changes you make in the Elements panel are not saved: they are gone after a reload, and a customer never sees them. Editing the page there helps you explore, but it is never a step to reproduce.
Where to learn this
13 lessonsQuestions and answers
Do I need to know JavaScript to use DevTools as a tester?
No. For bug evidence you read the Console's messages, the request's status, what was sent and what came back. That needs HTTP basics and the ability to read JSON, not programming.
Where is "Preserve log" in Chrome DevTools?
Current Chrome labels it "Keep log". In the Network panel it is a checkbox in the toolbar next to "Disable cache"; for the Console it is in "Console settings", the gear at the top right.
Is every red line in the Console a bug?
No. A 404 for a product that does not exist is the right answer, and the browser logs it in red. Compare with the expected result first. A red error during normal steps on a screen that looks fine is worth reporting.
Why is the Network panel empty?
It records only while DevTools is open. Open DevTools first, then reload the page or repeat the action. If the list empties when the page changes, tick "Keep log".
Can I test a mobile layout in DevTools?
Partly. "Toggle device toolbar" (Ctrl+Shift+M, Cmd+Shift+M on a Mac) draws the page at a phone's width. It is still a desktop browser: touch, the on-screen keyboard and the phone's network need a real device.
Is it safe to attach a HAR file to a bug report?
Use the sanitized export, which leaves out cookies and the Authorization header. A full HAR can contain sign-in tokens and anything you typed, so keep it out of shared trackers.
More guides
- Start hereHow to become a software testerWhat a software tester does, what to learn and in what order, and how to practice without a job: six steps from zero to a small portfolio.
- Bug reportsHow to write a bug reportThe fields of a bug report, a template to copy, a complete example from a practice shop, severity and priority with examples, and the mistakes that send a report back to you.
- Test casesHow to write test casesThe parts of a test case, a template, a complete example and its negative cases, the difference between a test case, a test scenario and a checklist, and how to fix a weak case.
- Test designBoundary value analysis and equivalence partitioning, with examplesHow to split inputs into equivalence partitions, pick boundary values with the 2-value and 3-value methods, and choose the step, worked through four fields of a practice shop.
- Bug reportsSeverity vs priority, with examplesWhat severity and priority mean, who sets each, the scales teams use, and all four combinations worked through on one practice shop, with a short answer for interviews.
- Test documentationTest case vs test scenario vs checklistWhat a test scenario, a checklist and a test case are, one shop feature written all three ways, when to use which, and how a scenario turns into checklists and test cases.
- Test designHow to test a login pageTest cases for a login page derived from partitions, a decision table, boundaries and states, plus the security checks every login page needs, worked through on a practice shop.
- API testingAPI testing with Postman: a beginner's guideHow to send your first requests in Postman, read the response, keep addresses and tokens in variables, test 401 and 403, add a status check and run a collection, on a practice shop's API.
- API testingHow to test a REST API manually: a checklistA manual REST API testing checklist without code: reading the OpenAPI documentation, status codes, body, headers, 401 versus 403, negative cases and state, with example requests to a practice shop.
- DatabasesSQL for testers: check what the app savedHow testers use SQL: the queries that check what an online shop saved after an order (order row, items, payments), SELECT, WHERE, GROUP BY and JOIN on a real schema, and the mistakes to avoid.
- Test processSmoke vs sanity vs regression testingWhat smoke, sanity, regression testing and retesting usually mean, why teams use the names differently, how to ask on a new team, and how to choose the checks for a new build.
- Mobile testingHow to test a mobile appWhat breaks only on a phone, how to choose between an emulator, a simulator and a real device, how to read the app's log and its traffic through a proxy, and a checklist to start from.
See the first course
The full outline of every course is available: you can see each lesson before you start.