FAQ
Questions, answered
Why does Google require closed testing?
Since 2023, new personal Google Play developer accounts must run a closed test with at least 12 testers for 14 consecutive days before they can publish an app to production. It's Google's way of reducing low-quality and throwaway accounts.
How does TestSlot verify testers actually keep the app?
Each tester runs our Android app, which performs a background check once a day to confirm whether your app is still installed, then reports the result to our server. The streak count is computed server-side using real timestamps, so it can't be faked by changing a phone's clock.
What exactly do I do in Play Console?
Add our single tester group email to your closed test's tester list. That one action gives every TestSlot tester access to your app - you never manage individual tester emails.
How many testers and days do I need?
Google's bar is 12 testers for 14 consecutive days. When you list your app you choose the number of slots and required days; we recommend matching Google's minimums or going slightly above to leave a safety margin.
What happens if a tester uninstalls the app?
Their streak is affected. We allow a small grace window for a missed daily check (phones with aggressive battery settings can delay background tasks), but a tester who removes the app will see their streak reset, and you'll see it reflected on your dashboard.
Can I sign in without a Google account?
Yes. App owners can sign up with an email and password or with Google. Testers sign in through the mobile app, currently with Google.
Is this against Google Play's policies?
TestSlot provides real human testers using real devices and does not automate installs or fake engagement. You're responsible for following Play Console's terms; we're a tool to help you coordinate genuine testers.
Is iOS supported?
No. The closed-testing requirement is a Google Play thing, and reliably detecting installed apps is only possible on Android, so the tester app is Android-only.
How much does it cost?
Pricing is per app you list for testing - see the pricing page for current details.
Does the 14-day clock reset if a tester drops out?
Not necessarily to zero, but it stops counting. Google looks for a 14-day window during which you consistently had 12 or more active testers, so if your count falls below 12 the streak is interrupted until you are back above the line. Replace the tester within hours and the impact is minimal; spend three days below 12 and those days do not count toward your 14. TestSlot assigns a replacement automatically from its active pool when someone drops, so your count stays at 12 without you managing it.
Can I use friends and family as testers?
Yes - Google places no restriction on who your testers are, only on how they behave. Each one needs a real Google account, must opt in through your official link, must install on a real Android device, and must stay installed for the full 14 days. The problem is reliability rather than eligibility: friends typically agree, then forget to opt in, or uninstall a few days later to free up storage. They work well when they genuinely want the app itself - a fitness enthusiast testing your workout app - and poorly when they are doing you a favour.
How long does the whole process take, including Google's review?
Setup in Play Console takes 1-4 hours including Google's initial release review. Sourcing testers takes hours with TestSlot, or days to weeks recruiting manually. The testing period itself is exactly 14 days and cannot be shortened. Google's production access review then takes 3-7 days. That works out to roughly 17-19 days end to end with TestSlot, against 25-40 days when you recruit testers yourself and risk restarts from dropouts.
Why would Google reject production access even with 12 testers?
Because Google evaluates engagement, not just headcount. The most common cause is testers who installed the app and never opened it - functionally identical to no testing at all. Other frequent reasons are testers on emulators or virtual devices, pushing zero app updates during the 14 days, and vague answers on the production access questionnaire. Push two or three small updates during testing and keep notes on tester feedback so you have something concrete to write.
What is the difference between closed and open testing?
Closed testing is invitation-only: testers join through an opt-in URL you provide, and only those Google accounts can install the build. Open testing is a public beta anyone can join without an invitation. Only closed testing counts toward the mandatory requirement - open testing does not satisfy the 12-tester, 14-day rule no matter how many people join it. Internal testing, the third track, allows up to 100 pre-registered testers with no minimum duration and also does not count.
What is "irregular testing activity" and how do I avoid it?
It is Google's term for testing patterns that look artificial, and being flagged can invalidate your testing period or delay your review. Known triggers include bulk opt-ins from one IP address, emulator device fingerprints, testers who install but never open the app, Google accounts with a history of testing manipulation across many apps, and a mismatch between the account that opted in and the account that installed. Real people on real devices, opting in independently and actually using the app, is what avoids all of it.
Do I still need closed testing with an organization account?
No. The requirement applies only to personal developer accounts created after 13 November 2023. Organization accounts, registered under a legal business entity with a D-U-N-S number, are exempt and can publish straight to production. A D-U-N-S number is free from Dun & Bradstreet and usually takes a few days, but you need an actually registered business to get one - it is not a way around the requirement if you are an individual developer.
Does this work for Flutter, React Native, or Kotlin Multiplatform apps?
Yes. Whatever you build with, the artifact you upload to Play Console is a standard Android App Bundle, and Google's closed testing requirement applies to it identically. Your framework affects how you produce the release build, not how testing works. Testers install from the same opt-in link and our verification works the same way.
Still have a question?
Get started