What a 99tests report looks like, section by section
A walk through a real-format 99tests report: the summary, the case-by-device coverage table, verified findings with recordings, the verification record and the not-run list.
In this article
- 1. The summary: read this first
- 2. The coverage table: every case on every device
- 3. Findings: what broke, where, and how to see it
- 4. The verification record: what was accepted, merged and rejected
- 5. Devices and sessions: who tested what, when, on which network
- 6. Not run: nothing quietly passed
- 7. Re-run after the fix
- What to look for in any test report
- See it yourself
Before you pay for any testing service, look at what you get back. A report decides whether your developers can fix things the same day or spend the morning asking "which phone was this on?"
This post walks through the 99tests sample report section by section. It is the exact format every job delivers, for a made-up shop app called ShopEasy: a Standard job on build 4.12.0 checkout, delivered on 17 September 2026.
1. The summary: read this first
The top of the report is five numbers and one paragraph.
| Cases run | 47 |
| Pass on all devices | 39 |
| Fail on at least one device | 6 |
| Blocked | 1 |
| Not run | 11 |
Under the numbers sits a plain-language verdict, written for whoever decides whether the release goes out:
Two S1 findings, cart loss on UPI app switch (Galaxy A15) and a blocked address editor on Safari (macOS), block release on those targets. Everything else is S2 or below.
A product manager can stop reading here and make the call. Everyone else keeps going.
2. The coverage table: every case on every device
The coverage table is a grid: test cases down the side, devices across the top. In the sample the devices are a Redmi 12 (Android 13), a Galaxy A15 (Android 14), Chrome 128 on Windows 11 and Safari 17 on macOS 15. Each cell is pass, fail, blocked or not run, and every fail links to its finding.
A few rows from the sample:
| Test case | Redmi 12 | Galaxy A15 | Chrome, Windows | Safari, macOS |
|---|---|---|---|---|
| TC-001 Login with OTP (P1) | Pass | Pass | Pass | Pass |
| TC-004 Add to cart, offline (P2) | Fail | Pass | Fail | Pass |
| TC-009 UPI payment, app switch (P1) | Pass | Fail | Pass | Blocked |
| TC-015 Change address mid-checkout (P1) | Pass | Pass | Pass | Fail |
| TC-021 Saved card payment (P1) | Pass | Pass | Fail | Pass |
This is the part automation reports don't give you. TC-009 passed on the Redmi 12 and failed on the Galaxy A15, so the bug is in how the app handles one phone's behaviour, not in the payment flow itself. That one row tells a developer where to start.
3. Findings: what broke, where, and how to see it
Each finding is written so a developer can reproduce it without asking anyone. Here is the first S1 from the sample:
S1 · TC-009 · Galaxy A15: cart empties when returning from the UPI app
- Device: Samsung Galaxy A15, One UI 6, Android 14, Jio 4G
- Steps: add 2 items and go to checkout; choose UPI and let the UPI app open; press back before completing the payment
- Expected: cart intact, payment marked pending
- Actual: cart shows 0 items; order not created; no error shown. Reproduced 3 of 3 attempts.
- Evidence: a 41-second screen recording and two screenshots
- Verified: complete, unique, severity confirmed (confidence 0.94)
Every finding carries the same fields: device, OS build, network, steps, expected, actual, how often it reproduced, the recording, and the session it came from. Laptop findings add the browser version and viewport. The sample's Chrome bug, for instance, only happens at 1366 px wide and works at 1440 px and above.
Severity runs from S1, which blocks the release, down to S4; in the sample, S4 is dark-grey text on a dark receipt card. In the sample, one finding was moved from S2 to S3 during verification because a workaround exists, and the report says so.
4. The verification record: what was accepted, merged and rejected
Testers find things; a separate reviewer decides what reaches you. The sample's verification record reads:
| Accepted | 7 |
| Merged as duplicates | 2 |
| Rejected (incomplete) | 1 |
Each finding was checked for complete reproduction steps and media, compared against the other findings on the job, and graded against the published severity rubric. One report that said only "payment slow" was rejected for lacking steps.
That's the difference between a crowd and a report. Without this step you get every tester's notes, duplicates included, and your team does the sorting.
5. Devices and sessions: who tested what, when, on which network
The session log lists all ten sessions: the device, the OS and browser, the network, the cases covered, when it started and how many findings it produced. In the sample, the Redmi 12 sessions ran on Jio 4G and Airtel 4G, the Galaxy A15 on Vi 4G, Jio 4G and Jio 5G, and the laptops on home broadband and fibre.
If a bug shows up only on one network, you can see it here.
6. Not run: nothing quietly passed
The last section lists what wasn't tested and why. In the sample, 11 cases (TC-048 to TC-058, wishlist and profile edits, all P3) were outside the package. One case on Chrome wasn't run because the tester's session ran out of time.
A report that leaves this out lets you assume coverage you didn't get. Here the fix is stated plainly: add five sessions to cover the rest on the same build.
7. Re-run after the fix
At the bottom is one button: re-run the same cases on the same devices against the new build. The two S1 bugs get checked on the Galaxy A15 and the Mac they failed on, not on whichever phones happen to be free.
The report comes as a hosted page and a PDF, so you can attach it to a Jira ticket or forward it to a client.
What to look for in any test report
Whether you buy from us or someone else, ask for a sample and check that it has:
- A verdict a non-engineer can act on
- Every case against every device, not just a bug list
- Device, OS build and network on every finding
- A recording for anything serious
- A record of what was merged and rejected
- A list of what was not run
See it yourself
Open the full sample report, with all 47 cases and 7 findings. When you're ready for one on your own app, pick a package: Starter is ₹9,999 + GST for up to ~25 cases on 2 devices, with this report in 3 business days.
