Closed Testing Report
What's actually in a Google Play closed testing report
Google's production access questionnaire asks what feedback you collected during closed testing and what you changed because of it. Most developers finish their 14 days with nothing to answer that with. This page breaks down a real 21-page QA report from a completed cycle — the exact sections, the device coverage, how each finding is written, and the questionnaire answers it feeds. The client name and app have been removed; everything else is as delivered.
1. Device coverage — the table that proves the test was real
This is the first thing to check in any report you're handed. It shows which Android versions and RAM tiers the app actually ran on. Coverage from a single modern flagship tells you nothing about how your app behaves on the 4 GB devices most of your users own. The cycle below used 25 real devices:
| Android version | RAM group | Devices | Count |
|---|---|---|---|
| Android 17 | 12 GB | Pixel 7 Pro, Pixel 6 Pro, Pixel 8 Pro | 3 |
| Android 16 | 8 GB | Pixel 7 ×4 | 4 |
| Android 15 | 8 GB | Infinix HOT 60 Pro+ ×2, Xiaomi 13 Pro, Tecno Spark 40 Pro+, Infinix HOT 15 Pro+ | 5 |
| Android 14 | 8 GB | OnePlus 9R, Tecno Camon 20 Pro, Infinix NOTE 30 | 3 |
| Android 11 | 4 GB | Vivo Y15, realme 6i, OPPO A16 ×2, Galaxy A03s, Infinix HOT 16 Play, Tecno Pova Neo, Infinix HOT 11 Play | 8 |
| Android 10 | 6 GB | Infinix Note 8i, Infinix Note | 2 |
| Total | 25 |
Note the shape of it: the largest single group is Android 11 on 4 GB devices, not the flagships. That is deliberate. Low-RAM devices on older Android versions are where layout, memory and inset bugs actually surface.
2. The severity scale
Findings are worthless if you can't tell which ones to fix before submitting. Every finding in the report carries one of five severities:
| Severity | Priority signal | Meaning |
|---|---|---|
| Critical | Fix immediately | Blocks app use, causes a crash or data loss, or prevents a core journey from continuing. |
| High | Fix soon | Major feature problem affecting normal use. The app may still open, but the experience is seriously impacted. |
| Medium | Plan fix | Noticeable issue in a non-blocking flow, layout, validation or feature behaviour, with a possible workaround. |
| Low | Improve later | Minor visual, text, spacing or usability issue that doesn't stop the main functionality. |
| Suggestion | Optional | Optional improvement for a cleaner experience or a future update. |
3. How a single finding is written
This is where most cheap "testing" services fall apart. A finding you can't reproduce is a finding you can't fix. Every entry in the report has the same seven parts. Here is a real one from the cycle, unedited apart from the app name:
- Finding
- Bottom navigation labels are obscured by the device navigation bar
- Severity
- Medium
- Test device / OS
- Google Pixel 6 Pro · Android 17
- Steps to reproduce
- 1. Launch the application. 2. Open the bottom navigation bar. 3. Observe the icon labels. 4. Compare their position with the device navigation bar.
- Expected vs. actual
- Expected: labels fully visible and positioned above the device navigation bar with no overlap. Actual: labels are partially hidden behind the device navigation bar.
- Policy relevance / quality concern
- The application does not account for the device's system window insets, causing the bottom navigation labels to overlap system UI. This reduces readability and hurts navigation usability.
- Recommendations
- Apply proper system window inset handling; add bottom padding or margin to prevent overlap; re-test across screen sizes and both gesture and 3-button navigation modes.
- Evidence
- Screenshot attached in the delivered report.
The "policy relevance" line matters more than it looks. When you later answer Google's question about what you learned during testing, you want findings that connect to quality and compliance, not a list of typos.
4. The three test-case sheets
Individual findings only tell you what broke. The sheets tell you what was checked — including everything that passed. Each row carries a test ID, area, scenario, steps, expected result and a pass / partial / fail verdict.
Sheet 1 — End-to-end app QA
Installation from the official testing link, app-name consistency across the listing, launcher and in-app title, logo consistency, first-launch time (expected: 3–5 seconds without a crash), sign-in with valid credentials, sign-in with invalid credentials, and the rest of the core journey.
Sheet 2 — Play Store listing QA
App-name clarity and consistency, icon quality and sizing on both store and launcher, screenshot sharpness and readability, and whether the screenshots actually represent the core features. This sheet exists because production review looks at your listing, not only your APK.
Sheet 3 — Functional and usability validation
Core functionality, navigation accuracy, performance, interface clarity, device compatibility, accessibility of text and controls, and stability under repeated use. In this cycle the functional-behaviour row came back Partial with the remark "some features are not working as intended" — which is exactly the kind of honest result that gives you something to fix and something to report.
5. The production questionnaire section
This is the part developers underestimate. After 14 days, Google asks you a written questionnaire before granting production access. The report drafts answers for each question, based on what actually happened during your cycle. The questions Google asks:
About your closed test
How did you recruit testers (friends and family, or a paid testing provider)? How easy was it to recruit them? And a summary of the feedback received, including how you collected it.
About your app
Who is the intended audience? How does the app provide value to users? How many installs do you expect?
Your production readiness
What changes did you make to your app based on what you learned during the closed test? And how did you decide the app is ready for production?
Read that middle question again: what changes did you make based on what you learned. If your 14 days produced no findings, you have nothing to write. That is the single strongest argument for running the window as a real test rather than a countdown.
6. One operational detail that costs people days
This is the most common panic message we get. Developers assume the cycle failed and start re-enrolling testers, which is unnecessary and occasionally makes things worse.
See the full report
The complete 21-page premium report is published as delivered: open the sample report (PDF). It includes the full findings list with screenshots, all three completed test sheets, and the drafted questionnaire answers.
Related reading: Google Play's 12 testers requirement, explained and the production questionnaire, question by question. Building with no-code tools? See our Base44 and Lovable publishing guides.
Want a report like this for your app?
Real testers for 14 days, and a report you can actually submit with.
Plans from $180, fully remote, worldwide. The Premium plan includes the full QA report and questionnaire answers written from your cycle's real findings.
Start your testing cycle