Zo werkt de gesloten test van Google Play met 12 testers en 14 dagen (2026)

Beleid gecontroleerd op 27 september 2026. Alles hieronder volgt de documentatie die Google op dat moment had gepubliceerd over de gesloten test en productietoegang. Waar Google niets heeft gepubliceerd, zegt dit artikel dat, in plaats van het gat op te vullen.

Een van de grootste veranderingen is de vereiste van een gesloten test met 12 testers: betrokken persoonlijke ontwikkelaarsaccounts moeten een kwalificerende gesloten test afronden voordat ze productietoegang kunnen aanvragen. De drempel van 12 gedurende 14 dagen halen publiceert je app niet en garandeert geen goedkeuring.

Veel ontwikkelaars snappen niet waarom deze vereiste bestaat, hoe het proces werkt en waarom het zo lastig is om 12 betrouwbare testers te vinden die twee volle weken willen meedoen. Dit artikel legt alles helder uit, stap voor stap, zodat je het hele proces begrijpt voordat je je app lanceert. Wil je het gedoe overslaan, dan kan onze testservice het hele proces voor je regelen.

Wat is de eis voor de gesloten test van Google Play in 2026?

Google kondigde dit aan op 9 november 2023, en de regel zoals die uiteindelijk luidt geldt voor persoonlijke Google Play Console-accounts die na 13 november 2023 zijn gemaakt. Dat zijn twee verschillende feiten en ze worden voortdurend door elkaar gehaald: de 9e is de dag van de aankondiging, de 13e is de peildatum voor het aanmaken van je account die echt bepaalt of je eronder valt.

Lees dat laatste stuk goed, want daar komt de meeste teleurstelling over dit onderwerp vandaan. De drempel halen publiceert je app niet. Het ontgrendelt de aanvraag, die Google daarna beoordeelt.

Google documenteert de vereiste voor persoonlijke accounts, waardoor organisatorische accounts buiten het genoemde bereik vallen. Dat is bewust niet dezelfde zin als "organisatorische accounts zijn vrijgesteld", een formulering die Google nooit gebruikt en die uitmaakt voor iedereen die een app tussen accounttypen heeft verplaatst. We werken dat netjes uit in het onderdeel over toepasselijkheid hieronder.

Google voerde de testvereiste in om de kwaliteit van apps te verbeteren door ontwikkelaars aan te zetten tot:

• Testen vóór de lancering
• Problemen opsporen en feedback verzamelen
• Bevestigen dat de app klaar is voor gebruikers
• Dezelfde aankondiging van november 2023 breidde daarnaast de ontwikkelaarsverificatie uit om malware en fraude tegen te gaan. Dat is een ander initiatief dan de gesloten test.

Dat betekent: voordat je live gaat, moet je app het volgende afronden:

Zodra minstens 12 testers elk 14 aaneengesloten dagen aangemeld zijn geweest, toont Play Console de optie om productietoegang aan te vragen. Google vraagt naar de betrokkenheid van je testers, de feedback, de wijzigingen tijdens de test en of je klaar bent voor productie. Variatie in apparaten en IP-adressen zijn kwaliteitspraktijken, geen gepubliceerde beoordelingsdrempels.

Geldt de eis van 12 testers voor mijn account?

Let op: 13 november 2023 is de peildatum voor het aanmaken van het account, niet de dag waarop Google het beleid aankondigde. De aankondiging kwam op 9 november 2023, en die twee data worden voortdurend door elkaar gehaald. Is je account in die tussenperiode gemaakt, dan telt de peildatum.

Zodra iemand weet dat de regel voor hem geldt, komen er steevast twee vervolgvragen, en die hebben verschillende antwoorden.

De eerste: heeft elke nieuwe app een eigen test nodig? In de praktijk geldt de eis per app, en ontwikkelaars met betrokken accounts melden dat ze er bij elke nieuwe app opnieuw aan moeten voldoen. Wat Google niet publiceert, is de belofte dat dit eeuwig zo blijft, en Product Experts melden dat de eis uiteindelijk kan verdwijnen naarmate een account publicatiegeschiedenis opbouwt. Behandel het dus als een eis op appniveau zolang het dashboard die toont, en controleer elke nieuwe app in plaats van iets aan te nemen. We gaan er dieper op in in heb ik voor elke app 12 testers nodig?.

De tweede: starten gewone updates van een app die al productietoegang heeft de teller opnieuw? Er is geen gepubliceerde eis om de test van 12 om 14 dagen te herhalen bij elke gewone update zodra die app productietoegang heeft. De normale beoordeling door Play en de overige beleidscontroles van Google gelden nog steeds voor elke release.

De keuze tussen persoonlijk en organisatorisch heeft gevolgen die veel verder gaan dan deze ene regel: kosten, verificatie en wie juridisch eigenaar is van de vermelding. Twijfel je nog, lees dan persoonlijke versus organisatorische Google Play-accounts voordat je je registreert.

Hoeveel testers heb ik in 2026 nodig voor Google Play?

De nuttiger vraag is waar de eis voor dient. Google zette het neer als testen, niet als tellen: problemen boven tafel krijgen, feedback verzamelen, daar iets mee doen en bevestigen dat de app klaar is.

Dus: werf er 12 omdat dat de regel is, en overweeg er een paar meer omdat afhakers een veelvoorkomende reden zijn dat je datum opschuift. Alleen het eerste is een eis van Google.

Wat telt er echt mee voor de 12 testers en de 14 dagen?

Bijna elke discussie tussen ontwikkelaars over deze regel komt doordat twee losse fasen op één hoop worden gegooid. Ze uit elkaar houden is het verschil tussen het juiste aantal dagen wachten en twee keer wachten.

Google zegt dat het je kan vragen door te gaan met testen wanneer je niet aan de testerseis voldeed of wanneer je testers de app tijdens de gesloten test niet gebruikten. Dat zijn twee verschillende problemen met twee verschillende oplossingen, en alleen het eerste is een getal.

Moeten testers de app elke dag openen?

Geen enkele gepubliceerde regel zegt dat. Googles getalsvoorwaarde is ononderbroken aangemeld blijven, en nergens in de huidige vereiste staat een aantal dagelijkse openingen, een minimumaantal sessies, een ondergrens aan minuten per dag of een aantal schermen dat elke tester moet bereiken.

Dat is geen vrijbrief om twaalf mensen te werven die één keer installeren en het daarna vergeten. De aanvraag voor productietoegang vraagt hoe je testers de app gebruikten en hoe dat zich verhoudt tot wat je van echte gebruikers verwacht, en Google noemt te weinig betrokkenheid als reden om je te vragen door te testen. Betrokkenheid is dus de moeite waard, maar streef ernaar als kwaliteit en niet als quotum, want er is geen quotum gepubliceerd.

Hebben testers echte apparaten of verschillende IP-adressen nodig?

Geen van beide staat in de gepubliceerde vereiste van Google voor de gesloten test. Er is geen genoemde voorwaarde dat elke kwalificerende tester een uniek fysiek apparaat gebruikt, en geen primaire Google-bron zegt dat je 12 testers 12 verschillende IP-adressen, netwerken, huishoudens of landen nodig hebben.

Vooral de IP-bewering verdient een label in plaats van een antwoord. Die gaat breed rond, ook in reacties van Community Product Experts, en die reacties spreken elkaar soms tegen. Behandel het als een melding uit de community: goed om te weten dat mensen het geloven, maar niet iets om je test omheen te plannen alsof Google het had opgeschreven. Wil je de lange versie, dan behandelen we de apparaatvraag in emulators en de gesloten test en de geografische vraag in testers in verschillende landen.

Telt de interne test mee voor de 12?

Nee. De vereiste van Google noemt specifiek een gesloten test, en beschrijft de interne test als optionele vroege kwaliteitscontrole. De interne test ondersteunt tot 100 testers en is echt nuttig om problemen te vinden voordat echte testers de build zien, maar hem uitvoeren brengt je niet dichter bij productietoegang.

Er is ook een praktische valkuil die je vooraf moet kennen: wie is aangemeld voor je interne test komt niet in aanmerking voor de gesloten test totdat hij zich afmeldt bij de interne test en zich aanmeldt voor de gesloten track. Heb je je eerste testers per ongeluk in de interne test gezet, dan moet je ze bewust verplaatsen.

De volledige vergelijking, inclusief wanneer elke track de moeite waard is, staat in onze analyse van interne, gesloten en open tests.

Hoe de 14 dagen werken als testers later instappen of zich afmelden

Meldt een tester zich af voordat de 14 dagen om zijn, dan telt hij niet meer mee, en zak je daardoor onder de 12, dan voldoe je niet langer aan de voorwaarde die Google publiceert: minstens 12 testers die minstens de afgelopen 14 dagen doorlopend aangemeld zijn. Omdat het venster altijd de recentste 14 dagen betreft, schuift je datum op zodra je mensen kwijtraakt. Google publiceert hier geen algoritme voor: er is geen gedocumenteerde regel dat één afhaker alle overige testers terugzet op dag nul, en de praktische controle is simpelweg hoeveel testers op dit moment aan de doorlopende voorwaarde voldoen. Dat is een veelvoorkomende reden waarom ontwikkelaars hun verwachte datum niet halen.

Een e-mailadres op de testerslijst zetten is niet genoeg. Een tester telt mee nadat hij zich via de testlink heeft aangemeld met een geschikt Google-account. Daarna moet hij de app met datzelfde account via Google Play installeren en testen. Play Console toont het aantal aangemelde testers, geen betrouwbare geschiedenis per persoon. Controleer het aantal daar, en houd zelf bij wanneer individuele testers instapten als je je datum wilt inschatten.

Wat gebeurt er als één tester zich afmeldt?

De aanmeldperiode van die tester is onderbroken, en een onderbroken periode telt niet. De dagen van vóór de afmelding kun je niet optellen bij de dagen na zijn terugkeer om samen 14 geldige dagen te maken. Komt hij terug, behandel dat dan als een nieuwe periode van 14 dagen vanaf de dag dat hij zich opnieuw aanmeldt.

Wat je dat kost, hangt af van je aantal testers én van wanneer de extra testers instapten. Met precies 12 zak je door één afmelding onder het minimum. Met 20 heb je nog flink wat marge in aantal, maar je datum blijft alleen beschermd als minstens 12 van de overgebleven testers voldoende vroege doorlopende aanmeldingen hebben. Later ingestapte testers kunnen je aantal redden zonder je oorspronkelijke datum te redden.

En als een tester de app verwijdert?

Verwijderen en afmelden zijn niet hetzelfde, en precisie loont hier omdat veel pagina's ze door elkaar gebruiken. Google bepaalt het getalscriterium via de aanmeldstatus. Geen enkele primaire bron stelt vast dat verwijderen op zichzelf de aanmeldperiode van een tester beëindigt of zijn teller opnieuw start.

Wat wel vaststaat, is het indirecte effect. Een app die niet geïnstalleerd is, levert geen gebruik op, en een tester die op dag twee verwijderde geeft je niets te beschrijven wanneer de aanvraag vraagt hoe je testers de app gebruikten. Ga dus achter herinstallaties aan omdat dat gebruiksbewijs waardevol is, niet omdat vaststaat dat verwijderen de telling breekt.

Zet een app-update de 14 dagen terug?

Er is geen gepubliceerde regel dat een nieuwe build de doorlopende aanmelding opnieuw start. Google gaat de andere kant op en ziet bijwerken tijdens de gesloten test als goede praktijk: de hele oefening draait om problemen vinden en oplossen, en de aanvraag voor productietoegang vraagt wat je daardoor hebt aangepast. Een release uploaden en dan in paniek raken dat je twee weken werk hebt vernietigd, is een heel gangbare en, voor zover primaire documentatie laat zien, ongegronde angst.

De enige kanttekening: dit is het ontbreken van een gepubliceerde regel, geen expliciete zin van Google dat "updates de periode nooit terugzetten". Zegt Play Console iets anders over jouw specifieke app, geloof dan Play Console. We ontleden de vraag netjes in zet een app-update de gesloten test terug?.

Daarom is de vraag naar professionele testdiensten gegroeid. Veel ontwikkelaars kiezen ervoor om professionele testers in te schakelen in plaats van weken kwijt te raken aan mislukte eigen pogingen.

Wat is de snelste manier om 12 testers voor Google Play te vinden?

Dat zet de vraag nuttig om. Je koopt geen snelheid, je koopt twee dingen: hoe snel je 12 aanmeldingen haalt, en hoe waarschijnlijk het is dat die 12 twee weken later nog aangemeld zijn. Elke route hieronder weegt dat anders af.

Google raadt zelf aan je persoonlijke en professionele netwerk te gebruiken: vrienden, familie, collega's en studiegenoten, plus relevante communities, volgers op sociale media en mensen die lijken op je toekomstige gebruikers. Dat laatste is de moeite waard om serieus te nemen, ook al is het geen eis, want de aanvraag vraagt hoe het gebruik door testers zich verhoudt tot wat je van echte gebruikers verwacht, en testers die niets op je doelgroep lijken maken die vraag lastiger.

Googles richtlijnen voor de gesloten test zeggen niet dat testers onbetaald moeten zijn. Op basis van die gepubliceerde richtlijnen kan een betaalde afspraak verenigbaar zijn met de eis, zolang die echt testen en echte feedback oplevert. Ze mag niet worden gebruikt om openbare beoordelingen, reviews, installaties, ranglijsten of de plek in de store te manipuleren.

Wat een begeleide testservice biedt

Omdat testers vinden ontzettend lastig is, gebruiken veel ontwikkelaars online testerdiensten met echte gebruikers van echte apparaten die klaarstaan om de eis van 14 dagen af te maken.

Een professioneel testteam levert:

PrimeTestLab haalt alle ingewikkeldheid uit de eisen van Google Play. Wij leveren geverifieerde testers die echte Android-apparaten gebruiken in 120+ landen. In plaats van weken zelf testers zoeken en aansturen, kun je 12 echte testers krijgen voor $19.99 en binnen enkele uren met testen beginnen.

De service van PrimeTestLab omvat activiteit van testers en feedback gedurende de hele periode van 14 dagen. Dat is onze servicenorm, geen door Google gepubliceerde eis om dagelijks te openen. Met 99,9% voltooide tests over 9.800+ geteste apps haalt het het wervingsprobleem van je bureau. Lees waarom een marge boven de 12 testers de moeite waard is.

Zo kunnen soloontwikkelaars en kleine teams apps publiceren zonder die twee weken achter mensen aan te zitten.

Onze cijfers: 9.800+ geteste apps

PrimeTestLab helpt ontwikkelaars te voldoen aan Googles eis voor de gesloten test, met drie pakketten:

We beheren een testersnetwerk dat is gebouwd voor de gesloten test van 12 om 14 dagen. Interne projectgegevens van PrimeTestLab, bijgewerkt op 15 augustus 2026. Een voltooide test betekent dat een betaald project de begeleide gesloten test heeft afgerond en het stadium van de aanvraag voor productietoegang heeft bereikt. Het betekent niet dat Google productietoegang heeft verleend. De servicecijfers hieronder zijn gebaseerd op die afgeronde opdrachten.

Het bekende probleem:

En het wervingsprobleem lossen we meteen op. De test start binnen 4-6 uur, en we blijven de ontwikkelaar begeleiden (de testers blijven aangemeld) tot de aanvraag is ingediend en jij ons Googles beslissing bevestigt.

Hoe stel ik de gesloten test van Google Play stap voor stap in?

Waarom zegt de aanmeldingslink dat de app niet beschikbaar is?

Dit gaat vaak mis, en het is bijna altijd een van deze negen dingen. Loop de lijst op volgorde af in plaats van meteen naar exotische verklaringen te springen.

1. De tester is ingelogd met precies het Google-account dat je hebt uitgenodigd, niet met een tweede persoonlijk account op dezelfde telefoon.
2. Bij een Google Groep is de tester lid geworden van de groep voordat hij de aanmeldingslink opende.
3. De release heeft de status Gepubliceerd, niet Concept, In beoordeling of Publicatie in behandeling.
4. Er zijn enkele uren verstreken sinds je eerste uitrol op de track.
5. Het land van de tester valt binnen de beschikbaarheid van de app.
6. Het apparaat van de tester is compatibel met de bundle die je hebt geüpload.
7. De tester heeft zich afgemeld bij de interne track, als hij daar ooit op stond.
8. Hij gebruikt de link van de gesloten test, niet die van een interne of open test.
9. Hij heeft beide stappen gedaan: de aanmelding accepteren en daarna installeren via Google Play.

Blijft het probleem na alle negen bestaan, dan gaan we dieper in app niet beschikbaar voor testers. Voor het uitnodigingsproces in het algemeen zie hoe je testers uitnodigt, en voor het probleem met groepen Google Groep werkt niet bij de gesloten test.

Wat een zinvolle test echt afdekt

Google publiceert geen testplan, geen dagschema en geen dekkingschecklist, en dit artikel gaat er ook geen verzinnen. Wat volgt is ons redactionele kwaliteitsplan: een redelijke opzet voor twee weken echt testen, aangeboden omdat "er is geen dagelijks quotum" klopt maar op zichzelf niet helpt. Zie het als een menu, niet als een nalevingsformulier.

De reden om dit allemaal te doen is niet dat Google het telt. Het is dat de aanvraag aan het eind vraagt wat je testers deden, wat ze je vertelden en wat je hebt aangepast, en een test die is opgebouwd zoals de lijst hierboven levert antwoorden op alle drie.

Zo vraag je na de test productietoegang aan

Dit is het deel van het proces dat de meeste artikelen overslaan, en juist dit deel bepaalt de uitkomst. De drempel halen is rekenwerk. De aanvraag is een geschreven betoog dat jij moet opbouwen.

Wat Google vraagt in het formulier voor productietoegang

Google publiceert de vragen. Wat Google niet publiceert is een beoordelingsschema, een aantal woorden, een lijst met zinnen die je de das omdoen, of enige formule die je antwoorden omzet in een beslissing. Wie zegt dat één bepaalde zin tot automatische afwijzing leidt, beschrijft een patroon dat hij zelf heeft afgeleid, niet een regel die Google heeft opgeschreven.

Wat je wel kunt doen, is antwoorden op basis van aantekeningen die je echt hebt bijgehouden. Elke vraag hieronder verwijst naar iets wat je uit je eigen 14 dagen zou moeten kunnen aanwijzen, en dat is het echte argument om tijdens de test aantekeningen te maken in plaats van ze achteraf te reconstrueren.

Komt het antwoord terug als een verzoek om meer testen in plaats van als toestemming, dan is dat een gedocumenteerde uitkomst en geen doodlopende weg, en het volgende onderdeel behandelt wat Google daar zelf over zegt.

Waarom Google zegt "meer testen nodig": wat we weten en wat niet

14 dagen volmaken en dan alsnog te horen krijgen dat je moet doortesten, is de meest demotiverende uitkomst van dit hele proces, en het gebeurt vaak genoeg dat er hele forumdraden over bestaan. Het eerlijke antwoord is dat Google je minder vertelt dan je zou willen, en de nuttige reactie is om de twee dingen die Google wél noemt op te lossen voordat je achter de rest aan gaat.

Lees de twee hieronder als Googles eigen uitgewerkte voorbeelden, niet als de volledige lijst. Het zijn de oorzaken die je als eerste wilt uitsluiten, omdat het de enige zijn die iemand buiten Google kan aanwijzen.

Zit je nu met een concreet bericht "meer testen nodig", dan pluizen we het hele proces uit in wat te doen als Google om meer testen vraagt, en de afwijzingspatronen breder in waarom een gesloten test wordt afgewezen.

Voor wie deze service is

Een kort stukje vertrouwen, geen tweede verkooppraatje:

Inbegrepen:

Zijn 12 testers genoeg, of kun je er beter meer nemen?

Het is goed om duidelijk te zeggen wat extra testers niet doen, want veel pagina's suggereren het tegenovergestelde. Ze verkorten de 14 dagen niet, ze vervangen echte betrokkenheid niet, en ze garanderen geen productietoegang. Dat gezegd hebbende, hier is een eerlijke vergelijking van je opties.

Voor de meeste ontwikkelaars is het Starter-pakket van PrimeTestLab met 12 testers de voordeligste optie. Wil je extra bescherming tegen afmeldingen, dan geeft het Professional-pakket met 20 testers je een marge van 8 testers. Het Enterprise-pakket met 25 testers voegt een marge van 13 testers en een vaste accountmanager toe. Als er na de kwalificerende test geen productietoegang wordt verleend, bevat elk pakket een gratis nieuwe test of volledige terugbetaling, volgens ons terugbetalingsbeleid. Wat geen enkel pakket kan beloven, is Googles beslissing zelf.

Andere eisen die een lancering kunnen blokkeren

De gesloten test is één publicatievereiste, niet de enige. Een app kan de eis van 12 testers halen en alsnog vastlopen op iets wat niets met testen te maken heeft, dus het loont om te weten wat er nog meer in de rij staat voordat je een lanceerdatum prikt.

De andere punten om bij je eigen app na te lopen:

• Doel-API-niveau. Nieuwe apps en updates moeten op een recente Android-versie mikken, en de ondergrens verschilt per apparaattype. Zie de gids over het doel-API-niveau voor de actuele cijfers en de uitstelprocedure.
• Beleid rond machtigingen. Gevoelige machtigingen hebben eigen verklaringen en deadlines, en die data schuiven. De kalender met beleidsupdates volgt elk ervan met de actuele ingangsdatum.
• Contentverklaringen van de app. Gegevensbeveiliging, privacybeleid, advertenties, contentclassificatie en doelgroep moeten allemaal compleet zijn voordat een release wordt uitgerold.
• Gewone beleidsbeoordeling. Elke release wordt op zichzelf beoordeeld, ongeacht je testgeschiedenis.

We houden de data hiervan bij op één beleidskalender in plaats van ze hier te herhalen, want deadlines die op meerdere plekken staan gaan uit elkaar lopen en dan klopt een van de kopieën niet meer.

Prijsplannen

Bespaar jezelf het gedoe van zelf testers zoeken. Alle pakketten bevatten alles wat je nodig hebt om te voldoen aan de eis van 14 dagen gesloten testen bij Google Play. Enterprise is op dit moment het actiepakket met de beste prijs-kwaliteitverhouding: het bevat meer testers dan Professional met een grotere korting, en daarom kunnen 25 testers minder kosten dan 20. Als er na de kwalificerende test geen productietoegang wordt verleend, bevat elk pakket een gratis nieuwe test of volledige terugbetaling, volgens ons terugbetalingsbeleid.

Veelgestelde vragen

Conclusie

Doe je dit zelf, dan komt het hele proces neer op een korte reeks stappen. Al het andere in dit artikel is detail dat aan een van deze tien stappen hangt.

1. Controleer of het Play Console-dashboard van de app de vereiste echt toont.
2. Rond het instellen van de app af: Play Store-vermelding, contentverklaringen, Gegevensbeveiliging.
3. Publiceer een release op de gesloten testtrack en wacht tot die de status Gepubliceerd heeft.
4. Zorg dat minimaal 12 testers zijn aangemeld, en controleer het aantal op het tabblad Testers, niet in de uitnodigingslijst.
5. Houd er minstens 12 doorlopend aangemeld gedurende de volle 14 dagen. De datum wordt bepaald door de twaalfde die zich kwalificeert.
6. Doe een echte test: geef je testers iets te doen en schrijf op wat ze je vertellen.
7. Los de echte problemen op die naar boven komen en noteer wat je hebt aangepast.
8. Vraag het aan vanaf het dashboard zodra Play Console het aanbiedt.
9. Vul het formulier in op basis van je eigen aantekeningen, niet met een sjabloon.
10. Ga ervan uit dat de beoordeling van Google meestal binnen 7 dagen gebeurt, niet dat het gegarandeerd is, en blijf testen als Google om meer vraagt.

Bij stap 5 verliezen mensen weken door te tellen vanaf de eerste uitnodiging in plaats van vanaf de twaalfde kwalificerende tester, en bij stap 6 door die twee weken als wachttijd te zien in plaats van als test.

12 betrouwbare mensen vinden die je app 14 dagen geïnstalleerd willen houden is echt lastig. Daar komt PrimeTestLab om de hoek kijken.

Controleer dit bij Google zelf

Dit artikel scheidt wat Google publiceert van wat alleen forums beweren, zodat je die eerste categorie zelf kunt controleren. Dit zijn de pagina's waar elke belangrijke uitspraak hierboven vandaan komt.

Waar dit artikel zegt dat Google iets publiceert, staat het in een van die drie. Waar het zegt dat iets uit de community komt of niet gedocumenteerd is, betekent dat: we hebben ze nagekeken en het stond er niet.