Requirements
How to answer the production access questionnaire (examples for each question)
When you apply for production access after your closed test, you have to answer questions about your testing. A person reads and evaluates your answers, so weak answers get rejected. We go through Google's three-part questionnaire one question at a time, with weak and strong answers side by side so you know what to write.
Last checked Sep 20, 2026.
1. What the questionnaire looks for
Once you complete 14 days of closed testing, you can apply for production access in Play Console. As part of that, you answer questions about your closed test, and a person at Google reads and reviews your answers. Reviews usually finish within 7 days.
It comes down to one thing: whether you actually tested, not just checked the box. A sentence like “Testing went well” gives no information, so it's a weak answer. A strong answer says what you looked at and what you fixed.
2. Step 1: About your closed test
This step asks how you ran your test. There are four questions.
Was it difficult to recruit testers?
This asks about difficulty, so there's no right answer. Be honest, and add a line about how you recruited them.
Weak answer
No. It was easy.
Strong answer
It wasn't easy. Friends and online communities didn't give us enough people, so we also used a real-device testing service and secured 12+ testers.
Did testers use all of your app's features?
Rather than claiming they used everything, you'll be more credible if you separate what was and wasn't checked. If some features weren't used, explain why.
Weak answer
Yes, they used all features.
Strong answer
From first launch through the main screens (home, list, and detail, which don't require sign-in), we checked on every device. Payments and push notifications need a real account, so we only checked them with the developer's account.
Was tester usage similar to real users?
Weak answer
Yes, it was similar.
Strong answer
Testers launched the app daily after installing and checked that it reached the home screen, so session length differs from real users who use it several times a day for longer. In exchange, we repeatedly verified that first launch works across multiple manufacturers and OS versions.
What feedback did you collect, and how?
This is the most important question. Write about how you collected it and what you collected separately.
Weak answer
Testers said it works well.
Strong answer
We checked per-device run logs and screenshots of each run, and recorded the error code and device model for every failed run. We found that on two Android 11 devices, the permission request screen was hidden behind the app on first launch.
3. Step 2: About your app
These questions are about the app itself: your target audience, value proposition, and expected installs in the first year. They aren't about testing, so write facts rather than marketing copy.
- Target audience — keep it narrow, like “office workers in their 20s and 30s who struggle to get up in the morning.” Avoid “all users.”
- Value proposition — one sentence on how you differ from competing apps. Rather than listing features, describe “what it does for the user.”
- Expected installs in the first year — answer with a range. It's better not to exaggerate; a big number with nothing behind it raises doubts about how ready you are.
4. Step 3: Production readiness
This asks how you applied what you learned in testing to your app. It's where approvals are most often won or lost.
Weak answer
We fixed bugs and improved stability.
Strong answer
We shipped three updates during testing. 1.0.3 fixed the hidden permission screen on Android 11; 1.0.4 shortened the splash screen after we noticed first-launch loading was slow; 1.0.5 reduced memory use on low-end devices.
When you include version numbers and what you fixed, the reviewer can verify it. That's why shipping an update every 3–4 days during testing makes this answer much easier to write.
5. What to gather before you answer
Answers written from memory end up vague. Gather these five things first and you can carry them straight into each question.
- Test start and end dates, and how many devices stayed installed during that time
- The versions you shipped during testing and what changed in each
- Devices where runs failed, with the error and OS version at the time
- Screenshots of first launch (showing that permission requests and onboarding work)
- Features you couldn't check, and why
6. Answers to avoid
- Making up feedback. If you write unverifiable claims like “All 12 testers said the UI was easy to use,” it's your account that's at risk if it becomes an issue, not just the app.
- Answering “Yes” to everything. Saying you had no difficulties at all actually makes it look like you didn't test.
- Submitting a copied template as is. Reviewers notice when the same sentences show up across many apps.
- Padding with feature lists. The question isn't what features you have; it's what you learned from testing.
Frequently asked questions
- Can I use a service that writes the questionnaire for me?
- We don't recommend it. Making up tester experiences that never happened means giving Google false information, and if it becomes an issue, it's your developer account that's at risk, not just the app. Writing it yourself based on what actually happened is safer and more likely to pass.
- Do I need to write in English?
- You can write in English or in your own language. Either way, long, vague sentences don't come across well, so keep it concise and focused on numbers and concrete facts.
- My testers didn't actually give feedback. What do I write?
- Don't invent feedback you didn't get; write about what you actually did. Facts you observed during testing — errors found in per-device runs, crash logs, the OS versions of devices where installation failed — are solid evidence on their own.
- How long should my answers be?
- Specifics matter more than length. Three to five sentences per question is enough; what matters is that you include numbers (devices, days, number of versions) and the actual changes you made.
- If I'm rejected, do I have to start over?
- It depends on the reason. If you were rejected because your answers weren't detailed enough, you can improve them and apply again. If the testing itself didn't meet the requirement, you may need to run more closed testing.
Meet the requirement without recruiting testers
DUIRE joins your closed test with real Android devices and opens your app every day for 14 days. Registering your app and checking installability are free.