Internal Testing: Was es ist, wie es funktioniert und wie man den Track einrichtet

Was ist Internal Testing?

Internal Testing ist ein Testtrack in der Google Play Console und TestFlight, der für die Verteilung von Builds an Mitglieder des Entwicklungsteams konzipiert ist. Im Gegensatz zu offenen Beta-Tests ist der Zugang zu Internal Testing auf eine Liste von E-Mail-Adressen beschränkt, die vom Inhaber des Entwicklerkontos genehmigt wurden.

Der Hauptvorteil ist die minimale Zustellzeit des Builds an die Tester. In Google Play muss Internal Testing keine Moderation durchlaufen — der Build erscheint innerhalb von 5–15 Minuten nach dem Upload bei den Teilnehmern. Im App Store über TestFlight wird der Build ebenfalls ohne vorherige App Review zugestellt, unterliegt jedoch einer automatischen Überprüfung auf grundlegende Sicherheitsanforderungen.

Wie sich Internal Testing von anderen Tracks unterscheidet

Google Play hat drei Testtracks: Internal Testing, Closed Beta (Open Beta) und Production. Internal Testing ist der schnellste und am stärksten eingeschränkte Track (bis zu 100 Personen). Closed Beta erlaubt bis zu 10.000 Teilnehmer und erfordert die Einrichtung einer Testseite. Production ist die letzte Stufe mit vollständiger Moderation.

Wann Internal Testing verwendet wird

Internal Testing wird für die erste Überprüfung von Builds verwendet, bevor sie an Beta-Tracks übergeben werden. Entwickler laden tägliche Builds für das QA-Team hoch, überprüfen die Integration neuer SDKs, testen die Kompatibilität mit verschiedenen OS-Versionen und identifizieren Regressionsfehler, bevor der Build von externen Testern gesehen wird.

Internal Testing in Google Play

In der Google Play Console ist Internal Testing ein separater Track, der im Bereich Release → Testing verfügbar ist. Um einen Tester hinzuzufügen, genügt die Eingabe seiner E-Mail-Adresse — der Teilnehmer erhält eine Einladung und einen Link zum Beitritt über Google Play. Builds werden über dieselbe Oberfläche wie Produktions-Releases hochgeladen.

Veröffentlichungsprozess im internen Track

Der Entwickler lädt ein App Bundle oder APK im Bereich Internal Testing der Google Play Console hoch. Das System überprüft die grundlegenden Anforderungen: Signatur, Code-Version und API-Kompatibilität. Nach 5–15 Minuten Verarbeitung wird der Build für die Tester verfügbar. Der Status wird in der Konsole verfolgt: Entwurf, In Überprüfung, Bereit zum Testen.

// Fastlane — Veröffentlichung im 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

Verwaltung der Tester

Das Hinzufügen von Teilnehmern erfolgt über den Bereich Testers in der Google Play Console. Gruppen-Upload über CSV-Datei wird unterstützt. Jeder Tester erhält eine E-Mail mit einer Einladung und Installationsanweisungen. Um den Zugriff zu entziehen, genügt es, den Teilnehmer aus der Gruppe zu entfernen — die installierte App funktioniert weiterhin, aber es kommen keine neuen Updates.

Internal Testing im App Store über TestFlight

Im Apple-Ökosystem übernimmt TestFlight die Rolle des Internal Testing — eine Plattform zur Verteilung von Beta-Versionen. TestFlight unterstützt bis zu 100 interne Tester, die per E-Mail über App Store Connect hinzugefügt werden. Für die Veröffentlichung eines Builds ist keine vollständige App Review erforderlich, aber der Build wird automatisch auf Mindestanforderungen geprüft.

Besonderheiten von TestFlight Internal Testing

Im Gegensatz zu Google Play, wo Internal Testing keinerlei Moderation erfordert, führt Apple eine automatische Basis-Review durch. Die Überprüfung dauert 30–60 Minuten und umfasst das Scannen des Binärcodes auf schädliche APIs und die Einhaltung grundlegender Anforderungen. Nach erfolgreicher Überprüfung ist der Build innerhalb von 24 Stunden für die Tester verfügbar. Der Build ist 90 Tage gültig.

Einrichtung von Internal Testing in App Store Connect

In App Store Connect wird Internal Testing im Bereich TestFlight → Internal Testing konfiguriert. Der Kontoinhaber fügt Tester per E-Mail hinzu und weist Rollen zu. Nach dem Hochladen eines Builds über Xcode oder Transporter benachrichtigt das System die Teilnehmer über die Verfügbarkeit einer neuen Version. Tester installieren die App über die TestFlight-App auf ihrem Gerät.

So richten Sie einen Internal Testing Track ein

Die Einrichtung von Internal Testing für beide Plattformen dauert 10 bis 30 Minuten. Nachfolgend finden Sie Schritt-für-Schritt-Anleitungen für Google Play und App Store. Der Prozess erfordert keine Änderungen am App-Code — eine einmalige Einrichtung der Entwicklerkonsole ist ausreichend.

Integration mit CI/CD-Systemen

Beide Stores unterstützen die Veröffentlichung in Internal Testing über API. Für die Automatisierung werden Gradle Play Publisher (Google Play) und Fastlane (beide Plattformen) verwendet. Die CI/CD-Pipeline kann nach jedem erfolgreichen Durchlauf von Unit-Tests und UI-Tests Builds in den internen Track hochladen.

Einrichtung von Testkonten

Für Apps mit Authentifizierung müssen Testkonten vorbereitet und dem QA-Team zur Verfügung gestellt werden. Die Konten sollten Zugriff auf die Testumgebung (Staging/Development) haben und keine Produktionsdaten beeinträchtigen. Es wird empfohlen, eine separate Test-Firebase-Konfiguration für den internen Track zu erstellen.

QA-Workflow mit Internal Testing

Internal Testing wird nach bestandenen automatischen Prüfungen in CI in die QA-Pipeline integriert. Der Entwickler oder DevOps-Ingenieur lädt den Build in den internen Track hoch, woraufhin QA-Ingenieure eine Benachrichtigung erhalten und das Update über den App Store auf Testgeräten installieren.

Optimale Veröffentlichungshäufigkeit

Es wird empfohlen, Builds täglich oder nach jeder wichtigen Änderung in der Codebasis in Internal Testing zu veröffentlichen. Das QA-Team testet kritische Szenarien: Authentifizierung, Hauptbenutzerfluss, API-Integration und lokale Speicheroperationen. Regressionstests werden bei jedem dritten oder vierten Build durchgeführt.

Tools zur Feedback-Erfassung

Verwenden Sie für die Erfassung von Fehlerberichten die Integration mit Tracking-Systemen: Jira, YouTrack, Trello oder GitHub Issues. Tester senden Screenshots, Logs und Schritte zur Reproduktion. TestFlight bietet integrierte Unterstützung für die Erfassung von Screenshots und Geräteprotokollen beim Schütteln — die Daten werden über App Store Connect an den Entwickler gesendet.

CI/CD-Pipeline-Integration

Um Builds automatisch im Internal Testing Track zu veröffentlichen, richten Sie eine CI/CD-Pipeline ein. Nach Bestehen von Unit-Tests und UI-Tests lädt das Skript den Build in den internen Track hoch und sendet eine Benachrichtigung an das QA-Team. Fastlane bietet die vorgefertigte Aktion upload_to_play_store mit dem Parameter track: internal. Verwenden Sie für iOS Fastlane Pilot zum Hochladen in TestFlight.

Einschränkungen und Grenzen von Internal Testing

Internal Testing hat strenge Grenzen für die Anzahl der Teilnehmer: bis zu 100 Personen in Google Play und bis zu 100 interne Tester in TestFlight. Google Play begrenzt zusätzlich die Anzahl der Gruppen — maximal 1 Gruppe für den internen Track. Der App Store begrenzt die Anzahl der Builds nicht, aber jeder Build ist 90 Tage gültig.

Unterschiede bei den Grenzen zwischen den Plattformen

Google Play begrenzt die Anzahl der in den internen Track hochgeladenen Builds nicht, aber nach 90 Tagen Inaktivität kann der Track automatisch ausgesetzt werden. TestFlight hat strengere Grenzen: bis zu 30 gleichzeitig aktive Builds, bis zu 10.000 externe Tester (nicht intern). Zur Aufhebung der Beschränkungen ist eine Teilnahme am Apple Developer Enterprise-Programm erforderlich.

Migration von Internal zu Open Beta

Nach der Stabilisierung des Builds im internen Track wird er in Closed oder Open Beta zum Testen mit einem externen Publikum verschoben. Google Play erlaubt das Kopieren der Track-Einstellungen und die Übertragung des Builds ohne erneuten Upload. TestFlight erfordert die Erstellung eines separaten externen Tracks mit neuen Testergruppen.

Sicherheit des Internal Testing Tracks

Builds im internen Track sind vor externem Zugriff geschützt: Nur Teilnehmer, die über Google Play Console oder App Store Connect autorisiert sind, können die App herunterladen. Selbst wenn jemand den App-Link kennt, kann ein nicht autorisierter Benutzer den Build nicht installieren. Dies gewährleistet die Vertraulichkeit neuer Funktionen und schützt geistiges Eigentum während der Entwicklungsphase.