What to Write When Google Asks "How Did You Recruit Testers?"

The short answer: describe what actually happened, in plain words. Say who your testers were, where they came from, how you kept them engaged, and what you changed because of their feedback. A specific, truthful paragraph beats a polished, vague one.

When you apply for production access after your closed test, Play Console asks you to explain your testing. One of the questions is about how you found your testers. The exact wording and the number of questions can change, so check the current form and Play Console Help before you write anything. This post covers only the recruitment question.

What the question is really asking

Nobody outside Google knows exactly how answers are reviewed, so treat this as a reasonable reading rather than a rule. The question seems aimed at one thing: did real people test your app, in a way that tells you something useful?

The rule exists to stop apps being pushed to production untested. Since November 13, 2023, new personal developer accounts need a closed test before applying for production. The requirement started at 20 testers and is now 12 testers opted in for 14 days in a row. Your answer to the recruitment question is your chance to show those 12 were not just numbers.

The four things a good answer covers

1. Who your testers were

Give a category, not a list of names. "Android users I know personally, a developer community I belong to, and testers from a testing service" is clear. Don't name individuals and don't invent a persona that doesn't fit.

2. Where you found them

Name the actual channels. Some examples of things developers really do:

• Asking friends, family and coworkers who use Android
• Posting in a developer community, a subreddit or a Discord server
• Inviting existing users of a website, newsletter or iOS version of the app
• Using a tester-exchange group where developers test each other's apps
• Using a paid testing service

Whatever mix you used, say so. If you used a service, name the kind of service. Hiding it gains you nothing, and a mismatch between your answer and what happened is a risk you don't need.

3. How you kept them testing for 14 days

Recruiting is the easy half. Keeping 12 people opted in and using the app for two weeks is harder, and your answer should show you managed it. Mention what you actually did:

• Gave testers a short list of things to try (sign-up, the main flow, a settings change)
• Asked for written feedback in a form, email or chat thread
• Checked in during the 14 days rather than disappearing
• Replaced testers who dropped out before the counter was affected

4. What you did with the feedback

This is the part most people skip, and it carries the most weight. Pick two or three real changes. A crash on a specific screen, a confusing onboarding step, a button that was too small on a small phone. If you really fixed it, say so and say what you shipped.

A fill-in template

Replace everything in brackets with your own facts. If a sentence doesn't apply to you, delete it. Don't keep it for appearances.

I recruited [number] testers for the closed test of [app name]. They were [description: e.g. Android users from a developer community, friends and colleagues, and testers from a testing service]. I found them by [channels]. Testers installed the app from the closed testing track on their own Android devices, and [number] stayed opted in for the full 14 days.

I asked testers to [tasks: e.g. complete sign-up, use the main feature, try it on slow connections] and to send written feedback through [channel]. I checked in [how often].

Based on their feedback I changed [change 1], [change 2] and [change 3], and released those changes in build [version]. Before applying for production I [any remaining work: e.g. fixed a crash on Android 12, improved the empty state].

Keep it factual. You don't need to hit a word count. A few clear paragraphs are enough.

If you used a testing service

Using a service is a legitimate way to reach 12 testers, especially if you don't have a network of Android users. Describe it like any other channel, and say what the testers actually did.

For example, if you used TesterMob, the facts you could include are these: the testers used their own Android phones, used the app for about 20 minutes a day, and gave written feedback. If you added the optional Android SDK (the .aar file), you can also mention that your dashboard showed daily tester activity, which helped you see whether people were really using the app. Only include that if you installed it.

A possible sentence: "I supplemented testers from my own network with testers from TesterMob, a service where testers use their own Android devices and submit written feedback after daily use." Details on how it works are on the developer page and in the FAQ. Pricing is a one-time $9.99 per app in USDT, listed on the pricing page.

A caveat that applies to any service: TesterMob is not affiliated with Google and cannot guarantee production approval. Nobody honestly can.

What weakens an answer

• Vagueness. "I recruited testers from various sources" says nothing. Name the sources.
• Invented numbers. Don't claim "50 bugs found" or "200 feedback messages" unless you counted them. If you don't have a number, describe the change instead.
• Claiming more than happened. If testers only installed the app and did little else, don't say they "extensively tested every feature."
• Copy-pasting a generic answer. Templates from forums are fine as a starting shape, but an answer that could apply to any app helps no one. Mention your app's actual features and fixes.
• Contradicting your own test. If your closed test track shows 12 testers, don't write that you had 30. Keep the answer consistent with what Play Console shows.

Keep notes while the test is running

Writing a good answer is much easier if you collect material during the 14 days instead of reconstructing it afterwards. A simple notes file is enough:

1. The date you invited testers and through which channel
2. Who dropped out and when you replaced them
3. Each piece of feedback that led to a change, with the build number
4. Any issues you decided not to fix, and why

When the application form appears, you will already have the facts. You'll just be tidying them into paragraphs.

Remember the form can change

Google adjusts the testing requirement, the form and its questions from time to time. The numbers and wording in this post reflect what we know now, and the form you see may differ. Always check Play Console Help for the current requirements, and treat any template, including the one above, as a starting point rather than a guaranteed formula.

If something in your situation is unusual, such as a team account or an app with a very small potential audience, you can also contact us and we'll tell you what we know. We're a small team in Istanbul and San Francisco, and we'd rather give you a straight answer than a hopeful one.