What Feedback Should You Collect During Google Play Closed Testing?

A closed test should collect more than a simple answer to “Did the app work?” The goal is to identify problems that should be fixed before the production release.

When testers receive only an open-ended request, responses often stop at “No issues” or “It worked.” Prepare a clear checklist in advance so that every tester knows what to examine.

The five essential feedback categories

1. Launch and sign-in
2. Core features
3. Interface and wording
4. Speed and stability
5. Continued use

1. Launch and sign-in

If a tester becomes blocked during the first session, they cannot evaluate the rest of the app.

Ask testers to check whether:

• The app launches after installation
• The app proceeds beyond the splash screen
• A new account can be created
• Sign-in works
• Password reset works
• External authentication such as Google Sign-In works
• Permission requests are explained clearly
• The tester can recover after an error

Example questions

Could you move from first launch to the home screen without becoming confused?
When sign-in failed, did the message explain what went wrong?

2. Core features

Focus on the actions that deliver the app’s main value.

Examples include whether the tester can:

• Create data
• Edit data
• Delete data
• Search
• Select a photo
• Save a result
• Share content
• Review history

Do not ask every tester to inspect every feature with equal depth. Assign priorities.

3. Interface and wording

A label that is obvious to the developer may be unclear to a first-time user.

Ask testers to check:

• Whether each button’s purpose is clear
• Whether input examples are useful
• Whether an error message explains the next action
• Whether text is clipped
• Whether content remains readable in dark mode
• Whether the layout works with a larger system font size
• Whether the app is usable on a small screen
• Whether back navigation causes an unexpected exit

Better questions

Was it clear from the screen that saving had completed?
Was there any screen where you were unsure which button to press?

4. Speed and stability

Record symptoms such as:

• Slow launch
• Loading that never finishes
• A frozen screen
• An app crash
• No way to retry after a network failure
• Slow image or list rendering
• Excessive battery consumption
• Different results from the same action

“Felt slow” is difficult to act on. Ask how many seconds it took and which action was being performed.

5. Continued use

An app may work during the first session and fail several days later.

Ask testers to verify whether:

• The sign-in state is preserved
• Saved data remains available
• Notifications arrive as expected
• The same data is not created twice
• The app still works after the date changes
• Data remains after an app update
• They would want to use the app again

Use the 14-day testing period as an opportunity to find issues that appear only through continued use.

Information required in a bug report

Give testers a template so that the issue can be reproduced.

Device model:
Android version:
App version:
Date and time:
Screen where it occurred:
Action performed:
Actual result:
Expected result:
Reproduction rate:
Screenshot: if needed

It helps if the app version can be found easily in the app’s settings or the Android app-information screen.

How to report that no problem was found

A useful report describes the tested scope rather than saying only “No issues.”

On a Pixel 8 running Android 15, I tested account registration, sign-in,
photo registration, editing, deletion, and data restoration after restarting.
I did not find a major issue within that scope.

This makes it possible to distinguish tested features from features that were not checked.

Feedback tracking table

Example severity levels

• Critical: The app cannot launch, sign in, or complete its central function
• High: Many users are likely to fail the task
• Medium: A workaround exists, but the experience is confusing
• Low: A minor visual issue or enhancement request

Use the feedback in your production-access application

A clear record helps you explain the testing process.

Testers reported that it was difficult to tell whether saving had completed.
We added a completion message and changed the button state, then confirmed the
improvement in an updated build.

The goal is not to make the feedback count look large. What matters is identifying important problems, fixing them, and confirming the result.

Do not ask too many questions

A long questionnaire reduces the response rate.

These five questions are enough for an initial round:

1. Could you launch and sign in successfully?
2. Could you complete the requested core action?
3. Was any screen or wording difficult to understand?
4. Did the app become slow, freeze, or close unexpectedly?
5. What is the single most important improvement you would request?

Summary

Organize closed-test feedback so that it records:

• Which device was used
• Which app version was tested
• Which action was performed
• What happened
• What should have happened
• What was changed in response
• Whether the updated version resolved the issue

Specific records improve the app and can also support your production-access application answers.