You completed your 14-day closed test. 12+ testers opted in, you pushed an update, everything looks good. Then you apply for production access — and Google asks you a questionnaire.
This step trips up more developers than the tester count ever does. Here's what it's actually checking, and how to answer it properly.
Why this questionnaire exists
Google isn't just counting testers. It's trying to confirm that a real testing cycle happened — that people used your app, gave you feedback, and you responded to it. The questionnaire is how Google checks that story holds together.
If your answers are generic, Google reads that as: no real testing happened, just a box-ticking exercise to hit the tester minimum. That's the single most common reason developers get rejected even with a technically compliant test.
The questions, and what they're really checking
Google's exact wording changes over time, but it consistently asks around these points:
"What feedback did you receive from testers?" A vague answer — "testers said the app was good" — signals nothing happened. A strong answer names specific things: "Testers reported the app crashed when rotating the screen on the profile page (2 reports, Pixel 7 and Pixel 8, Android 14). One tester suggested adding a skip button during onboarding."
"What changes did you make based on that feedback?" This is where many developers fail — they collected feedback but never touched the app during the 14 days. Google expects at least one visible change or fix pushed during the test window, not just a plan to fix things later.
"How did testers access the app?" Answer factually: email list or Google Group, and how many testers were opted in. This is a sanity check against your actual Play Console data — don't round up.
"Is the app ready for production?" Be honest here. If there are still known critical bugs, saying "yes, fully ready" while your own bug list says otherwise is inconsistent — and inconsistency is what trips detection, not the presence of bugs themselves. It's fine to say you fixed the critical issues and are tracking a couple of minor ones for a follow-up release.
The pattern behind rejections
Across rejected applications, three patterns show up repeatedly:
- Generic answers — "everything went well," "no issues found." Even a genuinely smooth test needs a specific example, not a summary sentence.
- No evidence of iteration — the app's last update was before testing even started.
- Mismatched numbers — claiming 16 active testers when Play Console shows several who never opened the app after day 2.
A practical way to prepare
Keep a running log during the 14 days instead of trying to remember everything on day 15:
- One line per bug found, with device and Android version
- One line per suggestion, even minor ones
- The date you pushed an update in response
When you sit down to answer the questionnaire, you're pulling from a real log, not reconstructing memory — which is exactly why the answers read as specific and believable, because they are.
If you're coordinating testers instead of managing this yourself
This is exactly the gap ClosedTest fills — real testers, daily engagement logged throughout the 14 days, and a written feedback report you can pull directly from when answering the questionnaire. See current plans →