De interne test van Google Play instellen (2026)

De interne test is de enige track in de Play Console die zich gedraagt zoals ontwikkelaars van software verwachten: je uploadt een build, hij verschijnt, mensen installeren hem. Tot het opeens niet meer werkt. Dan staar je naar een link die een pagina in de Play Store opent met de mededeling dat de app niet beschikbaar is voor je account, zonder foutcode, zonder diagnose, en met een Help-artikel dat drie testtracks over honderden regels door elkaar husselt. Dit artikel scheidt de interne track van de andere twee, geeft je het pad in de console en de regels voor testerslijsten in de volgorde waarin je ze echt nodig hebt, en neemt daarna ruim de tijd voor de storingsfamilie die de supportthreads vult. Waar de eigen pagina's van Google elkaar tegenspreken, en over timing doen ze dat duidelijk, staan beide lezingen erbij in plaats van alleen de gemakkelijkste. Alles hier is actueel op 12 augustus 2026.

Hoe stel je de interne test in?

Voordat je begint

Zorg voor de app, de build, de accounts van je testers en je eigen toegang tot de Play Console. Let op wat er niet nodig is: een afgeronde storevermelding, screenshots, een contentbeoordeling of een ingevuld formulier over gegevensveiligheid. Google staat uitdrukkelijk toe dat een interne test draait voordat de app volledig is ingericht. Geverifieerd

• 01
  Een app die in de Play Console bestaat Aangemaakt, niet per se ingevuld. Het eerste artefact dat je uploadt legt de packagenaam voor die app vast en die kan daarna niet meer worden gewijzigd, dus zorg dat de applicationId degene is die je wilt houden.
• 02
  Een geldige app bundle Google spreekt van een "geldige app bundle". Dat is de enige eis aan het artefact om een vroege interne build in handen van testers te krijgen.
• 03
  E-mailadressen van testers Google-accounts. De huidige Help noemt een Google-account met Gmail, of een Google Workspace-account. Verzamel precies het adres waarmee elke persoon ingelogd zal zijn, want dat is de identiteit waaraan de hele track is opgehangen.
• 04
  De toegang in de Play Console om het te doen Eigenaren en beheerders hebben die al. Een gedelegeerde gebruiker heeft het recht nodig om apps naar testtracks te publiceren, en het beheren van de track en de bijbehorende testerslijsten kan het aparte recht vereisen om testtracks te beheren en testerslijsten te bewerken. Een ontbrekende of grijze releaseknop is een toegangsprobleem en geen buildprobleem.
• 05
  Play App Signing, alleen bij de eerste release Bij de eerste release van een app loodst de Play Console je door het instellen van Play App Signing. Het is een eenmalige stap die je tijdens het uploaden tegenkomt en niet iets wat je vooraf regelt, maar het is goed om te weten dat hij eraan komt voordat je begint.

Stap 1: open de interne testtrack

Selecteer je app en ga daarna naar Test and release › Testing › Internal testing. Google documenteert dit pad op twee manieren. Het Help-artikel van de Play Console over het instellen van een test kort het af tot Testing › Internal testing, terwijl een andere actuele Help-pagina het volledige bovenliggende menu toont. Beide beschrijven dezelfde bestemming, dus toont jouw console een korter menu dan hier staat, dan zit je niet verkeerd.

Stap 2: maak je lijst met interne testers

Open het tabblad Testers op de interne testtrack en kies Create email list (Mailinglijst maken). Geef de lijst een naam, voeg de adressen toe, sla de wijzigingen op en maak de lijst aan. Je kunt adressen rechtstreeks in de interface typen, gescheiden door komma's, of ze uploaden als CSV. Juist bij die CSV-route sneuvelen lijsten stilletjes, want daar horen drie regels bij die één keer zijn gedocumenteerd en daarna nooit meer herhaald.

Linter voor testerslijsten

Stap 3: koppel de lijst en een feedbackkanaal

Selecteer terug op het tabblad Testers de gebruikerslijst of lijsten die je voor deze track wilt gebruiken en geef Google daarna een feedback-URL of e-mailadres. Dat adres krijgen testers te zien op de aanmeldingspagina, waarmee het de enige ingebouwde route is om je te laten weten dat er iets stuk is.

Stap 4: maak de release en rol hem uit

Kies Create new release, voeg je app bundle toe, controleer hem en rol hem uit met de huidige knoppen van de console. Varianten van de Play Console verschillen genoeg in hun exacte knopteksten dat een klikvolgorde verder uit je hoofd leren eerder een risico dan een hulp is, dus de instructie stopt waar de huidige documentatie van Google stopt.

Stap 5: kopieer de aanmeldingslink en deel hem

Kopieer de deelbare testerslink en stuur hem rond. Dit is de stap die ontwikkelaars sinds minstens 2018 in verwarring brengt, en die verwarring is volkomen terecht: elk ander uitnodigingssysteem op internet stuurt een e-mail, en de gedocumenteerde werkwijze van Google geeft je in plaats daarvan een link om te verspreiden. Reken er niet op dat de Play Console je testers uitnodigt.

Twee voorwaarden bepalen of die link überhaupt al bestaat. De aanmeldingslink wordt alleen getoond wanneer de status van de app Published is. Zolang de app op Draft of Pending publication staat, valt er niets te kopiëren, en het tabblad Testers nog eens doorlezen levert er geen op. Geverifieerd

Stap 6: elke tester meldt zich aan en installeert

De laatste stap is aan de tester, en die kun jij niet voor hem doen. Elke tester opent jouw link met precies het account dat je hebt toegevoegd, rondt de aanmelding op die pagina af en volgt daarna de link naar de Play Store om te installeren. Tot dat gebeurt komen ze wel in aanmerking maar zijn ze niet ingeschreven, en testers die alleen in aanmerking komen ontvangen niets. Stuur de link met de naam van het uitgenodigde account ernaast, want aanmelden met de verkeerde identiteit is een van de meest gemelde storingen in dit proces en het lijkt precies op een kapotte link.

Wie doet wat

De hele volgorde, in één tabel

Scroll de tabel opzij om alle kolommen te zien

Hoe lang duurt het voordat testers kunnen installeren?

Tijdens een interne test lopen vijf verschillende klokken, en klachten over timing komen meestal voort uit het vergelijken van de verkeerde twee. De build die het distributiesysteem van Google bereikt is één ding. De aanmeldingslink die voor testers live gaat is een tweede. Een gepubliceerde wijziging die mensen bereikt die al meedoen is een derde. Een geïnstalleerde app die automatisch bijwerkt is een vierde. En de tijdelijke storevermelding die wordt vervangen door je echte appnaam is een vijfde, en daarom kan een perfect werkende interne build er een paar dagen onaf uitzien.

Is mijn wachttijd nog normaal?

De enige nuttige versie van die vraag bevat ook waarop je wacht, want het antwoord verschilt per fase met een factor honderd. De tool hieronder vraagt naar allebei, citeert wat Google voor die fase publiceert en benoemt de eigen numerieke ijkpunten als de lezing van dit artikel en niet als die van Google.

Doorvoerklok

Alle klokken naast elkaar

Scroll de tabel opzij om alle kolommen te zien

Het redactionele punt om mee te nemen: seconden, minuten, een paar uur en tot 48 uur zijn tegelijk allemaal waar, omdat ze verschillende stukken van dezelfde keten beschrijven. Elk artikel dat ze platslaat tot één getal, zet iemand op het verkeerde been op precies het moment dat die nauwkeurigheid nodig heeft. Geverifieerd

Wacht een interne release op een beoordeling door Google?

Een zorgvuldige formulering is hier belangrijk, want de twee bronnen van Google zeggen het niet op dezelfde manier. De productpagina van Google over de interne test presenteert die als een manier om builds te distribueren zonder te hoeven wachten op beoordelingen van apps. Het Helpcentrum van de Play Console is voorzichtiger en zegt dat interne tests mogelijk niet onderworpen zijn aan de gebruikelijke beleids- en beveiligingsbeoordelingen van Play.

De accurate uitspraak is dus dat je met de interne test normaal gesproken kunt distribueren zonder te wachten op het standaardproces van app-beoordeling, en de onnauwkeurige uitspraak is dat interne releases nooit worden beoordeeld. Google heeft geen categorische vrijstelling van elke beoordeling beloofd, en schrijven dat dat wel zo is, is hoe een artikel fout wordt op het eerste moment dat iemands interne release wordt tegengehouden. Geverifieerd, met een voorbehoud bij de formulering

Telt de interne test mee voor de 12 testers?

Dit is het meest ingrijpende misverstand in het hele onderwerp, en het wordt actief verspreid. Minstens één breed gedeeld artikel uit 2026 beschrijft de verplichte eis als iets waaraan je op de interne testtrack voldoet. De eigen eisenpagina van Google zegt iets anders, in bewoordingen die geen ruimte voor interpretatie laten.

De beslisregel, in één zin

Gebruik de interne test voor snelle private QA met mensen die je vertrouwt. Gebruik de gesloten test wanneer je de verplichte test vóór productie nodig hebt. Dat is de hele regel, en het is bewust alles wat dit artikel over de vergelijking zegt: de volledige uitsplitsing van de drie tracks staat in interne, gesloten en open test vergeleken, dat voor die vraag is gemaakt.

Scroll de tabel opzij om alle kolommen te zien

Voor wie de eis werkelijk geldt

De eis heeft een afgebakende reikwijdte, en juist in die afbakening zit de meeste verwarring. De pagina van Google documenteert de eis voor kwalificerende persoonlijke ontwikkelaarsaccounts die na 13 november 2023 zijn gemaakt. Google kondigde het beleid aan op 9 november 2023, en daarom zie je beide data als startpunt genoemd worden.

Wees voorzichtig met hoe je het formuleert voor organisatorische accounts. De eisenpagina van Google beperkt de regel tot persoonlijke accounts; er staat geen zin op die organisatorische accounts vrijstelt. De verdedigbare formulering is dat de eis is gedocumenteerd voor kwalificerende persoonlijke ontwikkelaarsaccounts en dat de aangehaalde pagina die niet oplegt aan organisatorische accounts. Reikwijdte afgeleid

14 dagen aangemeld is niet hetzelfde als 14 dagen gebruikt

De numerieke drempel is geformuleerd in termen van testers die doorlopend aangemeld zijn, niet in termen van dagelijks gebruik. Dat is het meetbare deel. Los daarvan beoordeelt Google wat je over je test rapporteert wanneer je productietoegang aanvraagt, en kan het meer testen vereisen als het aantal testers of de betrokkenheid onvoldoende is. Concurrerende pagina's gooien die twee dingen routineus op één hoop in een verzonnen regel over minuten dagelijks gebruik.

Dus: de drempel is doorlopende aanmelding, en betrokkenheid wordt daar bovenop beoordeeld en niet in plaats daarvan. Wat dat in de praktijk betekent voor een lopende test, staat in de regel van 14 doorlopende dagen en de eis van 12 testers uitgelegd. Geverifieerd

Waarom werkt mijn link voor de interne test niet?

Dit is de storing die de communitythreads over de interne test vult, en de slechtst gedocumenteerde. Ontwikkelaars komen hier terecht nadat ze alles hebben gedaan wat de Play Console vroeg, en juist daarom is de ervaring zo ontregelend: er is geen foutcode, geen diagnose, en de pagina meldt vrolijk dat de app niet beschikbaar is voor je account, alsof het account het probleem is in plaats van een symptoom. De meldingen lopen van een vraag op Stack Overflow uit 2018 tot threads in de Google Developer Community van juli 2026, in het Engels en het Portugees, die telkens hetzelfde handjevol oorzaken beschrijven.

De nuttige zet is om te stoppen met denken in een kapotte link en te gaan denken in een stroomkring. De leveringsregel van Google is een reeks voorwaarden, en één open contact legt alles verderop stil. Vier toestanden dekken de oorzaken die in die meldingen blijven terugkomen: niet op de testerslijst, op de lijst maar niet aangemeld, aangemeld maar met het verkeerde Google-account, en correct geconfigureerd en nog aan het doorvoeren. Die laatste is helemaal geen storing, en juist daaraan gaat de meeste tijd verloren.

Vind de open poort

Zet elke schakelaar hieronder op wat je echt hebt bevestigd, niet op wat je aanneemt. De poorten staan op volgorde van hoe goedkoop je ze kunt controleren, dus de eerste die nog openstaat is wat je als volgende wilt oplossen.

Simulator voor toegangspoorten

“Deze app is niet beschikbaar voor je account”

Toegang van een tester hangt aan een identiteit, niet aan een apparaat of een link. Google vereist dat het account is opgenomen in de beheerde testerconfiguratie en zich heeft aangemeld voor dat testprogramma. Ontbreekt een van beide helften, dan kan de Play Store die persoon op geen enkele manier onderscheiden van een onbekende die je URL heeft gevonden.

De reden dat dit in de praktijk zo vaak opduikt, is doodgewoon: op telefoons en in browsers zijn vaak meerdere Google-accounts ingelogd, en het account dat een link opent is niet altijd het account dat je hebt uitgenodigd. Threads in de Google Developer Community uit maart 2026 beschrijven testers die helemaal niet naar de bedoelde identiteit kunnen overschakelen omdat de accountkiezer zich anders gedraagt dan ze verwachten, en Portugeestalige threads uit medio 2025 melden hetzelfde patroon met een antwoord dat rechtstreeks wijst op het afstemmen van het account dat in Google Play is geselecteerd. Gemeld door de community

Er is geen aanmeldingslink om te kopiëren

Controleer eerst de status van de app. Google toont de aanmeldingslink alleen wanneer de status van de app Published is. Bij Draft of Pending publication is de link niet verborgen of vertraagd, hij bestaat gewoon nog niet. Dit is de schoonste oplossing uit de hele lijst met storingen, want de voorwaarde is binair en zichtbaar in je eigen console. Geverifieerd

Hij is gepubliceerd, maar niemand kan hem vinden in de Play-zoekfunctie

Dat is verwacht gedrag en geen fout. Google stelt dat een interne of gesloten test die voorafgaat aan de open test of aan productie niet vindbaar is via de zoekfunctie van de Play Store. Testers die de opdracht krijgen om "de app op Play te zoeken" komen er nooit uit, hoe correct je configuratie ook is, en melden dan begrijpelijkerwijs dat de app niet bestaat.

Stuur de directe link. Zeg er uitdrukkelijk bij dat zoeken niet werkt, want dat is het eerste wat iedereen probeert. Geverifieerd

Sommige testers zitten nog op de oude versie

Werk drie oorzaken in volgorde af. Ten eerste het doorvoeren: aanvullende gepubliceerde wijzigingen kunnen enkele uren nodig hebben om testers te bereiken, dus een recente update is misschien gewoon nog niet aangekomen. Ten tweede de version codes: een gebruiker krijgt de hoogste compatibele version code van elke track waarvoor die in aanmerking komt. Omdat elke gebruiker in aanmerking komt voor productie, kan een hogere version code uit productie worden geleverd in plaats van een lagere testversie, wat de verwarrende situatie oplevert waarin je nieuwste interne build echt bestaat, correct is, en toch niet is wat de tester heeft. Ten derde de vraag voor welke track iemand in aanmerking komt: een account dat is aangemeld voor de interne test komt niet in aanmerking voor gesloten of open builds, dus heb je het werk naar een andere track verplaatst, dan kijkt dat account naar de verkeerde. Geverifieerd

Alles klopt en het gaat nog steeds mis

Nu, en pas nu, zijn de remedies uit de community het proberen waard: het apparaat opnieuw opstarten, de Play Store opnieuw starten, de cache of de gegevens van de Play Store wissen, of de link openen in een schoon browserprofiel. Die komen uit threads in de Google Developer Community en niet uit beleid van Google, en ze worden gemeld als dingen die bij iemand hebben gewerkt, niet als gedocumenteerd gedrag. Ze vooropstellen is hoe ontwikkelaars dagen verliezen, want ze verhelpen geen configuratieprobleem en ze maskeren een vertraging in het doorvoeren als een succes. Gemeld door de community

Er is ook een echt grensgeval. Een thread uit de community van februari 2026 beschrijft een link voor de interne test die nooit heeft gewerkt, en een thread uit mei 2026 meldt een HTTP 500 op de aanmeldingspagina. Voor geen van beide is een algemene grondoorzaak vastgesteld, en een technische verklaring verzinnen zou erger zijn dan dat toegeven. Is je configuratie aantoonbaar correct, zijn de doorvoervensters verstreken en blijft de storing bestaan of komt er een serverfout terug, dan is dat een redelijk moment om op te schalen via de support van de Play Console in plaats van instellingen te blijven veranderen. Oorzaak niet geverifieerd

Van symptoom naar oplossing, met bewijsgradaties

Scroll de tabel opzij om alle kolommen te zien

Limieten en regels die vaak fout gaan

Scroll de tabel opzij om alle kolommen te zien

Interne test versus internal app sharing

Dit zijn twee verschillende functies met namen die verwarrend veel op elkaar lijken, en de verkeerde kiezen kost je een middag. De interne test is de formele track die dit hele artikel beschrijft: een release, een beheerde lijst van maximaal 100 testers, aanmelding, en updates die via Google Play worden geleverd. Internal app sharing is een snelle deelfunctie die een geüploade APK of app bundle omzet in een downloadlink die je kunt rondsturen. Die heeft ook toegangsinstellingen, alleen andere: op de pagina van Google erover kun je downloads beperken tot mailinglijsten of de link openzetten voor iedereen naar wie je hem stuurt, en in beide gevallen moet de tester internal app sharing eerst inschakelen in zijn eigen Play Store-app.

De praktische regel: gebruik internal app sharing om binnen tien minuten een build naar een collega te schieten, en gebruik de interne testtrack wanneer je de versiegeschiedenis, de testerslijst en een build wilt die je later kunt doorzetten. Het verlopen na 60 dagen is het detail waar mensen op stuklopen, want een link die twee maanden geleden in een bugrapport werkte, is simpelweg dood en niet verkeerd geconfigureerd. Geen van beide functies telt mee voor de gesloten test met 12 testers. Geverifieerd

De valkuil van in-app-aankopen

Neem de veelgehoorde bewering dat tijdens de interne test alles gratis is niet over. De regel van Google scheidt de app van wat erin wordt verkocht. Een betaalde app zelf is gratis te installeren voor een interne tester. In-app-aankopen worden nog steeds in rekening gebracht, tenzij het account van die tester ook is ingesteld als licentietester.

Bij een test met abonnementen scheelt dit onderscheid echt geld, en minstens één artikel dat nu goed scoort in de vergelijkingen beweert botweg het tegendeel. Staan je testers op het punt een aankoopproces te doorlopen, stel dan eerst licentietesten in of reken op echte afschrijvingen. Geverifieerd

Twee dingen die niet jouw probleem zijn

Een groot deel van de algemene adviezen over de interne test die online rondgaan, laat je dingen repareren die de oorzaak niet kunnen zijn. Dat kost tijd en sloopt soms een werkende configuratie.

Beweringen gecontroleerd, met een oordeel

Elke rij hieronder is een uitspraak die je over de interne test tegenkomt. De oordeelkolom geeft weer wat de primaire bronnen ondersteunen, niet wat redelijk klinkt.

• Onwaar
  “De interne test telt als de test met 12 testers.” De eisenpagina van Google vraagt uitdrukkelijk om een gesloten test. Dit is de schadelijkste fout in dit onderwerp, omdat die mensen het volledige venster van 14 dagen kost.
• Verouderd
  “Je hebt nog steeds 20 testers nodig.” Historisch sinds 11 december 2024. Het huidige minimum is 12.
• Onwaar
  “Interne testers krijgen alle aankopen gratis.” Alleen de betaalde app zelf is gratis. In-app-aankopen worden in rekening gebracht, tenzij licentietesten is ingesteld.
• Onwaar
  “Zit je tester in het buitenland, voeg dan zijn land toe.” Google zondert de interne test uitdrukkelijk uit van die distributiebeperking.
• Misleidend
  “Je link is stuk als die niet meteen werkt.” Google rekent zelf een paar uur voor een eerste link en enkele uren voor latere wijzigingen.
• Misleidend
  “Testers krijgen de aanmeldingslink automatisch per e-mail.” De gedocumenteerde werkwijze van Google is dat de ontwikkelaar de deelbare link kopieert en verspreidt. Reken er niet op dat de Play Console je testers uitnodigt.
• Gedeeltelijk
  “Je kunt een Google Groep gebruiken voor de interne test.” De huidige Help van de Console documenteert mailinglijsten voor de interne test en Google Groepen voor de gesloten test. De testers-resource van de publishing-API ondersteunt groepen breder, maar dat zegt niets over het gedrag van de Console in 2026 voor deze track. Gebruik de gedocumenteerde methode met een mailinglijst en reken niet op een groep.
• Gedeeltelijk
  “Google staat precies één interne track toe.” De publishing-API stelt de standaard interne track beschikbaar als één vast benoemde track, en de Help documenteert extra benoemde gesloten tracks zonder een aantal voor interne tracks te publiceren. Zeg dus "de standaard interne testtrack" in plaats van een harde limiet te beweren.
• Waar
  “Je kunt een interne test draaien voordat je storevermelding af is.” Google zegt dat een geldige app bundle genoeg is om intern te distribueren voordat de app volledig is ingericht.
• Waar
  “Feedback van testers uit een test schaadt mijn openbare beoordeling niet.” Google stelt dat feedback van testgebruikers geen invloed heeft op de openbare beoordeling van de app.

Een interne test beëindigen

Pauzeer de track. Testers houden de kopie die ze al hebben geïnstalleerd, maar ze krijgen er geen testupdates meer via. Dat is goed om te weten voordat je aanneemt dat het pauzeren van een track de app van iemands telefoon haalt, want dat gebeurt niet. Geverifieerd

Hoe verplaats je een build naar de gesloten test?

Dit is de stap waar de meeste mensen na een geslaagde interne test aankomen, en hier begint de klok voor productietoegang pas echt te lopen. De instructie hieronder vermijdt bewust een script van knop tot knop, omdat varianten van de Play Console verschillen en een uit het hoofd geleerd klikpad het eerste is dat stukgaat.

1. 01
   Open de doeltrack Ga naar Test and release › Testing › Closed testing en beheer de gesloten track die je wilt gebruiken.
2. 02
   Maak een release op die track Een gesloten release is een eigen release, ook al draagt die het artefact dat je al hebt getest.
3. 03
   Hergebruik het geteste artefact met Add from library Selecteer de versie die je tijdens de interne test hebt geüpload in plaats van de bundle opnieuw te uploaden. Dit is het deel dat wél is gedocumenteerd in de huidige release-Help van Google (answer 9859348). Geverifieerd
4. 04
   Stel de gesloten testers in Gebruik de eigen testerinstellingen van de gesloten track. Voor de gesloten test ondersteunt de huidige Help mailinglijsten of Google Groepen, en dat is een echt verschil met de interne track.
5. 05
   Controleer en rol uit Deel daarna de aanmeldingslink voor de gesloten test op dezelfde manier als de interne. Dezelfde twee voorwaarden gelden: op de lijst staan, en aangemeld zijn.

Kan ik dezelfde testers houden?

Ja als personen, nee als gelijktijdige aanmeldingen, en dat onderscheid sloopt in deze fase meer gesloten tests dan wat dan ook.

Een account dat is aangemeld voor de interne test komt niet in aanmerking voor builds uit de open of gesloten test. De instructie van Google is dat de tester zich eerst afmeldt voor de interne test en zich daarna aanmeldt voor de gesloten test. Je zorgvuldig samengestelde interne QA-groep kan dus prima je groep voor de gesloten test worden, maar iedereen moet de interne track eerst actief verlaten voordat die iets op de gesloten track kan zien.

Scroll de tabel opzij om alle kolommen te zien

Vanaf hier gaat het over iets heel anders: mensen werven die 14 dagen doorlopend aangemeld blijven, ze goed geteld krijgen en de vragenlijst voor productietoegang doorstaan. Dat komt aan bod in testers uitnodigen voor de gesloten test, waarom de Play Console 0 aangemelde testers toont en de vragenlijst voor productietoegang.

Waar PrimeTestLab past

Het is de moeite waard om die overdracht precies te benoemen, want de twee tracks falen om totaal verschillende redenen. De interne test faalt op configuratie: een link die er nog niet was, een account dat zich nooit heeft aangemeld, een doorvoervenster dat iemand niet heeft uitgezeten. Dat los je op door zorgvuldig te lezen, en daar zijn de eerste twee derde van dit artikel voor.

De gesloten test faalt op mensen. De gepubliceerde numerieke voorwaarde van Google is minimaal 12 testers die de afgelopen 14 dagen doorlopend aangemeld zijn voor de gesloten test, wat in de praktijk twaalf mensen betekent die meedoen en er in week twee nog steeds zijn. Los van dat aantal wil je dat die testers de build installeren en zinvol gebruiken, want Google vraagt bij de beoordeling van de aanvraag voor productietoegang naar betrokkenheid, functiegebruik en feedback. Geen van beide helften is een documentatieprobleem, en met kennis van de Play Console alleen los je ze niet op. De meeste ontwikkelaars ontdekken dit precies op het moment dat ze de interne test afronden en beseffen dat de eis geen millimeter is opgeschoven.

De gesloten test zelf doen, of uitbesteden

Scroll de tabel opzij om alle kolommen te zien

Ja, 25 testers kosten op dit moment minder dan 20. Dat is een actie en geen typefout: Enterprise heeft nu de diepste korting van de drie pakketten, waardoor die ook de laagste prijs per tester heeft, ongeveer $1.12 tegenover $1.50 bij Professional. Beide pakketten draaien dezelfde gesloten test; de actie is de enige reden dat de volgorde omkeert, en de prijzenpagina geeft het actuele bedrag als het sinds dit schrijven is veranderd.

Bij 7.400+ apps in 120+ landen halen we een slagingspercentage van 99,9% op de eis van de gesloten test. Wat we je niet zullen vertellen, is dat goedkeuring gegarandeerd is. Google beoordeelt de aanvraag voor productietoegang op eigen voorwaarden en kan om meer testen vragen, en wie je een bepaalde uitkomst belooft, beschrijft iets waar diegene geen controle over heeft. Wat we wél toezeggen, is het deel dat we zelf in de hand hebben: slaagt de test niet, dan krijg je een gratis hertest of een volledige terugbetaling.

Veelgestelde vragen over de interne test

Kort samengevat