Most advice about Google Play's closed-testing rule is about getting 12 testers and keeping them for 14 days. Very little of it says what those testers should do once they are in. The usual answer is "open the app every day", and that is the floor, not the job.
A tester who opens your app for ten seconds a day keeps your count alive. A tester who uses it like a real user finds the bug that would have been your first one-star review. Here is what the second kind of tester does, and what you can give them so they do it.
What Google actually checks
For newer personal developer accounts, Google requires a closed test with at least 12 testers who stay opted in for 14 days in a row before you can apply for production. That part is clear.
What counts as "engaged" is less clear. Google does not publish an exact activity threshold, and the production application asks about your testing, the feedback you received and what you changed. So treat daily use as necessary but not sufficient. A test where testers installed the app and never touched it again gives you nothing to write in that application, and it may not satisfy Google either.
This is why PeerPlay checks that a tester actually opened the app for a real minimum session each day, not just that it is installed, and removes testers who go quiet from a round.
A 14-day plan for a tester
Days 1 and 2: install from the Play Store test link, go through onboarding like a new user, and note anything confusing in the first minute. First impressions only happen once.
Days 3 to 7: use the core features the way a real user would. Create things, edit them, delete them, come back the next day and check they are still there. Most real bugs live in that last step.
Days 8 to 11: try the edges. Turn off the network, rotate the phone, switch apps mid-task, use very long or empty inputs. If the developer ships an update, retest what changed.
Days 12 to 14: repeat the main flows on the latest version and send a short final note: what worked, what broke, what was confusing. That last note is often the most useful thing a developer gets from the whole test.
What real testers found in 14 days
PeerPlay's first paid campaign was for Nada, a women's health and cycle tracking app. It ran from September 16 to October 6, 2026. Testers sent 14 feedback items, and the developer marked 8 as solved during the test.
None of those were found by opening the app and closing it. They included a schedule switch that did nothing, a schedule list that did not refresh after deleting an item, cycle tracking that stopped around the 19th cycle, and reversed quotation marks in notes. Every one of them needed someone to use a feature, come back to it, or push it further than the happy path.
The same campaign also shows why the count matters. On day one only 7 testers were active. From September 17 to October 1, at least 12 were active every day. 18 testers joined in total, 11 completed all 14 days and 3 quit, and Google granted Nada production access.
What developers should give their testers
Testers do better work when you tell them what to look at. Write three to five short scenarios, such as "create an entry, close the app, reopen it tomorrow and edit it". Give them one place to send feedback, and say what a useful report includes: what they did, what they expected and what happened.
Ship at least one small update during the 14 days, and tell testers what changed. It gives them a reason to look again, and it gives you something concrete to describe when Google asks what you changed based on testing.
Finally, recruit above 12. Someone will be slow on day one, someone will quit. A buffer of a few testers is cheaper than restarting the clock.
Top comments (0)