What a useful tester report looks like
A real report, annotated — plus the three prompts that turn “looks nice” into something you can act on before your users find it.
Most tester feedback is worthless, and it is usually the developer’s fault. “Looks nice, works well” is what you get when you ask someone what they thought. You get something you can act on when you ask four specific questions instead.
The four questions
1. First impression
What did you think this was for, and how long did it take to work out? This is the only question whose answer expires — a tester can never see your app for the first time twice, and by day three they have learned their way around the thing that confused them on day one. Ask it immediately or lose it.
2. What broke
Not “did anything break”, which invites a no. Name the screen, the action, and what happened instead. A useful answer reads like:
Export to Markdown silently does nothing when the note has an attachment. No error, no file, no toast.
Three facts in one sentence: the feature, the condition, and the absence of any feedback to the user. That last part is the actual bug — the export failing is a defect, the export failing silently is a design decision nobody made.
3. Reproduction steps
The difference between a report you can fix this afternoon and a report you file under “cannot reproduce”. Numbered, literal, and ideally confirmed on a second device:
- New note, type anything
- Attach any image
- Menu → Export → Markdown
- Nothing happens. Repeats on a second device.
Any report claiming a significant issue without these is not actionable, and it is reasonable to require them.
4. One change they would make
Exactly one. Asking for a list gets you a wishlist; asking for one forces a priority judgement, and the thing someone picks when limited to one is usually the thing that actually bothered them.
Move the attachment button out of the overflow menu. I found it by accident on day four and I was looking for it on day one.
Two things that make the answers honest
Device and OS version, always. “Crashes on rotate” is a mystery. “Crashes on rotate, Redmi Note 12, Android 13” is a ticket. Most indie developers own two or three devices and ship to thousands of configurations; the device string is often the most valuable field in the report.
Severity, classified by the tester. Minor, significant, blocker. This is not a rating of your app — it is a triage label on one defect, and it is what lets you read fourteen reports in ten minutes instead of an hour.
The incentive problem, which is the real one
None of this survives if the person writing it has a reason to be nice. If the developer decides whether a report gets paid, every tester learns very quickly that praise pays and criticism does not, and within a few cycles you have built a machine that produces compliments. The reports get shorter, warmer and completely useless, and you will not notice because they will all be positive.
Two rules prevent it. A critical report has to pay exactly what a glowing one pays — if a blocker costs the developer more, developers learn to dispute blockers. And a developer must not be able to unilaterally refuse payment for feedback they disliked; disputing a report should open an arbitration a third party decides, not reject it.
Those two rules are the difference between a feedback system and a flattery system, and they are worth checking for in any service you use.
See a real one
There is a full redacted report on the front page, rendered exactly as a developer receives it — the four answers, the device, the severity tag and the arbitration rule stated plainly. Read it here, or see which apps are open to testers right now.