Internal Testing: essentie, hoe het werkt en hoe je de track instelt

Wat is Internal Testing?

Internal Testing is een testtrack in Google Play Console en TestFlight voor het verspreiden van builds onder leden van het ontwikkelingsteam. In tegenstelling tot open bètatesten is toegang tot Internal Testing beperkt tot een lijst met e-mailadressen die zijn goedgekeurd door de eigenaar van het ontwikkelaarsaccount.

Het belangrijkste voordeel is de minimale levertijd van de build aan testers. In Google Play vereist Internal Testing geen moderatie — de build verschijnt bij deelnemers binnen 5–15 minuten na upload. In de App Store via TestFlight wordt de build ook geleverd zonder voorafgaande App Review, maar wordt automatisch gecontroleerd op basisveiligheidseisen.

Hoe Internal Testing verschilt van andere tracks

In Google Play zijn er drie testtracks: Internal Testing, Closed Beta (Open Beta) en Production. Internal Testing is de snelste en meest beperkte qua aantal deelnemers (tot 100 personen). Closed Beta staat tot 10 000 deelnemers toe en vereist het instellen van een testpagina. Production is de eindfase met volledige moderatie.

Wanneer Internal Testing gebruiken

Internal Testing wordt gebruikt voor primaire controle van builds voordat ze naar beta-tracks worden doorgestuurd. Ontwikkelaars uploaden dagelijkse builds voor het QA-team, controleren de integratie van nieuwe SDK's, testen compatibiliteit met verschillende OS-versies en identificeren regressiefouten voordat externe testers de build zien.

Internal Testing in Google Play

In Google Play Console is Internal Testing een aparte track, beschikbaar in de sectie Release → Testing. Om een tester toe te voegen, volstaat het om zijn e-mailadres in te voeren — de deelnemer ontvangt een uitnodiging en een link om deel te nemen via Google Play. Builds worden geüpload via dezelfde interface als productiereleases.

Publicatieproces in de Interne track

De ontwikkelaar uploadt een App Bundle of APK naar de sectie Internal Testing van Google Play Console. Het systeem controleert basisvereisten: handtekening, codeversie en API-compatibiliteit. Na 5–15 minuten verwerking is de build beschikbaar voor testers. De status is te volgen in de console: Draft, In Review, Ready to Test.

// Fastlane — publicatie in Internal Testing track
lane :internal_testing do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "internal",
        release_status: "completed",
        rollout: 1.0
    )
    
    slack(
        message: "Build uploaded to Internal Testing"
    )
end

Testers beheren

Het toevoegen van deelnemers gebeurt via de sectie Testers in Google Play Console. Groepsupload via CSV-bestand is beschikbaar. Elke tester ontvangt een e-mail met een uitnodiging en installatie-instructies. Om de toegang in te trekken, volstaat het om de deelnemer uit de groep te verwijderen — de geïnstalleerde app blijft werken, maar ontvangt geen nieuwe updates meer.

Internal Testing in App Store via TestFlight

In het Apple-ecosysteem vervult TestFlight de rol van Internal Testing — een platform voor het verspreiden van bètaversies. TestFlight ondersteunt tot 100 interne testers, die via e-mail worden toegevoegd in App Store Connect. Voor het publiceren van een build is geen volledige App Review vereist, maar de build wordt automatisch gecontroleerd op minimale vereisten.

Kenmerken van TestFlight Internal Testing

In tegenstelling tot Google Play waar Internal Testing helemaal geen moderatie vereist, voert Apple een automatische Basic Review uit. De controle duurt 30–60 minuten en omvat het scannen van de binaire code op kwaadaardige API's en naleving van basisvereisten. Na succesvolle controle is de build binnen 24 uur beschikbaar voor testers. De geldigheidsduur van een build is 90 dagen.

Internal Testing instellen in App Store Connect

In App Store Connect wordt Internal Testing ingesteld in de sectie TestFlight → Internal Testing. De accounteigenaar voegt testers toe via e-mail en wijst rollen toe. Na het uploaden van de build via Xcode of Transporter stelt het systeem deelnemers op de hoogte van de beschikbaarheid van een nieuwe versie. Testers installeren de app via de TestFlight-app op het apparaat.

Internal Testing track instellen

Het instellen van Internal Testing voor beide platforms duurt 10 tot 30 minuten. Hieronder vind je stapsgewijze instructies voor Google Play en App Store. Het proces vereist geen wijzigingen in de app-code — een eenmalige configuratie van de ontwikkelaarsconsole is voldoende.

Integratie met CI/CD-systemen

Beide winkels ondersteunen publicatie in Internal Testing via API. Voor automatisering worden Gradle Play Publisher (Google Play) en Fastlane (beide platforms) gebruikt. De CI/CD-pipeline kan builds uploaden naar de Interne track na elke succesvolle reeks unit-tests en UI-tests.

Testaccounts instellen

Voor apps met authenticatie moeten testaccounts worden voorbereid en aan het QA-team worden doorgegeven. Accounts moeten toegang hebben tot de testomgeving (staging/development) en geen productiegegevens beïnvloeden. Het wordt aanbevolen om een aparte Firebase-configuratie voor de Interne track te maken.

QA-werkstroom met Internal Testing

Internal Testing wordt ingebouwd in de QA-pipeline na het doorstaan van geautomatiseerde controles in CI. De ontwikkelaar of DevOps-ingenieur uploadt de build naar de Interne track, waarna QA-ingenieurs een melding ontvangen en de update op testapparaten installeren via de app-winkel.

Optimale publicatiefrequentie

Het wordt aanbevolen om builds dagelijks of na elke significante wijziging in de codebase naar Internal Testing te publiceren. Het QA-team test kritische scenario's: authenticatie, de belangrijkste gebruikersstroom, integratie met API en werken met lokale opslag. Regressietesten worden uitgevoerd bij elke derde of vierde build.

Hulpmiddelen voor feedbackverzameling

Gebruik voor het verzamelen van bugrapporten integratie met trackingsystemen: Jira, YouTrack, Trello of GitHub Issues. Testers sturen schermafbeeldingen, logs en stappen om te reproduceren. TestFlight ondersteunt ingebouwd het verzamelen van schermafbeeldingen en logs van het apparaat bij schudden — gegevens worden naar de ontwikkelaar gestuurd via App Store Connect.

Integratie met CI/CD-pipeline

Configureer een CI/CD-pipeline voor automatische publicatie van builds in de Internal Testing track. Na het doorstaan van unit-tests en UI-tests uploadt het script de build naar de Interne track en stuurt een melding naar het QA-team. Fastlane biedt de kant-en-klare actie upload_to_play_store met parameter track: internal. Voor iOS gebruik je Fastlane Pilot voor upload naar TestFlight.

Beperkingen van Internal Testing

Internal Testing heeft strikte limieten voor het aantal deelnemers: tot 100 personen in Google Play en tot 100 interne testers in TestFlight. Google Play beperkt ook het aantal groepen — maximaal 1 groep voor de Interne track. App Store beperkt het aantal builds niet, maar de geldigheidsduur van elke build is 90 dagen.

Verschillen in limieten tussen platforms

Google Play beperkt het aantal geüploade builds in de Interne track niet, maar na 90 dagen inactiviteit kan de track automatisch worden opgeschort. TestFlight heeft strengere beperkingen: tot 30 gelijktijdige actieve builds, tot 10 000 externe testers (niet Internal). Voor het opheffen van beperkingen is deelname aan het Apple Developer Enterprise-programma vereist.

Migratie van Internal naar Open Beta

Na stabilisatie van de build op de Interne track wordt deze overgebracht naar Closed of Open Beta voor testen op een extern publiek. Google Play maakt het mogelijk trackinstellingen te kopiëren en de build over te zetten zonder opnieuw te uploaden. TestFlight vereist het aanmaken van een aparte externe track met toevoeging van nieuwe testersgroepen.

Beveiliging van de Internal Testing track

Builds in de Interne track zijn beschermd tegen externe toegang: alleen deelnemers die zijn geautoriseerd via Google Play Console of App Store Connect kunnen de app downloaden. Zelfs met kennis van de app-link kan een externe persoon de build niet installeren. Dit waarborgt de vertrouwelijkheid van nieuwe functies en bescherming van intellectueel eigendom in de ontwikkelingsfase.