Gesloten test van Google Play voor games: 12 testers in 2026

De meeste bestaande gidsen beantwoorden maar de helft van dit probleem. Algemene artikelen over gesloten testen leggen de eis van 12 testers uit zonder de releaserisico’s aan te raken die specifiek voor een game gelden, terwijl artikelen over game-QA het over prestaties en apparatenlabs hebben zonder de poort van productietoegang uit te leggen die de lancering in werkelijkheid blokkeert. Threads in de community vullen de ruimte daartussen met zelfverzekerde folklore: elke dag één keer spelen, drie updates uitbrengen, dertig minuten per sessie, een minimumaantal levels. Geen van die dingen is een gepubliceerde regel van Google, en dit artikel zegt dat elke keer dat er zo eentje langskomt. Alles hier is actueel op 12 augustus 2026, met de deadlines uit het beleid opnieuw gecontroleerd op 14 augustus 2026, en alles is terug te voeren op primaire documentatie van Google; waar het eerlijke antwoord “Google publiceert dat niet” is, drukt de pagina dat af in plaats van een getal.

De volgorde hieronder volgt de manier waarop het probleem zich in werkelijkheid oplost. Eerst de poort zelf, want je kunt niets plannen zolang je niet weet of die op jou van toepassing is en wat er precies wordt geteld. Daarna de laag die met games te maken heeft: wat een test die alleen aangemelde accounts optelt niet opmerkt, en hoe je elk van die risico’s test voordat de beoordelaars van Google het resultaat zien.

Vereist Google Play een gesloten test voor Android-games?

“Als je een nieuw persoonlijk ontwikkelaarsaccount hebt, moet je een gesloten test voor je app uitvoeren met minimaal 12 testers die in een periode van minimaal de afgelopen 14 dagen doorlopend aangemeld zijn geweest.”

Play Console Help, answer 14151465

Lees die zin ook op wat er niet staat. Er wordt niet gesproken over categorieën apps. De trigger hangt aan het account en niet aan wat je uploadt, dus het feit dat jouw bundle als game is ingedeeld, verandert niets aan de vraag of de poort geldt. Het materiaal van Google over gesloten testen behandelt apps en games binnen hetzelfde proces voor productietoegang, en noemt testen vóór de lancering van mobiele games expliciet als toepassing van de testtracks.

Lees hem nog een keer, nu op de woorden je app. De aanmaakdatum van het account bepaalt of de vereiste voor jou geldt, maar de kwalificerende test en de aanvraag voor productietoegang worden per afzonderlijke app afgerond. Het proces voor één game doorlopen, draagt niet over naar het volgende package dat je vanaf hetzelfde account publiceert: een tweede game krijgt een eigen gesloten test, eigen 12 testers en eigen twee weken. Die conclusie steunt erop dat Google de voorwaarde tegen “je app” schrijft en dat productietoegang per package wordt aangevraagd, en niet op een gepubliceerde zin die overdracht uitsluit; ga uit van een nieuwe test per game, en kijk in je Console-dashboard bij de specifieke app voordat je van het een of het ander uitgaat.

Wat de regel werkelijk telt

Heb je gelezen dat het getal 20 is, dan is die pagina verouderd. Google legde de drempel oorspronkelijk op 20 testers en verlaagde die op 11 december 2024 naar 12, in eigen woorden omschreven als een eis van “12 in plaats van 20 testers”, terwijl de periode van twee weken intact bleef. De geschiedenis staat uitgebreid beschreven in het artikel over de wijziging van 20 naar 12 testers, en de werking van de vereiste zelf in het artikel over de eis van 12 testers. Dit artikel gaat van allebei uit en blijft bij wat er anders is aan een game.

Welke gameontwikkelaars hebben echt 12 testers nodig?

Nog één stuk algemene context over het account, want het komt in dezelfde adem ter sprake en wordt vaak verward met de kosten van testen: Google rekent eenmalige registratiekosten van $ 25 om een ontwikkelaarsaccount te openen. Die kosten staan los van de testvereiste. Een gesloten test uitvoeren kost in Play Console niets; wat het kost, is twaalf mensen vinden die blijven.

En dat is voor een game het echte probleem. Vergeleken met een hulpapp heeft een game meestal diepere sessies nodig voordat de gebreken überhaupt zichtbaar worden: voortgang en opgeslagen status, asset delivery, thermisch gedrag en monetisatie gaan zich pas misdragen zodra iemand ver genoeg heeft gespeeld om iets te verliezen te hebben. Geen van beide categorieën wordt veilig getest door mensen die een build installeren en hem twee weken met rust laten, en Google weegt betrokkenheid en feedback bij apps en games even zwaar mee. Bij een game maakt de oppervlakkige versie van die fout alleen meer stuk, want je hebt mensen nodig die echt spelen, op hardware die lijkt op die van een speler, en lang genoeg om het tweede bedrijf te halen. Over dat gat gaat de rest van dit artikel.

Hoe werkt de gesloten test van 14 dagen voor een game?

Bron: de testvereiste voor nieuwe persoonlijke accounts (answer 14151465). Het minimum van 12 testers verving 20 op 11 december 2024; de doorlopende periode van 14 dagen bleef ongewijzigd.

1. 01
   Vóór dag één

   Publiceer de release voor de gesloten test en stel hem beschikbaar aan je testers. Controleer of de build zoals Play die aflevert installeert en draait, of assetpacks binnenkomen, of het inloggen bij Play Games werkt en of alles wat de test moet bereiken ook bereikbaar is. Een build die vanaf jouw machine werkt, zegt niets over de build die Play samenstelt.

2. 02
   Aanmelden

   Elke tester moet de uitnodiging accepteren en niet alleen op een lijst staan. Hier gaat het voortdurend mis: iemand toevoegen aan een mailinglijst of een Google Groep is jouw handeling, aanmelden is die van hen. Tel alleen accounts die dat hebben afgerond.

3. 03
   Dag één tot en met veertien

   Minstens 12 testers blijven doorlopend aangemeld terwijl ze spelen. Werf boven het minimum, zodat één afmelding je niet tekort kan laten komen. Google vraagt bij je aanvraag naar betrokkenheid en feedback, dus de nuttige opbrengst van deze twee weken is een lijst met dingen die mensen je hebben verteld, niet een screenshot van een teller.

4. 04
   Tijdens de test

   Los echte defecten op en blijf de build bijwerken. Nieuwe releases uploaden binnen dit venster is normaal en zet niets terug op nul: de kwalificerende voorwaarde is geschreven tegen de aanmeldgeschiedenis van testers, niet tegen de leeftijd van één bevroren build. Dat volgt uit de formulering van Google over doorlopende aanmelding per tester; Google publiceert verder geen aparte regel over build-updates, in welke richting dan ook. Loop de installatie- en updatepaden af, voortgang en saves, het downloaden van assets, crashes, prestaties, aankopen en Play Games, precies zoals jouw game die gebruikt.

5. 05
   Na het kwalificerende venster

   Ga naar Dashboard > Apply for production en geef eerlijk antwoord over wie er heeft getest, hoe betrokken die testers waren, wat ze zeiden, wat jij hebt veranderd en waarom de game klaar is.

6. 06
   Beoordeling

   Google zegt dat dit meestal 7 dagen of minder duurt en soms langer kan duren. Het is geen serviceafspraak en niemand kan je een datum beloven.

Eén correctie die je beter vroeg kunt maken, omdat ze mensen twee weken kost. De interne test is een andere track met een veel hoger plafond: tot 100 testers, en snel beschikbaar. Die is echt nuttig om een build snel voor mensen te krijgen. Hij vervangt de gesloten test die in de voorwaarde staat niet. De verschillen tussen de drie tracks staan in het artikel over interne, gesloten en open test, en de open test komt pas beschikbaar zodra je productietoegang hebt.

Moeten testers de game elke dag spelen?

Hier gaat vrijwel elk antwoord uit de community de mist in, dus houden we de drie categorieën netjes uit elkaar.

Google vereist doorlopende aanmelding en zegt dat betrokkenheid meetelt bij de beoordeling van je aanvraag. Google publiceert geen quotum voor dagelijks openen, geen aantal minuten per sessie en geen aantal updates. Behandel de rechterkolom voor wat die is: adviezen die tot folklore verhardden omdat ze met veel overtuiging zijn herhaald. Mik op echt testen, dan voldoe je aan de middelste kolom zonder de derde nodig te hebben.

Begint de twee weken opnieuw als één tester afhaakt?

Niet vanzelf, en dit is de meest overdreven regel die in omloop is. De voorwaarde van Google wordt gemeten op het moment dat je de aanvraag indient: minstens 12 testers die elk de voorgaande 14 dagen doorlopend aangemeld zijn geweest. Het is geen eis dat één onaangeroerde groep van precies twaalf de twee weken ongewijzigd doorstaat.

De rekensom werkt dus per tester, niet per groep. Begin je met precies 12 en verlies je er één op dag negen, dan kom je tekort: je hebt nu elf accounts die het volle venster kunnen aantonen, en de twaalfde vervanger moet eerst zijn eigen 14 doorlopende dagen volmaken voordat je de aanvraag kunt indienen. Begin je met vijftien en verlies je er één, dan kunnen de overgebleven veertien elk nog steeds aan de voorwaarde voldoen, en verlies je alleen wat marge. Dat is het hele argument om boven het minimum te werven in plaats van er precies op.

Hoe we dit weten Deze lezing volgt uit de formulering van Google zelf over doorlopende aanmelding per tester, en daar is de vereiste tegen geschreven. Google publiceert geen aparte regel over het resetten van een groep die met zoveel woorden zegt dat het vertrek van één tester de periode van alle anderen intact laat, dus behandel dit als een zorgvuldige lezing van de gepubliceerde voorwaarde en niet als een zin die je een beoordelaar kunt voorhouden. Het praktische advies verandert er hoe dan ook niet door: werf boven 12 zodat de vraag nooit beantwoord hoeft te worden.

Wat gebeurt er na dag 14?

Jij dient de aanvraag in en Google leest de antwoorden. De aanvraag voor productietoegang vraagt hoe testers met de game omgingen, welke feedback ze gaven, wat jij daardoor hebt veranderd en waarom je hem klaar vindt. Voor een game komt daar een categoriespecifieke vraag bij: beschrijf wat hem laat opvallen. Ook die vraag is geen formaliteit: daar begint een game die functioneel in orde is maar niets over zichzelf te melden heeft, eruit te zien als een game die niemand serieus heeft getest.

Wat mist een algemene apptest bij een game?

Hieronder staat de kaart van de rest van dit artikel. De rechterkolom is het deel dat mensen in beide richtingen verkeerd inschatten: sommige punten zijn vereisten van Google met gevolgen, andere zijn gewone kwaliteitspraktijk die in geen enkel beleid staat. Een praktijk voor een regel aanzien kost je die twee weken, en een regel voor een praktijk aanzien kost je de release.

Let op wat er niet in die tabel staat: een verplicht aantal apparaten, een verplichte sessieduur, een verplichte framerate of een minimumaantal levels. Die worden voortdurend beweerd en geen ervan is gepubliceerd. Wat Google wél publiceert, zijn limieten, drempels, mechanismen en beleidsregels, en die zijn allemaal te testen in dezelfde twee weken die je toch al aan de teller besteedt.

Hoe groot mag je game op Google Play zijn?

Dit is het feit dat in wat je hiervoor las het vaakst niet klopt. Het getal van 200 MB dat nog steeds rondgaat, was jaren geleden de basislimiet, en een paar oudere Android-gamepagina’s van Google zelf lopen achter op de pagina in Play Console Help die de echte uploads bepaalt. Spreken twee pagina’s van Google elkaar tegen, dan is de aparte pagina over omvanglimieten in Play Console Help de specifieke en actuele bron voor wat de Console accepteert. Controleer die opnieuw voordat je een release om een van de getallen hieronder heen plant.

De volledige limiettabel

Omvanglimieten van Google Play gecontroleerd op 12 augustus 2026. Alle waarden zijn gecomprimeerde downloadomvangen die Play Console berekent. Bronnen: maximumlimieten voor de omvang van een app (answer 9859372) en Play Asset Delivery.

Welke modus van Play Asset Delivery moet je game testen?

Play Asset Delivery heeft drie modi, en elke modus gaat op een andere plek stuk. De modus die je in de build hebt gekozen bepaalt welke testcases ertoe doen, dus loop deze tabel langs en test alleen de rijen die je game echt gebruikt.

Welke cijfers over framerate en crashes publiceert Google eigenlijk?

Dat onderscheid doet ertoe, want het gaat standaard verloren. De drempels van vitals beschrijven technische kwaliteit, en Google heeft laten weten dat Play gebruikers na verloop van tijd zal wegleiden van games die op hun telefoon geen 20 FPS halen. Dat is een mechanisme voor vindbaarheid en kwaliteit. Het is niet de beoordeling voor productietoegang, en geen enkele bron van Google maakt van een framerate een slaagcijfer voor de test van 14 dagen. Allebei kan tegelijk waar zijn: je game kan de testerdrempel halen en toch een game zijn die Play stilletjes niet meer aanbeveelt.

De cijfers, en wat elk van hen niet is

Native libraries en 64-bits

Games die op Unity, Unreal, Cocos of een andere engine met native plug-ins draaien, bevatten gecompileerde binaries, en die binaries hebben hun eigen compatibiliteitsregels, los van alles in dit artikel. Google Play vereist dat apps 64-bits architecturen ondersteunen: wordt er een native 32-bits architectuur ondersteund, dan moet de bijbehorende 64-bits architectuur er ook in zitten. Test in een 64-bits omgeving en ga er bij elke plug-in van derden van uit dat die een eigen incompatibele binary kan meebrengen, wat je engineversie ook beweert.

Loopt je build tijdens dit werk ook tegen de waarschuwing over de geheugenpaginagrootte van 16 KB aan, dan is dat een aparte vereiste met een eigen deadline en een eigen oplossingsroute, behandeld in de post over het oplossen van de 16 KB-paginagroottefout.

Hoe test je in-app-aankopen zonder testers te laten betalen?

“Gebruikers worden daadwerkelijk gefactureerd ... tenzij de gebruiker een licentietester is.”

Google Play Billing, documentatie over het testen van in-app-facturering

Twee aparte lijsten bepalen twee aparte dingen. De testerslijst van de gesloten track bepaalt wie de nog niet uitgebrachte build mag installeren. De lijst met licentietesters bepaalt wiens aankopen via de testbetaalmethoden van Google lopen in plaats van via een echte kaart. Een ontwikkelaar die twaalf mensen aan de eerste lijst toevoegt en niemand aan de tweede, heeft een test gebouwd waarin elke aankoop echt is, en degene die daar als eerste achter komt is meestal een tester die om zijn geld terug vraagt.

Tester op de gesloten track versus licentietester

De aankooptests die een game met verdienmodel hoort te draaien

Timing van de billing library: Play Billing Library 7 is op 31 augustus 2026 voorbij de deadline voor nieuwe apps en updates gegaan. Heb je uitstel, dan loopt dat tot 1 november 2026; anders hebben nieuwe releases een latere ondersteunde versie nodig. De nieuwste release zijn is niet hetzelfde als de minimaal toegestane versie zijn, dus mik op een ondersteunde en onderhouden versie in plaats van aan te nemen dat de nieuwste verplicht is. Bron: In-app-facturering testen, inclusief licentietesters.

Maken loot boxes van je game een gokapp?

De classificatievragenlijst is geen formaliteit

Elke game heeft juiste en volledige antwoorden op de classificatievragenlijst nodig, te bereiken via Policy > App content in Play Console, en die antwoorden moeten worden bijgewerkt zodra de content of de functies die ze beschrijven veranderen. Een verkeerde voorstelling van wat er in een game zit, kan leiden tot verwijdering of opschorting, en dat maakt een onjuiste vragenlijst een aanzienlijk duurdere fout dan een traag frame.

Games raken meer onderdelen van de vragenlijst dan apps: geweld, gesimuleerd gokken, aankopen in de game, communicatie tussen gebruikers, door gebruikers gemaakte content. Voegt je gesloten test in week twee een chatfunctie of een willekeurige beloning toe, dan kloppen de antwoorden uit week één niet meer. Open de vragenlijst opnieuw voordat je productietoegang aanvraagt, en niet pas nadat iemand het opmerkt.

Bron: het beleid van Google Play voor willekeurige virtuele items (answer 9858738), dat vereist dat de kansen vóór en dicht bij de aankoop bekend worden gemaakt.

Waarom mislukt inloggen met Play Games tijdens een gesloten test?

Het symptoom is kenmerkend en misleidend: inloggen werkt op je eigen machine, werkt bij jou op een apparaat, en mislukt daarna bij iedereen zodra de build via Play binnenkomt. Dat oogt als een kapotte release, waardoor ontwikkelaars iets gaan herbouwen dat nooit stuk was.

De instelling die het oplost

1. 01
   Open de testerlijst van Play Games Services

   In Play Console: Grow users > Play Games Services > Setup and management > Testers. Deze lijst staat los van je testerlijst voor de gesloten track en neemt daar niets van over.

2. 02
   Autoriseer testers of schakel de track in

   Voeg de accounts één voor één toe, of schakel de betreffende releasetrack in Play Console in voor het testen van Play Games Services, zodat iedereen met toegang tot de testbuild ook toegang tot Play Games krijgt. De tweede optie is de enige die verder schaalt dan een handjevol mensen.

3. 03
   Controleer of de gegevens overeenkomen met de build

   De authenticatie mislukt als de ingestelde package name of de vingerafdruk van het ondertekeningscertificaat niet overeenkomt met wat er is geüpload. Zodra Play App Signing in het spel is, heeft je configuratie van Play Games de vingerafdruk nodig die Play gebruikt, niet die op je eigen werkstation.

4. 04
   Test elke functie die je echt hebt ingeschakeld

   Eerst het inloggen, daarna prestaties, klassementen en opgeslagen games, voor zover je game die gebruikt. Opgeslagen games verdienen extra aandacht omdat ze samenhangen met voortgang: een save die niet wordt hersteld, is een bug die je testers alleen vinden als ze ver genoeg komen om voortgang te hebben die het herstellen waard is.

Vier systemen, vier lijsten, één game. Deze sectie bestaat alleen maar omdat drie van die vier onzichtbaar zijn vanuit het scherm van de gesloten track, waardoor een ontwikkelaar die de enige zichtbare lijst correct heeft ingesteld redelijkerwijs aanneemt dat de rest vanzelf volgt. Dat is niet zo.

Bron: Play Games Services console setup and tester authorization, waarin de testerlijst, het alternatief met een ingeschakelde track en de OAuth- en 404-fouten die een niet-geautoriseerde tester ziet worden beschreven.

Kun je pre-registratie gebruiken terwijl je game in een gesloten test zit?

Dit doet bij games meer pijn dan bij apps, want pre-registratie is een lanceringsinstrument en een gamelancering wordt meestal vanaf een datum terug gepland. Ging je plan uit van een pre-registratiecampagne naast de gesloten test, dan moet dat plan op de schop: eerst aan de voorwaarde voldoen, dan de campagne draaien, dan lanceren.

De praktische volgorde voor een eerste game: begin de gesloten test zodra de build speelbaar is in plaats van te wachten tot hij af voelt, want die twee weken lopen parallel aan werk dat je toch al doet. Marketing die afhangt van functies in de store komt daarna, niet ertussendoor.

Bron: de vereiste van een gesloten test voor nieuwe persoonlijke accounts (answer 14151465), waar Google stelt dat productietoegang en pre-registratie beperkt blijven tot aan de vereiste is voldaan.

Wat moeten je testers eigenlijk met de game doen?

Waarom vraagt Google om nog eens 14 dagen nadat je de 12 hebt gehaald?

Ontwikkelaars melden deze uitkomst regelmatig: de aantallen klopten, de aanvraag ging de deur uit, en het antwoord luidde meer testen. Gemeld in de community De threads zijn eensgezind over de ervaring en veel minder betrouwbaar over de oorzaak, want niemand buiten Google ziet de redenering. Wat je op basis van de documentatie van Google zelf kunt zeggen, is dat betrokkenheid en feedback meewegen in de beoordeling, en daar kun je mee werken.

Hoe een tweede ronde eruit hoort te zien

Word je om meer testen gevraagd, dan is de verleiding groot om de eerste ronde met hetzelfde passieve installatiepatroon te herhalen en op een ander antwoord te hopen. Een nuttiger tweede ronde verandert iets echts: houd de groep stabiel, geef testers een concrete route door de game, leg schriftelijk vast wat ze melden, breng de fixes uit waar de feedback aanleiding toe gaf, en beschrijf dat allemaal helder als je opnieuw aanvraagt. Dat is, niet toevallig, ook wat een betere game oplevert.

Wat er niet in hoort, is een verzonnen ritueel. Er bestaat geen gepubliceerd aantal starts, geen verplicht aantal updates en geen quotum voor dagelijks spelen dat een afwijzing in een goedkeuring verandert, en niemand kan je beloven dat een bepaald activiteitspatroon de beslissing van Google verandert. Meer over afwijzingspatronen in het algemeen staat in het artikel over waarom gesloten testen wordt afgewezen.

Belangrijke deadlines van Google Play voor game-uitgevers in 2026 en begin 2027

Bronnen: vereisten voor het doel-API-niveau (answer 11926878) voor de targetingdata van 31 augustus en de niveaus per apparaatvorm, en de twee beleidsplekken van Google voor de rest: de deadlinetabel in Play Console Help en de beleidstijdlijn van Android Developers.

Het is de moeite waard dit ronduit te zeggen, want juist de volgorde laat mensen struikelen: geen van deze data heeft iets met de testvereiste te maken, en de testvereiste halen ontslaat je van geen enkele ervan. Een game kan een vlekkeloze gesloten test van 14 dagen afronden en alsnog niet kunnen uitbrengen omdat de build het verkeerde API-niveau als doel heeft. Controleer de vereisten die een release blokkeren vóórdat je aan die twee weken begint, niet erna.

Waar vind je 12 echte testers voor een game?

Dat de communities rond game-engines vol staan met berichten van “ik heb 12 testers nodig”, is simpele rekenkunde: iemand die voor het eerst een game maakt, kent meestal geen twaalf mensen die een Android-telefoon hebben, een aanmelding afronden én twee weken later nog steeds aangemeld zijn. Vrienden installeren hem, spelen één keer uit beleefdheid en haken af. Daar is niets zwaks aan. Een gunst heeft nu eenmaal een halfwaardetijd van ongeveer drie dagen, en de eis loopt veertien dagen.

Ruilgroepen voor testers lossen het aantal op en vaak niet veel meer, want een ruilpartner heeft precies dezelfde drijfveer als jij: aanmelden, aangemeld blijven en door naar de volgende. Dat voldoet aan de teller en levert precies het patroon van passieve betrokkenheid op waar Google in het aanvraagformulier naar vraagt. Voor een game is dat erger dan voor een app, want de fouten die ertoe doen zitten een paar sessies diep, en een ruiltester komt daar nooit.

Wat een beheerde run dekt

PrimeTestLab levert 12 echte testers op echte apparaten van Android 7 tot 17, aangemeld en de volle 14 dagen vastgehouden, waarbij het testen binnen 4-6 uur begint. Wij hebben dit gedaan voor 7.400+ apps in 120+ landen met een slagingspercentage van 99,9%, en de run wordt gedekt door een gratis hertest of volledige terugbetaling. Pakketten beginnen bij $19.99.

Even eerlijk over de grens, want een game heeft onderdelen die niemand kan overnemen: een beheerde run neemt de testerskant van die twee weken voor zijn rekening. Hij bouwt je assetpacks niet opnieuw, stemt je frametijden niet af, implementeert geen acknowledgment in je factureringscode en vult je classificatievragenlijst niet in. Dat blijft jouw werk, en de secties hierboven bestaan om het korter te maken. Wat verdwijnt, is het gehaaste werven en het risico dat de groep op dag negen instort.

Zelf werven versus een beheerde run

Eén ding kan geen enkele dienst bieden, en wees wantrouwig bij iedereen die het wel belooft: productietoegang zelf. Die beslissing ligt bij Google, dat naast het aantal ook de kwaliteit van je testen weegt en om nog een ronde kan vragen. Wat wél beloofd kan worden, is de groep, de twee weken en de garantie daarachter. Bekijk de pakketten en wat er in elk pakket zit →

Veelgestelde vragen

Kort samengevat