What Makes a Good Closed Test Report
A report that lists crashes is useful. A report that orders them by severity, names the device, and shows the steps to reproduce is evidence. Here is the difference.
A testing report is only useful if it tells you what to fix and in what order. A list of 50 observations with no severity order is a list, not a report. A list of three findings — crash on payment screen, layout break on small screens, onboarding confusion on first launch — is actionable.
Severity ordering matters because the reviewer has limited time. Google’s production access reviewers look at the testing record and ask whether the app was exercised by real people. A report that leads with crashes and data loss, then broken core flows, then layout and polish, reads like a professional assessment.
Device information matters because Android is fragmented. A crash on Android 14 with a Samsung skin is a different bug from the same crash on a Pixel with stock Android. Naming the device, the OS version, and the app version turns a vague report into something a developer can reproduce.
Screenshots matter because they are evidence. A written description of a layout break is useful to the team. A screenshot of the broken layout on a real device is useful to a reviewer who has never seen the app before. Daily screenshots on Premium and Enterprise plans exist for exactly this reason.
If this matches your situation
12Tests assigns 12 real Android testers within hours, runs the full 14-day window, and delivers a written report you can paste into Google's production access questionnaire. One-time payment per app, no subscription.