When you buy testing, the report is the product. Everything else — the testers, the devices, the process — exists to produce it.
So it is worth being concrete about what one actually contains, because "you get a bug report" covers everything from a structured document to somebody's list of complaints in a chat thread.
The unit: one verified issue
The core of the report is a set of issues. Each one carries:
A title that describes the failure. Not "checkout broken" but "Checkout: Pay button stays disabled after entering a valid card". You should be able to triage from the list without opening anything.
A severity. Assigned consistently across the whole run, not by whichever tester felt most strongly. Critical means the core flow is blocked. Cosmetic means it looks wrong but works.
Numbered reproduction steps, starting from a state you can actually reach — a fresh install, a logged-out app — rather than "from the settings screen."
Expected versus actual, stated separately. This sounds pedantic until you meet the case where a developer believes the current behaviour is correct. Writing the expectation down surfaces that disagreement immediately instead of after three rounds of comments.
Device and environment. Model, OS version, platform, and the app build. "Works on my machine" is usually true and usually irrelevant — you need to know where it failed.
Frequency. Every time, or one attempt in five, or seen once and not since. A developer who tries once, cannot reproduce, and closes the ticket has been misled by a report that implied determinism.
Evidence. Screenshots on every issue. Screen recordings on critical bugs, because some failures — a flicker, a stuck animation, a race condition — are close to impossible to describe in text.
We wrote separately about why this structure is what makes a bug report survive contact with the person who has to fix it. The report format is that structure, enforced.
Coverage, not just findings
A list of bugs tells you what was found. It does not tell you what was looked at — and those are very different questions.
If a report says nothing about your payment flow, there are two possible explanations: the payment flow is solid, or nobody tried it. Without coverage data you cannot tell which, and the difference matters enormously.
So the report includes task completion status per tester: which assignments each person worked through and completed. You can see that eleven testers ran the signup flow and nine completed checkout, rather than inferring it from an absence of bugs.
What gets removed before you see it
This is the part that is easy to overlook and is most of the actual work.
Duplicates get merged. When twelve people test the same build, several will hit the same bug. Twelve tickets for one defect is noise. They arrive as one issue, with the device and OS spread noted — which is itself useful, because "seen on three different Android manufacturers" tells you something "seen once" does not.
Incomplete reports get sent back. A submission without steps, or without device context, is not usable. Those go back to the tester rather than forward to you.
Non-bugs get filtered. Testers sometimes report intended behaviour they did not understand, or an issue you already flagged as known in your brief. Those get resolved before they reach your list.
Severity gets normalised. Left to individuals, severity is a mood. Applied consistently across a run, it is a triage tool.
The net effect: what lands in your dashboard is closer to a triaged backlog than a feedback dump. That is the difference between testing that saves your team time and testing that adds a filtering job to their week.
The formats you get it in
In your dashboard, browsable and filterable, with screenshots and recordings attached inline.
As a PDF export, one click, for the cases where the dashboard is not the right venue — sending findings to a client, attaching to a release checklist, sharing with a stakeholder who does not have an account, or keeping a record of what was verified before a release.
What a good report changes
The practical test of a report is whether a developer can act on it without a conversation. If every issue requires a follow-up — which device? what were you doing? can you screenshot it? — the report has moved work rather than removed it.
That is the bar. Open an issue, reproduce it, fix it.
See one for yourself
The fastest way to judge report quality is to get one for your own app.
- [Start a test run →](/client/tests/new) — submit a build and see what comes back
- [See pricing](/pricing) — subscriptions or one-off credit packs
- [Create an account](/auth/signup) — look around the dashboard first