Internal Testing: innebörd, hur det fungerar och hur du ställer in spåret

Vad är Internal Testing?

Internal Testing är ett testspår i Google Play Console och TestFlight som är utformat för att distribuera builds bland medlemmar i utvecklingsteamet. Till skillnad från öppen betatestning är åtkomsten till Internal Testing begränsad till en lista med e-postadresser som godkänts av utvecklarkontots ägare.

Den största fördelen är den minimala leveranstiden för bygget till testare. I Google Play kräver Internal Testing ingen granskning — bygget visas för deltagarna inom 5–15 minuter efter uppladdning. I App Store via TestFlight levereras bygget också utan föregående App Review, men genomgår automatisk kontroll av grundläggande säkerhetskrav.

Hur Internal Testing skiljer sig från andra spår

I Google Play finns tre testspår: Internal Testing, Closed Beta (Open Beta) och Production. Internal Testing är det snabbaste och mest begränsade när det gäller antal deltagare (upp till 100 personer). Closed Beta tillåter upp till 10 000 deltagare och kräver inställning av en testsida. Production är slutsteget med full granskning.

När ska Internal Testing användas

Internal Testing används för primär kontroll av builds innan de skickas vidare till betaspår. Utvecklare laddar upp dagliga byggen för QA-teamet, kontrollerar integration av nya SDK:er, testar kompatibilitet med olika operativsystemversioner och identifierar regressionsfel innan bygget ses av externa testare.

Internal Testing i Google Play

I Google Play Console är Internal Testing ett separat spår, tillgängligt i avsnittet Release → Testing. För att lägga till en testare räcker det att ange dess e-postadress — deltagaren får en inbjudan och en länk för att ansluta via Google Play. Byggen laddas upp via samma gränssnitt som produktionslanseringar.

Publiceringsprocess i det interna spåret

Utvecklaren laddar upp App Bundle eller APK i avsnittet Internal Testing i Google Play Console. Systemet kontrollerar grundläggande krav: signatur, kodversion och API-kompatibilitet. Efter 5–15 minuters bearbetning blir bygget tillgängligt för testare. Statusen kan följas i konsolen: Draft, In Review, Ready to Test.

// Fastlane — publicering i Internal Testing-spåret
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

Hantera testare

Läggande av deltagare görs via avsnittet Testers i Google Play Console. Gruppuppladdning via CSV-fil finns tillgänglig. Varje testare får ett e-postmeddelande med inbjudan och installationsinstruktioner. För att återkalla åtkomst räcker det att ta bort deltagaren från gruppen — den installerade appen fortsätter att fungera, men nya uppdateringar kommer inte.

Internal Testing i App Store via TestFlight

I Apples ekosystem fyller TestFlight rollen som Internal Testing — en plattform för distribution av betaversioner. TestFlight stöder upp till 100 interna testare som läggs till via e-post i App Store Connect. För att publicera ett bygge krävs inte fullständig App Review, men bygget kontrolleras automatiskt för minimikrav.

Egenskaper för TestFlight Internal Testing

Till skillnad från Google Play där Internal Testing inte kräver någon granskning alls, utför Apple en automatisk Basic Review. Kontrollen tar 30–60 minuter och inkluderar skanning av binärkod för skadliga API:er och efterlevnad av grundläggande krav. Efter framgångsrik kontroll är bygget tillgängligt för testare inom 24 timmar. Byggets giltighetstid är 90 dagar.

Konfigurera Internal Testing i App Store Connect

I App Store Connect konfigureras Internal Testing i avsnittet TestFlight → Internal Testing. Kontoägaren lägger till testare via e-post och tilldelar roller. Efter uppladdning av bygget via Xcode eller Transporter meddelar systemet deltagarna om tillgängligheten av en ny version. Testare installerar appen via TestFlight-appen på enheten.

Ställa in Internal Testing-spåret

Konfigurering av Internal Testing för båda plattformarna tar 10 till 30 minuter. Nedan finns steg-för-steg-instruktioner för Google Play och App Store. Processen kräver inga ändringar i appkoden — en engångskonfiguration av utvecklarkonsolen räcker.

Integration med CI/CD-system

Båda butikerna stöder publicering i Internal Testing via API. För automatisering används Gradle Play Publisher (Google Play) och Fastlane (båda plattformarna). CI/CD-pipelinen kan ladda upp builds till det interna spåret efter varje framgångsrik omgång av enhetstester och UI-tester.

Konfigurera testkonton

För appar med autentisering måste testkonton förberedas och överlämnas till QA-teamet. Kontona bör ha åtkomst till testmiljön (staging/development) och inte påverka produktionsdata. Det rekommenderas att skapa en separat Firebase-konfiguration för det interna spåret.

QA-arbetsflöde med Internal Testing

Internal Testing är inbyggt i QA-pipelinen efter att automatiska kontroller i CI har godkänts. Utvecklaren eller DevOps-ingenjören laddar upp bygget till det interna spåret, varefter QA-ingenjörer får ett meddelande och installerar uppdateringen på testenheter via appbutiken.

Optimal publiceringsfrekvens

Det rekommenderas att publicera builds till Internal Testing dagligen eller efter varje betydande förändring i kodbasen. QA-teamet testar kritiska scenarier: autentisering, det primära användarflödet, API-integration och arbete med lokal lagring. Regressionstestning utförs på var tredje eller fjärde bygge.

Verktyg för feedbackinsamling

För insamling av felrapporter, använd integration med spårningssystem: Jira, YouTrack, Trello eller GitHub Issues. Testare skickar skärmdumpar, loggar och reproduceringssteg. TestFlight har inbyggt stöd för insamling av skärmdumpar och loggar från enheten vid skakning — data skickas till utvecklaren via App Store Connect.

Integration med CI/CD-pipeline

För automatisk publicering av builds i Internal Testing-spåret, konfigurera en CI/CD-pipeline. Efter att enhetstester och UI-tester har godkänts laddar skriptet upp bygget till det interna spåret och skickar ett meddelande till QA-teamet. Fastlane tillhandahåller den färdiga åtgärden upload_to_play_store med parametern track: internal. För iOS, använd Fastlane Pilot för uppladdning till TestFlight.

Begränsningar för Internal Testing

Internal Testing har strikta gränser för antalet deltagare: upp till 100 personer i Google Play och upp till 100 interna testare i TestFlight. Google Play begränsar också antalet grupper — maximalt 1 grupp för det interna spåret. App Store begränsar inte antalet builds, men giltighetstiden för varje bygge är 90 dagar.

Skillnader i gränser mellan plattformar

Google Play begränsar inte antalet uppladdade builds i det interna spåret, men efter 90 dagars inaktivitet kan spåret automatiskt stängas av. TestFlight har strängare begränsningar: upp till 30 samtidigt aktiva builds, upp till 10 000 externa testare (inte Internal). För att ta bort begränsningarna krävs deltagande i Apple Developer Enterprise-programmet.

Migrering från Internal till Open Beta

Efter att bygget stabiliserats på det interna spåret överförs det till Closed eller Open Beta för testning på extern publik. Google Play gör det möjligt att kopiera spårinställningar och överföra bygget utan omuppladdning. TestFlight kräver att ett separat externt spår skapas med tillägg av nya testargrupper.

Säkerhet för Internal Testing-spåret

Byggen i det interna spåret är skyddade från extern åtkomst: appen kan endast laddas ner av deltagare som är auktoriserade via Google Play Console eller App Store Connect. Även om någon känner till app-länken kan en extern person inte installera bygget. Detta säkerställer konfidentialitet för nya funktioner och skydd av immateriella rättigheter under utvecklingsfasen.