Good tester feedback comes from asking specific questions, giving testers one easy place to answer, and writing down what you change because of it. You need this for more than a better app: when you apply for production access, Google says "You must summarize your testing feedback". So plan how you'll collect feedback before day 1, not on day 14.
Where feedback can come from
Private feedback in Play Console
Testers can send you private feedback on the test version through Google Play. You'll find it in Play Console under Monitor and improve > Ratings and reviews > Testing feedback.
Two facts from Google's help are worth knowing:
- "Testers cannot leave public reviews on Google Play for test versions."
- Private feedback "won't affect your app's public rating."
So testers can be blunt without hurting your future rating. Tell them that. It makes honest criticism more likely.
Your own channels
Play Console feedback is useful, but it's limited to short text. Most developers add one of these:
- A short form (a few questions, two minutes to fill in) sent at the end of week one and week two.
- A group chat or channel, which Google itself suggests as a best practice for testers. Good for quick bug reports and screenshots.
- An in-app feedback button that opens email with the app version and device model filled in.
Pick one main channel and stick to it. Feedback spread across five apps gets lost.
Ask questions that get usable answers
"Any feedback?" gets "looks good" or silence. Ask about specific moments instead:
- What did you try to do first, and did it work?
- Was there any screen where you didn't know what to do next?
- Did the app crash, freeze or show an error? What were you doing?
- Which feature did you use most? Which did you never open?
- If you could change one thing, what would it be?
- What phone and Android version do you use?
Questions 1, 2 and 4 give you engagement information. The production access form asks whether testers used all your features and whether their usage matched what you expect in production. Question 3 gives you bugs. Question 6 makes bugs reproducible.
Make bug reports reproducible
Ask testers to include:
- what they did, step by step
- what they expected to happen
- what happened instead
- a screenshot or screen recording, if possible
Don't expect perfect reports. A tester who says "the save button didn't work on the second screen" has done their part. Your job is to ask one follow-up question, not to send them a template to fill in.
Keep a feedback log
A simple spreadsheet is enough. One row per piece of feedback:
| Date | Tester | Source | Feedback | Type | Action | Version fixed |
|---|---|---|---|---|---|---|
| Day 3 | Tester 4 | Group chat | Sign-up email took 10 minutes | Bug | Switched email provider | 1.0.2 |
Use tester numbers rather than names if you share the log with anyone. The log pays off three ways:
- you can see patterns (five people stuck on the same screen is a priority)
- you can tell testers what was fixed, which keeps them engaged (see how to keep testers engaged)
- you have the facts you need for the application form
Turn feedback into your production access answers
Google's production access form has three parts. Feedback feeds into two of them:
- About your closed test: a summary of the feedback and how you collected it.
- About your production readiness: the changes you made based on the closed test, and how you decided the app was ready.
With a log, these answers almost write themselves: "We collected feedback through Play Console's testing feedback and a group chat. Testers reported X, Y and Z. We fixed X and Y in version 1.0.2 and redesigned Z." That's specific, honest and easy to check.
One warning: the form is lost if you leave the page without clicking Next or Apply. Draft your answers in a text file first. Our apply for production guide has example answers for each question.
What to do with feedback you won't act on
Not every suggestion should be built. It's fine to write "we decided not to add X before launch because Y". Being clear about why you kept something is part of showing you used the test seriously.
What to avoid
- Don't ask testers for Play Store ratings or reviews as part of the test. They can't leave public reviews on test versions, and incentivizing reviews is against Google Play policy.
- Don't invent feedback for the application. Your answers should describe what really happened in the test, and vague or made-up answers don't help your case.
- Don't collect personal data you don't need in your feedback form. A tester number and a device model are usually enough.
Key takeaways
- Read Testing feedback in Play Console and use one channel of your own.
- Ask specific questions about tasks, confusion and crashes.
- Log every piece of feedback and what you did about it.
- Your log becomes your production access summary.
GoPlayTester runs the 14-day test with 12+ real testers, and you can see how it works in our setup guide. If you need testers for your next closed test, you can order here.
