So richten Sie den internen Test bei Google Play ein (2026)

Der interne Test ist der eine Track in der Play Console, der sich so verhält, wie Entwickler es von Software erwarten: Sie laden einen Build hoch, er erscheint, die Leute installieren ihn. Bis er es eines Tages nicht mehr tut. Dann sitzen Sie vor einem Link, der eine Play Store-Seite mit dem Hinweis öffnet, die App sei für Ihr Konto nicht verfügbar. Kein Fehlercode, keine Diagnose, und ein Hilfeartikel, der drei Test-Tracks über mehrere hundert Zeilen hinweg vermischt. Dieser Beitrag trennt den internen Track von den beiden anderen, gibt Ihnen den Weg durch die Console und die Regeln für Testerlisten in der Reihenfolge, in der Sie sie wirklich brauchen, und nimmt sich dann echte Zeit für die Fehlerfamilie, die die Support-Threads füllt. Wo Googles eigene Seiten sich widersprechen, und beim Timing tun sie das eindeutig, stehen hier beide Lesarten und nicht nur die bequeme. Alle Angaben haben den Stand 12. August 2026.

Wie richten Sie den internen Test ein?

Bevor Sie anfangen

Bereiten Sie die App, den Build, die Testerkonten und Ihren eigenen Zugriff auf die Play Console vor. Beachten Sie, was nicht nötig ist: ein fertiger Store-Eintrag, Screenshots, eine Inhaltsbewertung oder ein ausgefülltes Formular zur Datensicherheit. Google erlaubt ausdrücklich, einen internen Test laufen zu lassen, bevor die App vollständig eingerichtet ist. Belegt

• 01
  Eine App, die es in der Play Console gibt Angelegt, nicht unbedingt ausgefüllt. Das erste Artefakt, das Sie hochladen, legt den Paketnamen dieser App fest, und danach lässt er sich nicht mehr ändern. Achten Sie also darauf, dass die applicationId die ist, bei der Sie bleiben wollen.
• 02
  Ein gültiges App Bundle Googles Formulierung lautet „gültiges App Bundle“. Das ist die einzige Anforderung an das Artefakt, um einen frühen internen Build in die Hände der Tester zu bringen.
• 03
  E-Mail-Adressen der Tester Google-Konten. Die aktuelle Hilfe nennt ein Google-Konto mit Gmail oder ein Google Workspace-Konto. Sammeln Sie genau die Adresse, mit der jede Person angemeldet sein wird, denn an dieser Identität hängt der ganze Track.
• 04
  Der nötige Zugriff in der Play Console Inhaber und Administratoren haben ihn bereits. Ein Nutzer mit delegierten Rechten braucht die Berechtigung, Apps für Test-Tracks freizugeben, und für die Verwaltung des Tracks und seiner Testerlisten kann die separate Berechtigung nötig sein, Test-Tracks zu verwalten und Testerlisten zu bearbeiten. Eine fehlende oder ausgegraute Schaltfläche für den Release ist ein Zugriffsproblem, kein Problem des Builds.
• 05
  Play App Signing, nur beim ersten Release Beim ersten Release einer App führt die Play Console Sie durch die Einrichtung von Play App Signing. Das ist ein einmaliger Schritt, der Ihnen beim Upload begegnet und den Sie nicht vorab erledigen müssen, es ist aber gut zu wissen, dass er kommt.

Schritt 1: den Track für den internen Test öffnen

Wählen Sie Ihre App aus und gehen Sie dann zu Test and release › Testing › Internal testing. Google dokumentiert diesen Pfad auf zwei verschiedene Arten. Der Hilfeartikel der Play Console zum Einrichten eines Tests kürzt ihn auf Testing › Internal testing ab, während eine andere aktuelle Hilfeseite das vollständige übergeordnete Menü zeigt. Beide beschreiben dasselbe Ziel. Wenn Ihre Console also ein kürzeres Menü zeigt als das hier notierte, sind Sie nicht falsch.

Schritt 2: die Liste Ihrer internen Tester anlegen

Öffnen Sie im Track für den internen Test den Tab Testers und wählen Sie Create email list. Benennen Sie die Liste, fügen Sie die Adressen hinzu, speichern Sie die Änderungen und legen Sie die Liste an. Die Adressen können Sie durch Kommas getrennt direkt in die Oberfläche tippen oder als CSV hochladen. Der Weg über die CSV ist der, auf dem Listen still und leise zerstört werden, denn er bringt drei Regeln mit, die genau einmal dokumentiert und nie wiederholt werden.

Prüfer für die Testerliste

Schritt 3: die Liste und einen Feedback-Kanal hinzufügen

Wählen Sie zurück im Tab Testers die Nutzerliste oder die Listen aus, die dieser Track verwenden soll, und geben Sie Google dann eine Feedback-URL oder eine E-Mail-Adresse. Dieses Ziel wird den Testern auf der Anmeldeseite angezeigt und ist damit ihr einziger eingebauter Weg, Ihnen zu sagen, dass etwas kaputt ist.

Schritt 4: den Release erstellen und ausrollen

Wählen Sie Create new release, fügen Sie Ihr App Bundle hinzu, prüfen Sie es und rollen Sie es mit den aktuellen Bedienelementen der Console aus. Die Varianten der Play Console unterscheiden sich in der genauen Beschriftung so stark, dass eine darüber hinaus auswendig gelernte Klickfolge eher schadet als hilft. Die Anweisung endet deshalb dort, wo Googles aktuelle Dokumentation endet.

Schritt 5: den Link zur Anmeldung kopieren und teilen

Kopieren Sie den teilbaren Testlink und verschicken Sie ihn. Dieser Schritt verwirrt Entwickler mindestens seit 2018, und die Verwirrung ist völlig nachvollziehbar: Jedes andere Einladungssystem im Internet verschickt eine E-Mail, und Googles dokumentierter Ablauf gibt Ihnen stattdessen einen Link zum Verteilen. Verlassen Sie sich nicht darauf, dass die Play Console Ihre Tester für Sie einlädt.

Zwei Bedingungen entscheiden darüber, ob es diesen Link überhaupt schon gibt. Der Link zur Anmeldung wird nur angezeigt, wenn der Status der App Published ist. Solange die App auf Draft oder Pending publication steht, gibt es nichts zu kopieren, und noch so häufiges Nachlesen im Tab Testers erzeugt keinen. Belegt

Schritt 6: jeder Tester meldet sich an und installiert

Der letzte Schritt gehört dem Tester, und es ist der eine, den Sie ihm nicht abnehmen können. Jede Person öffnet Ihren Link, während sie mit genau dem Konto angemeldet ist, das Sie hinzugefügt haben, schließt auf dieser Seite die Anmeldung ab, folgt dann dem Play Store-Link und installiert. Bis das passiert, sind diese Leute berechtigt, aber nicht eingetragen, und berechtigte Tester bekommen nichts. Schreiben Sie den Namen des eingeladenen Kontos neben den Link, denn sich mit der falschen Identität anzumelden ist einer der am häufigsten berichteten Fehler in diesem Ablauf, und er sieht exakt aus wie ein kaputter Link.

Wer macht was

Der ganze Ablauf in einer Tabelle

Scrollen Sie die Tabelle seitwärts, um alle Spalten zu sehen

Wann können Tester installieren?

Während eines internen Tests laufen fünf getrennte Uhren, und Klagen über die Dauer entstehen meistens daraus, dass zwei falsche verglichen werden. Dass der Build Googles Auslieferungssystem erreicht, ist das eine. Dass der Link zur Anmeldung für die Tester live geht, ist das zweite. Dass eine veröffentlichte Änderung bei Leuten ankommt, die bereits beigetreten sind, ist das dritte. Dass sich eine installierte App automatisch aktualisiert, ist das vierte. Und dass der vorläufige Store-Eintrag durch Ihren echten App-Namen ersetzt wird, ist das fünfte, weshalb ein einwandfrei funktionierender interner Build ein paar Tage lang trotzdem unfertig aussehen kann.

Ist meine Wartezeit noch normal?

Die einzig brauchbare Fassung dieser Frage enthält, worauf Sie warten, denn die Antwort unterscheidet sich zwischen den Stufen um den Faktor hundert. Das Werkzeug unten fragt beides ab, zitiert für diese Stufe, was Google tatsächlich veröffentlicht, und kennzeichnet seine eigenen Prüfpunkte als Lesart dieses Beitrags und nicht als Googles.

Uhr für die Verteilung

Alle Uhren nebeneinander

Scrollen Sie die Tabelle seitwärts, um alle Spalten zu sehen

Der redaktionelle Punkt, den man mitnehmen sollte: Sekunden, Minuten, ein paar Stunden und bis zu 48 Stunden stimmen alle gleichzeitig, weil sie verschiedene Teile derselben Kette beschreiben. Jeder Artikel, der sie zu einer einzigen Zahl plattdrückt, führt jemanden genau in dem Moment in die Irre, in dem er Genauigkeit braucht. Belegt

Wartet ein interner Release auf Googles Überprüfung?

Hier kommt es auf die Formulierung an, denn die beiden Google-Quellen sind nicht gleich formuliert. Googles Produktseite zum internen Test bewirbt ihn als Weg, Builds zu verteilen, ohne auf App-Überprüfungen warten zu müssen. Das Hilfezentrum der Play Console ist zurückhaltender und sagt, interne Tests unterliegen den üblichen Richtlinien- und Sicherheitsüberprüfungen von Play möglicherweise nicht.

Die genaue Aussage lautet also: Der interne Test lässt Sie in der Regel verteilen, ohne auf den üblichen Ablauf der App-Überprüfung zu warten. Die ungenaue lautet: Interne Releases werden nie überprüft. Google hat keine kategorische Ausnahme von jeder Überprüfung zugesagt, und das trotzdem zu schreiben ist der Weg, auf dem ein Beitrag falsch wird, sobald der erste interne Release von jemandem zurückgehalten wird. Belegt, mit Vorbehalt bei der Formulierung

Zählt der interne Test für die 12 Tester?

Das ist das folgenschwerste Missverständnis im ganzen Thema, und es wird aktiv verbreitet. Mindestens ein weit zirkulierender Artikel aus dem Jahr 2026 beschreibt die verpflichtende Anforderung als etwas, das man im Track für den internen Test erfüllt. Googles eigene Anforderungsseite sagt das Gegenteil, in Worten, die keinen Auslegungsspielraum lassen.

Die Entscheidungsregel in einer Zeile

Nutzen Sie den internen Test für schnelles, privates QA mit Leuten, denen Sie vertrauen. Nutzen Sie den geschlossenen Test, wenn Sie den vorgeschriebenen Test vor der Produktion brauchen. Das ist die ganze Regel, und mehr sagt dieser Beitrag zu dem Vergleich bewusst nicht: Die vollständige Gegenüberstellung der drei Tracks steht in interner, geschlossener oder offener Test, der genau für diese Frage gebaut ist.

Scrollen Sie die Tabelle seitwärts, um alle Spalten zu sehen

Für wen die Anforderung tatsächlich gilt

Die Anforderung ist im Umfang begrenzt, und genau in dieser Begrenzung steckt die meiste Verwirrung. Googles Seite dokumentiert sie für qualifizierende private Entwicklerkonten, die nach dem 13. November 2023 erstellt wurden. Angekündigt hat Google die Richtlinie am 9. November 2023, weshalb Sie beide Daten als Beginn zitiert finden.

Bei Organisationskonten sollten Sie vorsichtig formulieren. Googles Anforderungsseite begrenzt die Regel auf private Konten; sie enthält keinen Satz, der Organisationskonten ausdrücklich ausnimmt. Belastbar ist die Formulierung, dass die Anforderung für qualifizierende private Entwicklerkonten dokumentiert ist und die zitierte Seite sie Organisationskonten nicht auferlegt. Umfang abgeleitet

14 Tage angemeldet ist nicht dasselbe wie 14 Tage genutzt

Die Zahlenschwelle ist so formuliert, dass Tester fortlaufend angemeldet sind, nicht über eine tägliche Nutzung. Das ist der messbare Teil. Davon getrennt bewertet Google, was Sie bei der Beantragung des Produktionszugriffs über Ihren Test berichten, und kann weitere Tests verlangen, wenn die Zahl der Tester oder ihr Engagement nicht ausreicht. Konkurrierende Seiten werfen diese beiden Dinge regelmäßig zu einer erfundenen Regel über tägliche Nutzungsminuten zusammen.

Also: Die Schwelle ist die durchgehende Anmeldung, und das Engagement wird zusätzlich bewertet, nicht an ihrer Stelle. Was das für einen laufenden Test praktisch bedeutet, behandeln die Regel der 14 aufeinanderfolgenden Tage und die Anforderung von 12 Testern erklärt. Belegt

Warum funktioniert mein Link zum internen Test nicht?

Das ist der Fehler, der die Community-Threads zum internen Test füllt, und der am schlechtesten dokumentierte. Entwickler landen dabei, nachdem sie alles getan haben, was die Play Console verlangt hat, und genau deshalb ist die Erfahrung so verstörend: kein Fehlercode, keine Diagnose, und die Seite meldet fröhlich, die App sei für Ihr Konto nicht verfügbar, als wäre das Konto das Problem und nicht ein Symptom. Die Berichte reichen von einer Frage auf Stack Overflow aus dem Jahr 2018 bis zu Threads in der Google Developer Community vom Juli 2026, auf Englisch und auf Portugiesisch, und sie beschreiben dieselbe Handvoll Ursachen.

Der nützliche Schritt ist, es nicht mehr als kaputten Link zu sehen, sondern als Stromkreis. Googles Regel für die Auslieferung ist eine Reihe von Bedingungen, und ein offener Kontakt stoppt alles dahinter. Vier Zustände decken die Ursachen ab, die in diesen Berichten immer wiederkehren: nicht auf der Testerliste, auf der Liste, aber nicht angemeldet, angemeldet, aber mit dem falschen Google-Konto und korrekt konfiguriert und noch in der Verteilung. Der letzte ist überhaupt kein Fehler, und genau deshalb geht damit so viel Zeit verloren.

Die offene Schranke finden

Stellen Sie jeden Schalter unten auf das, was Sie tatsächlich bestätigt haben, nicht auf das, was Sie annehmen. Die Schranken sind danach sortiert, wie günstig sich jede prüfen lässt, die erste noch offene ist also die, die sich als Nächstes zu beheben lohnt.

Simulator für die Zugriffsschranken

“Diese App ist für Ihr Konto nicht verfügbar”

Der Testzugriff hängt an einer Identität, nicht an einem Gerät und nicht an einem Link. Google verlangt, dass das Konto in der verwalteten Testerkonfiguration enthalten ist und sich für dieses Testprogramm angemeldet hat. Fehlt eine der beiden Hälften, kann der Play Store diese Person nicht von einem Fremden unterscheiden, der Ihre URL gefunden hat.

Der Grund, warum das in der Praxis so oft auftaucht, ist banal: Auf Telefonen und in Browsern sind routinemäßig mehrere Google-Konten angemeldet, und dasjenige, das einen Link öffnet, ist nicht immer das, das Sie eingeladen haben. Threads in der Google Developer Community vom März 2026 beschreiben Tester, die überhaupt nicht auf die gewünschte Identität umschalten können, weil sich die Kontoauswahl anders verhält als erwartet, und portugiesischsprachige Threads von Mitte 2025 berichten dasselbe Muster mit einer Antwort, die direkt auf das in Google Play ausgewählte Konto zeigt. Aus der Community

Es gibt keinen Link zur Anmeldung zum Kopieren

Prüfen Sie zuallererst den Status der App. Google zeigt den Link zur Anmeldung nur an, wenn der Status der App Published ist. Bei Draft oder Pending publication ist der Link nicht versteckt und nicht verzögert, es gibt ihn schlicht noch nicht. Das ist die sauberste Lösung im ganzen Fehlerkatalog, weil die Bedingung binär und in Ihrer eigenen Console sichtbar ist. Belegt

Sie ist veröffentlicht, aber niemand findet sie über die Play-Suche

Das ist erwartetes Verhalten und kein Fehler. Google sagt, dass ein interner oder geschlossener Test, der vor dem offenen Test oder der Produktion liegt, über die Suche im Play Store nicht auffindbar ist. Tester, denen man sagt, sie sollten „die App in Play suchen“, scheitern jedes Mal, ganz gleich wie korrekt Ihre Konfiguration ist, und melden völlig zu Recht zurück, dass es die App nicht gibt.

Schicken Sie den direkten Link. Schreiben Sie ausdrücklich dazu, dass Suchen nicht funktioniert, denn genau das versucht jeder zuerst. Belegt

Manche Tester haben noch die alte Version

Arbeiten Sie drei Ursachen der Reihe nach ab. Erstens die Verteilung: Weitere veröffentlichte Änderungen können mehrere Stunden brauchen, bis sie bei den Testern ankommen, ein frisches Update ist also womöglich einfach noch nicht da. Zweitens die Version codes: Ein Nutzer erhält den höchsten kompatiblen Version code aus jedem Track, für den er berechtigt ist. Weil jeder Nutzer für die Produktion berechtigt ist, kann statt einer niedrigeren Testversion ein höherer Version code aus der Produktion ausgeliefert werden, und daraus entsteht die verwirrende Lage, dass Ihr neuester interner Build echt und korrekt ist und der Tester ihn trotzdem nicht hat. Drittens die Berechtigung für den Track: Ein Konto, das für den internen Test angemeldet ist, ist nicht berechtigt, geschlossene oder offene Builds zu erhalten. Wenn Sie die Arbeit also auf einen anderen Track verlagert haben, schaut dieses Konto auf den falschen. Belegt

Alles stimmt, und es scheitert trotzdem

Jetzt, und erst jetzt, lohnen sich die Hausmittel aus der Community: Gerät neu starten, Play Store neu starten, Cache oder Daten des Play Store löschen oder den Link in einem frischen Browserprofil öffnen. Sie stammen aus Threads der Google Developer Community und nicht aus Googles Richtlinien, und sie werden als etwas berichtet, das bei irgendjemandem geholfen hat, nicht als dokumentiertes Verhalten. Sie an den Anfang zu stellen, ist der Weg, auf dem Entwickler Tage verlieren: Sie beheben kein Konfigurationsproblem und tarnen eine Verzögerung bei der Verteilung als Erfolg. Aus der Community

Es gibt außerdem einen echten Grenzfall. Ein Community-Thread vom Februar 2026 beschreibt einen Link zum internen Test, der überhaupt nie funktioniert hat, und ein Thread vom Mai 2026 meldet einen HTTP 500 auf der Anmeldeseite. Für beides ist keine allgemeine Ursache belegt, und eine technische Erklärung zu erfinden wäre schlimmer, als das einzugestehen. Wenn Ihre Konfiguration nachweislich korrekt ist, die Zeitfenster für die Verteilung vorbei sind und der Fehler bleibt oder ein Serverfehler zurückkommt, ist das ein vernünftiger Punkt, um über den Support der Play Console zu eskalieren, statt weiter an Einstellungen zu drehen. Ursache unbestätigt

Vom Symptom zur Lösung, mit Belegstufen

Scrollen Sie die Tabelle seitwärts, um alle Spalten zu sehen

Grenzen und Regeln, die oft falsch verstanden werden

Scrollen Sie die Tabelle seitwärts, um alle Spalten zu sehen

Interner Test und interne App-Freigabe

Das sind zwei verschiedene Funktionen mit verwirrend ähnlichen Namen, und die falsche zu wählen kostet einen Nachmittag. Der interne Test ist der reguläre Track, den dieser ganze Beitrag beschreibt: ein Release, eine verwaltete Liste mit bis zu 100 Testern, die Anmeldung und Updates über Google Play. Die interne App-Freigabe ist ein Werkzeug zum schnellen Teilen: Sie nimmt eine hochgeladene APK oder ein App Bundle und gibt Ihnen einen Download-Link zum Weiterreichen. Sie hat eigene Zugriffskontrollen, nur eben andere: Googles Seite dazu lässt Sie den Download auf E-Mail-Listen beschränken oder den Link für jeden öffnen, dem Sie ihn schicken, und in beiden Fällen muss der Tester die interne App-Freigabe zuerst in seiner Play Store-App aktivieren.

Die praktische Regel: Nutzen Sie die interne App-Freigabe, um einem Kollegen in den nächsten zehn Minuten einen Build zuzuwerfen, und den Track für den internen Test, wenn Sie den Versionsverlauf, die Testerliste und einen Build wollen, den Sie später hochstufen können. Der Ablauf nach 60 Tagen ist das Detail, über das Leute stolpern, denn ein Link, der vor zwei Monaten in einem Bugreport noch funktionierte, ist schlicht tot und nicht falsch konfiguriert. Keine der beiden Funktionen zählt für den geschlossenen Test mit 12 Testern. Belegt

Die Falle bei In-App-Käufen

Übernehmen Sie nicht die verbreitete Behauptung, im internen Test sei alles kostenlos. Googles Regel trennt die App von dem, was darin verkauft wird. Eine kostenpflichtige App selbst kann ein interner Tester gratis installieren. In-App-Käufe kosten weiterhin Geld, solange das Konto dieses Testers nicht zusätzlich als Lizenztester eingerichtet ist.

Bei einem Test mit Abos geht es hier um echtes Geld, und mindestens ein derzeit gut platzierter Vergleichsartikel behauptet unumwunden das Gegenteil. Wenn Ihre Tester gleich einen Kaufablauf durchspielen, richten Sie vorher das Lizenztesten ein oder rechnen Sie mit echten Abbuchungen. Belegt

Zwei Dinge, die nicht Ihr Problem sind

Ein großer Teil der allgemeinen Ratschläge zum internen Test im Netz fordert Sie auf, Dinge zu reparieren, die gar nicht die Ursache sein können. Das kostet Zeit und zerschießt manchmal eine funktionierende Konfiguration.

Geprüfte Behauptungen, mit Urteil

Jede Zeile unten ist eine Aussage, die zum internen Test im Umlauf ist. In der Spalte mit dem Urteil steht, was die Primärquellen hergeben, und nicht, was plausibel klingt.

• Falsch
  “Der interne Test zählt als der Test mit 12 Testern.” Googles Anforderungsseite verlangt ausdrücklich einen geschlossenen Test. Das ist der schädlichste Irrtum in diesem Thema, weil er die Leute das ganze 14-Tage-Fenster kostet.
• Veraltet
  “Sie brauchen weiterhin 20 Tester.” Seit dem 11. Dezember 2024 Geschichte. Das aktuelle Minimum ist 12.
• Falsch
  “Interne Tester bekommen alle Käufe kostenlos.” Kostenlos ist nur die kostenpflichtige App selbst. In-App-Käufe kosten Geld, solange kein Lizenztesten eingerichtet ist.
• Falsch
  “Wenn Ihr Tester im Ausland ist, fügen Sie sein Land hinzu.” Google nimmt den internen Test von dieser Beschränkung der Verteilung ausdrücklich aus.
• Irreführend
  “Ihr Link ist kaputt, wenn er nicht sofort funktioniert.” Google selbst räumt für einen ersten Link ein paar Stunden ein und für spätere Änderungen mehrere Stunden.
• Irreführend
  “Tester bekommen den Link zur Anmeldung automatisch per E-Mail.” Googles dokumentierter Ablauf sieht vor, dass der Entwickler den teilbaren Link kopiert und verteilt. Planen Sie nicht damit, dass die Play Console Ihre Tester für Sie einlädt.
• Teilweise
  “Für den internen Test können Sie eine Google Group verwenden.” Die aktuelle Hilfe zur Console dokumentiert E-Mail-Listen für den internen Test und Google Groups für den geschlossenen Test. Die Ressource testers der Publishing API unterstützt Gruppen breiter, das belegt aber nicht das Verhalten der Console 2026 für diesen Track. Nutzen Sie die dokumentierte Methode über die E-Mail-Liste und planen Sie nicht mit einer Gruppe.
• Teilweise
  “Google erlaubt genau einen internen Track.” Die Publishing API stellt den internen Standard-Track als einen einzelnen, fest benannten Track bereit, und die Hilfe dokumentiert zusätzliche benannte geschlossene Tracks, ohne eine Zahl für interne Tracks zu veröffentlichen. Sagen Sie lieber „der Standard-Track für den internen Test“, statt eine harte Obergrenze zu behaupten.
• Stimmt
  “Sie können einen internen Test durchführen, bevor der Store-Eintrag fertig ist.” Google sagt, ein gültiges App Bundle genügt, um vor der vollständigen Einrichtung der App intern zu verteilen.
• Stimmt
  “Feedback von Testern aus einem Test schadet meiner öffentlichen Bewertung nicht.” Google sagt, dass Feedback von Testnutzern die öffentliche Bewertung der App nicht beeinflusst.

Einen internen Test beenden

Pausieren Sie den Track. Die Tester behalten die Kopie, die sie bereits installiert haben, erhalten darüber aber keine Test-Updates mehr. Das sollte man wissen, bevor man annimmt, das Pausieren eines Tracks entferne die App von irgendjemandes Telefon: Das tut es nicht. Belegt

Wie bringen Sie einen Build in den geschlossenen Test?

Diesen Schritt erreichen die meisten nach einem erfolgreichen internen Test, und hier beginnt die Uhr für den Produktionszugriff wirklich zu laufen. Die Anweisung unten verzichtet bewusst auf ein Skript Schaltfläche für Schaltfläche, denn die Varianten der Play Console unterscheiden sich, und ein auswendig gelernter Klickpfad ist das Erste, was bricht.

1. 01
   Den Ziel-Track öffnen Gehen Sie zu Test and release › Testing › Closed testing und verwalten Sie den geschlossenen Track, den Sie nutzen wollen.
2. 02
   Auf diesem Track einen Release erstellen Ein geschlossener Release ist ein eigener Release, auch wenn er das Artefakt trägt, das Sie bereits getestet haben.
3. 03
   Das getestete Artefakt mit Add from library wiederverwenden Wählen Sie die Version aus, die Sie im internen Test hochgeladen haben, statt das Bundle erneut hochzuladen. Genau dieser Teil ist in Googles aktueller Hilfe zu Releases (answer 9859348) dokumentiert. Belegt
4. 04
   Die Tester des geschlossenen Tests konfigurieren Nutzen Sie die eigenen Tester-Einstellungen des geschlossenen Tracks. Für den geschlossenen Test unterstützt die aktuelle Hilfe E-Mail-Listen oder Google Groups, und das ist ein echter Unterschied zum internen Track.
5. 05
   Prüfen und ausrollen Teilen Sie danach den Link zur Anmeldung für den geschlossenen Test genauso, wie Sie den internen geteilt haben. Es gelten dieselben zwei Bedingungen: auf der Liste stehen und angemeldet sein.

Kann ich dieselben Tester behalten?

Als Personen ja, als gleichzeitige Anmeldungen nein, und an dieser Unterscheidung scheitern in dieser Phase mehr geschlossene Tests als an allem anderen.

Ein Konto, das für den internen Test angemeldet ist, ist nicht berechtigt, Builds aus dem offenen oder geschlossenen Test zu erhalten. Googles Anweisung lautet: Der Tester meldet sich zuerst vom internen Test ab und dann für den geschlossenen Test an. Ihre sorgfältig zusammengestellte interne QA-Gruppe kann also durchaus Ihre Gruppe für den geschlossenen Test werden, jeder Einzelne muss den internen Track aber aktiv verlassen, bevor er auf dem geschlossenen überhaupt etwas sieht.

Scrollen Sie die Tabelle seitwärts, um alle Spalten zu sehen

Ab hier ist die Mechanik ein anderes Thema: Leute gewinnen, die 14 Tage am Stück angemeldet bleiben, sie korrekt gezählt bekommen und den Fragebogen zum Produktionszugriff überstehen. Das behandeln Tester zum geschlossenen Test einladen, warum die Play Console 0 angemeldete Tester zeigt und der Fragebogen zum Produktionszugriff.

Wo PrimeTestLab hilft

Es lohnt sich, bei der Übergabe genau zu sein, denn die beiden Tracks scheitern aus völlig unterschiedlichen Gründen. Der interne Test scheitert an der Konfiguration: an einem Link, den es noch gar nicht gab, an einem Konto, das sich nie angemeldet hat, an einem Zeitfenster für die Verteilung, das niemand abgewartet hat. Das lässt sich durch sorgfältiges Lesen lösen, und dafür sind die ersten zwei Drittel dieses Beitrags da.

Der geschlossene Test scheitert an Menschen. Googles veröffentlichte Zahlenbedingung lautet: mindestens 12 Tester, die über die letzten 14 Tage fortlaufend für den geschlossenen Test angemeldet waren. In der Praxis heißt das zwölf Menschen, die beitreten und in Woche zwei noch da sind. Unabhängig von dieser Zahl wollen Sie, dass diese Tester den Build installieren und sinnvoll nutzen, denn Google fragt bei der Prüfung des Antrags auf Produktionszugriff nach Engagement, Feature-Nutzung und Feedback. Keine der beiden Hälften ist ein Dokumentationsproblem, und kein noch so gutes Wissen über die Console löst sie. Die meisten Entwickler merken das genau in dem Moment, in dem sie den internen Test abschließen und feststellen, dass sich an der Anforderung überhaupt nichts bewegt hat.

Den geschlossenen Test selbst machen oder abgeben

Scrollen Sie die Tabelle seitwärts, um alle Spalten zu sehen

Ja, 25 Tester kosten derzeit weniger als 20. Das ist eine Aktion und kein Tippfehler: Enterprise trägt aktuell den größten Rabatt der drei Pläne und hat damit auch die niedrigsten Kosten pro Tester, rund $1.12 gegenüber $1.50 bei Professional. Beide Pläne führen denselben geschlossenen Test durch; dass sich die Reihenfolge umdreht, liegt allein an der Aktion. Den aktuellen Stand zeigt die Preisseite, falls sich seit diesem Text etwas geändert hat.

Über 7.400+ Apps in 120+ Ländern halten wir eine Erfolgsquote von 99.9% bei der Anforderung an den geschlossenen Test. Was wir Ihnen nicht sagen werden: dass eine Genehmigung garantiert ist. Google prüft den Antrag auf Produktionszugriff nach eigenen Maßstäben und kann weitere Tests verlangen, und wer Ihnen ein bestimmtes Ergebnis verspricht, beschreibt etwas, das er nicht kontrolliert. Wozu wir uns verpflichten, ist der Teil, den wir kontrollieren: Geht der Test nicht durch, bekommen Sie einen kostenlosen neuen Test oder eine vollständige Rückerstattung.

Häufige Fragen zum internen Test

Fazit