Can the Same 12 Testers Cover Multiple Play Apps?

You can use the same testers for every app you publish. You cannot use the same opt-in. Each app runs its own closed test, and each tester has to join that app's test individually — which means a person who helped you launch your last app has contributed nothing to your next one until they tap the new opt-in link.

Google's requirement is framed per app: personal accounts created after 13 November 2023 must run a closed test for their app, with at least 12 testers opted in continuously for the 14 days preceding the application. Production access is applied for per app as well.

The good news is that the hard part — finding reliable Android users — is a problem you only solve once. The second launch is faster, cheaper, and less uncertain than the first.

What carries over and what does not

How to run a repeat window properly

Message the opt-in explicitly

The single most common failure on a second launch is assuming that an experienced tester knows what to do. They do — for the app they already joined. Most people will reasonably assume their previous opt-in still applies, and will reply "already done" without having opened the new link.

Write it plainly: "This is a different app, so you will need to opt in again using this link. Your previous opt-in does not transfer."

Verify in Play Console, per app

Each app's closed testing page shows its own opted-in count. App one's healthy count tells you nothing about app two. Check the new app's count daily for the full window, exactly as you did the first time.

Recruit to 15-16 again

Experienced testers are not automatically more reliable testers. On a repeat launch, the novelty is gone, testers may have already seen your app style, and everyone involved is a little more casual about it. The buffer argument applies with more force, not less.

Across OnTesters' own campaign data, testers dropping below the 12-tester minimum accounts for roughly 40% of the rejections we see. That is a headcount failure, and it happens on repeat launches to publishers who assumed the first cohort would simply follow them across.

Keep the feedback separate

Google states you must summarise your testing feedback when applying for production access. Application two needs a summary of app two's test. Reusing the first summary describes a different test on a different build, and it is not a substitute.

The upside of a repeat window is that you can collect better feedback. You know what testers tend to report, you have a reporting channel already set up, and you can give the second cohort a task list informed by the first run.

Running two windows at once

Publishers with a portfolio sometimes try to run several closed tests concurrently. It is possible, and it is a coordination decision rather than a policy one.

For two apps with a 15-16 tester cohort each, concurrency means holding 30-32 opted-in testers across two tracks. That is achievable with a managed pool and unpleasant by hand. If your testers are doing double duty across both apps, make sure they understand they need two separate opt-ins — and that a count of 16 people is not a count of 32 opt-ins.

When reusing testers is a bad idea

• If the apps serve very different audiences. Google recommends recruiting testers who represent your app's intended audience, because that is where device-specific and use-case-specific bugs surface. Twelve productivity-app testers will not find much in a fitness app.
• If the first cohort was already marginal. If you barely held 12 the first time, do not build a second window on the same people without adding new sources.
• If the same people tested several of your apps already. Habituation is real. Feedback quality drops when a tester has seen your patterns repeatedly.

A repeat-launch checklist

1. Confirm app setup is complete — a closed test cannot start until it is.
2. Create the closed track for the new app and add testers.
3. Publish, then wait for the opt-in link to resolve — Google documents a delay of several hours after the first release.
4. Send the opt-in link with an explicit note that the previous opt-in does not transfer.
5. Recruit to 15-16 rather than 12, mixing existing testers with new sources.
6. Verify the new app's opted-in count daily, separately from any other app you are running.
7. Hold 14 continuous days, ship two or more updates, and collect app-specific feedback.
8. Write a fresh feedback summary for this app's application.

The mechanics of a reused opt-in

Reusing testers works cleanly once you understand that the opt-in attaches to the app's testing program rather than to the person's relationship with you.

The row that causes the damage is the first. A tester who has helped twice before is the most likely person to reply "already done" without having opened the new link, and the least likely person you will think to verify. Check the count in Play Console per app, and treat a reassurance as a prompt to look rather than as a substitute for looking.

Making a standing pool work

If you publish repeatedly, the difference between a comfortable second launch and a repeat of the first is whether you kept anything from the first.

1. Record who held for the whole window. Not everyone who opted in — the people who were still opening the app on day 12.
2. Record who reported something useful. A tester who filed one real bug is worth more than three who installed silently.
3. Record which channel they came from. Over two or three launches this tells you which sources are worth the effort, and which are not.
4. Thank people specifically, mentioning what they reported. Testers who feel their report mattered are far more likely to engage on the next app.
5. Top up with new testers each time. A pool that never refreshes becomes a cohort of people who have seen your patterns three times, and habituation shows up as thinner feedback.

Two data points from our own campaigns are worth carrying into that pool strategy. Testers dropping below the 12-tester minimum accounts for roughly 40% of the rejections across 1,500+ analysed campaigns, and campaigns where testers were active on 10 or more days correlated with success at 97% against 41% for 5-7 active days. OnTesters' own figures. A pool chosen for the second number is worth more than one grown for size — and if you are assembling rather than buying, the channel comparison in How to Find Android App Testers for Closed Testing is the place to start.

Sequencing two windows, if you have to

Publishers running a portfolio eventually ask whether they can run two closed tests at once. You can, and it is a coordination decision rather than a policy one.

If you do run them concurrently, two rules keep it manageable. Stagger the start dates so both windows are not at their most fragile point in the same week, and use a single written checklist that lists every app and its current opted-in count so that verifying all of them takes one pass rather than remembering. If your testers are helping with both apps, say explicitly that they need two separate opt-ins — a cohort of 16 people is not a count of 32.

Whether you run one window or three, the underlying discipline is the same as a first launch: recruit past the minimum, brief in writing, verify daily, and ship updates you can point to. What that looks like end to end is in How to Get 12 Testers for Google Play: 7 Methods.

Deciding when to start the second app

The per-app rule makes the sequencing of a portfolio a real planning question rather than an afterthought.

The constraint is simple arithmetic: each app needs a 14-day window, and windows cannot be compressed. Three apps cannot be launched in a fortnight on a personal account, no matter how many testers you know. If you have a roadmap, the window for app two should appear in it as a fixed two-week block, in the same way you would plan for a store review.

Two practical rules follow. Do not start app two's window while app one's review is still open, because a request for more testing on app one would leave you managing two fragile windows at once. And do not start a window you cannot personally supervise for a fortnight — the daily count check is the thing that makes these windows hold, and it is not delegable. What the window requires day by day is in Google Play 14-Day Closed Testing: What Resets.

What a second window costs in calendar time

Everything about the first launch repeats, and the repetition has a cost that is easy to underestimate when you are planning a roadmap rather than a single release.

Only the first row is genuinely one-off. Everything else repeats, which is why a portfolio plan that budgets two weeks for a second launch is short by roughly the whole recruitment and review allowance. The realistic figure is close to four weeks per app, and the breakdown is in How Long Does Google Play Closed Testing Take?

Frequently Asked Questions

Can I reuse testers for a second app?

Yes. The people are reusable, and serial publishers build a standing pool for exactly this reason. What does not carry over is the opt-in — each tester joins each app's closed test individually.

Does my existing cohort count toward the new app's 12?

No. The opt-in is per app, so your existing testers count toward the new app only once they have opted in to the new app's closed test. Their clock for that app starts at their opt-in.

Can I run two closed tests at the same time?

Google documents that internal tests can run concurrently with closed and open tests for different app versions. Running closed tests for two different apps means maintaining two separate cohorts and two opted-in counts, which is a coordination decision rather than a policy one.

Do I need to run the 14 days again for a second app?

Yes. The requirement is per app: at least 12 testers opted in continuously for the 14 days preceding each production access application.

Do repeated testers count for less?

Google does not publish anything suggesting reused testers count for less. The practical concern is engagement — testers who have seen your app patterns before may be less thorough, so it is worth mixing in new sources.

Sources

Google Play Console Help — App testing requirements for new personal developer accounts (per-app requirement, continuous opt-in, feedback summary obligation, diverse-tester best practice, feedback collection guidance). Google Play Console Help — Set up an open, closed, or internal test (track setup per app, opt-in mechanics, several-hour link delay). OnTesters campaign figures are our own.