--- title: "Google-Play-Test: 12 Tester, 14 Tage, im Alleingang" description: "Google verlangt etwas Einfaches, nur einschüchternd formuliert: Bevor Sie den Produktionszugang beantragen können, muss Ihre App einen geschlossenen Test mit mi" canonical_url: "https://de.goodbarber.com/blog/geschlossener-test-bei-google-play-12-tester-14-tage-—-und-sie-ganz-allein-a1445/" lang: de date: 2026-09-11 last_updated: 2026-09-11 --- # Google-Play-Test: 12 Tester, 14 Tage, im Alleingang [Zurück](/blog/mach-es-r13/) # Geschlossener Test bei Google Play: 12 Tester, 14 Tage — und Sie ganz allein Written by [Florian Luccioni](https://de.goodbarber.com/blog/author/flo-luccioni/) on Freitag 11 September 2026 ## Seit November 2023 verlangt Google von jedem neuen persönlichen Entwicklerkonto einen geschlossenen Test mit mindestens 12 Testern, die 14 Tage lang durchgehend angemeldet bleiben — bevor überhaupt über eine Veröffentlichung in der Produktion gesprochen wird. Wenn Sie Ihre App allein bauen, klingt das nach einer Mauer: zwölf Menschen, vierzehn Tage, und niemand zur Hand. Dieser Leitfaden nimmt die Regel Schritt für Schritt auseinander: die .aab-Datei holen, mehr als das Minimum an Testern gewinnen, den Zugang über eine Google-Gruppe automatisieren, die zwei Wochen durchhalten, ohne Ihr Umfeld zu zermürben, und den Abschlussfragebogen im ersten Anlauf bestehen. ## Die Google-Regel in einer Minute ![](https://cmsphoto.ww-cdn.com/superstatic/129568/art/grande/97993743-68226842.jpg?v=1789121034.9476748) Google verlangt etwas Einfaches, nur einschüchternd formuliert: Bevor Sie den Produktionszugang beantragen können, muss Ihre App einen geschlossenen Test mit **mindestens 12 durchgehend angemeldeten Testern über mindestens 14 Tage** hinter sich haben. | Frage | Antwort | | ------------------------------------- | --------------------------------------------------------------------------------------- | | Wen betrifft es? | **Persönliche** Entwicklerkonten, die ab dem 13. November 2023 erstellt wurden | | Wen nicht? | **Organisationskonten** und persönliche Konten von vor diesem Datum | | Wie viele Tester? | Mindestens 12, gleichzeitig | | Wie lange? | 14 Tage, zusammenhängend | | Was den Zähler zurücksetzt | Ein Tester, der das Programm verlässt. Kommt er zurück, beginnen seine 14 Tage von vorn | | Was den nächsten Schritt freischaltet | Die Schaltfläche **Apply for production** im Dashboard der Play Console | | Antwortzeit von Google | In der Regel sieben Tage oder weniger | Quelle: [Play Console Help — App testing requirements for new personal developer accounts](https://support.google.com/googleplay/android-developer/answer/14151465), abgerufen am 11. September 2026. Zwei Klarstellungen, die viel Anspannung nehmen. Erstens zählt **die Anmeldung Ihrer Tester, nicht Ihre Builds**: Wenn Sie während der 14 Tage eine neue Version auf den geschlossenen Track laden, setzt das nichts zurück. Zweitens sind es tatsächlich 12 angemeldete **Google-Konten** — nicht 12 Geräte und schon gar nicht 12 Fünf-Sterne-Bewertungen. ## Das ist keine Prüfung, das ist ein Häkchen Die Regel wird als Urteil über die Qualität der App erlebt. Sie ist keines. Google verlangt nicht, dass Ihr Launch gelingt; Google prüft, ob Ihre App auf echten Telefonen in echten Händen lief und ob Sie erzählen können, was dabei passiert ist. Ihre Retention bewertet niemand. Auch die eigentlichen Kosten sind nicht die 14 Tage. Es sind die Prüfungen drumherum: bis zu sieben Tage, bis der geschlossene Track freigegeben ist und überhaupt jemand etwas installieren kann, dann in der Regel sieben Tage oder weniger für den Produktionsantrag und noch einmal so lange für die Produktionsversion selbst. **Rechnen Sie mit vier bis sechs Wochen zwischen dem ersten Klick und der öffentlichen App** — und richten Sie Ihre Kommunikation danach aus, nicht nach der Zahl 14. Bleibt die andere Lesart der Einschränkung. Zwölf Menschen, die Ihre App zwei Wochen lang benutzen, sind der Nutzertest, den Sie allein nie organisiert hätten und den die meisten Solo-Projekte nie bekommen. Sie werden erfahren, wo Leute auf dem ersten Screen hängen bleiben, welches Wort in Ihrem Menü ihnen nichts sagt und ob Ihre App ein Android-Gerät von 2019 mit 8 % Akku überlebt. Google zwingt Sie zu dem, was Sie ohnehin hätten tun sollen. ## Schritt 1 — Die .aab-Datei aus GoodBarber holen Google erwartet ein **Android App Bundle** (`.aab`), kein APK. Diesen Teil übernimmt die Plattform vollständig. Bevor Sie irgendetwas einreichen: Erzeugen Sie die **Ad-Hoc-Version** Ihrer Android-App und installieren Sie sie auf Ihrem eigenen Telefon. Das ist Ihr letztes Sicherheitsnetz — was Sie in der Vorschau des Back-office nicht sehen, sehen Sie dort. Danach im Back-office: **Sales Channel > Android App > Update**, dann **Submit my app**. Die Seite **Submission to Google Play** öffnet sich und gibt Ihnen Ihre `.aab` mit einem Klick. Legen Sie sie griffbereit ab, Sie laden sie gleich hoch. *(Sowohl das GoodBarber-Back-office als auch die Play Console sind lokalisiert; die Menüpunkte erscheinen in Ihrer Kontosprache. Hier stehen sie auf Englisch, so wie Googles eigene Dokumentation sie benennt.)* Sie öffnen weder Android Studio noch Gradle noch eine Kommandozeile. GoodBarber kompiliert ein natives Android-Binary in Kotlin und übergibt es Ihnen hochladefertig — genau die Datei, die die Play Console erwartet. Ein Detail, das später im Ablauf Zeit spart: Die Compiler binden eine Bibliothek nur dann ein, wenn die zugehörige Funktion in Ihrem Back-office aktiviert ist. Schalten Sie sie ab, kompiliert die Plattform neu, und die Bibliothek ist aus dem Binary verschwunden. Der Abschnitt **Data safety** der Play Console — der, vor dem Solo-Entwickler am meisten zurückschrecken — beschreibt damit, was Ihre App tatsächlich tut, und nicht ein Paket generischer SDKs, das der Builder standardmäßig mitliefert. **Sechs Prüfungen, bevor Sie den geschlossenen Track anlegen** 1. **Die Ad-Hoc-Version läuft auf einem echten Android-Gerät.** Nicht nur in der Vorschau. 2. **Die Grafiken liegen bereit**: Icon 512 × 512 px, Feature-Grafik 1024 × 500 px und 2 bis 8 Smartphone-Screenshots. 3. **Der Play-Store-Eintrag ist ausgefüllt**: Name, Kurzbeschreibung, vollständige Beschreibung, Kategorie, Kontakt-E-Mail. 4. **Der Bereich App content ist vollständig**: Datenschutzerklärung, Datensicherheit, Werbung, Zielgruppe. 5. **Die Länder und Regionen des geschlossenen Tracks sind ausgewählt** — und das ist Falle Nummer eins. Die Play Console geht nach dem **Land des Google-Kontos** des Testers, nicht danach, wo er sich aufhält. Ihr Cousin in Österreich mit einem österreichischen Google-Konto sieht nichts, wenn Sie nur Deutschland angehakt haben. Im Zweifel haken Sie alle Länder an: Ein geschlossener Track ist ohnehin nur für Ihre Tester sichtbar. 6. **Der Feedback-Kanal ist eingetragen** (eine E-Mail-Adresse oder eine URL). Google verlangt ihn, und über ihn kommt das Material für den Abschlussfragebogen herein. Die vollständige Anleitung Bildschirm für Bildschirm steht in unserem Hilfebereich: [Publish your app on Google Play with a Personal account](https://www.goodbarber.com/help/shop/publish-your-android-app-yourself-solo-r62/publish-your-app-on-google-play-with-a-personal-account-a513/) (auf Englisch). ## Schritt 2 — 15 bis 20 Tester finden, wenn Sie kein Netzwerk haben Zielen Sie auf 15 bis 20 Personen. Nicht aus Übereifer, sondern aus Arithmetik. Von zehn Menschen, die Ja sagen, gibt Ihnen einer eine Adresse, die nicht sein Google-Konto ist, ein zweiter klickt nie auf den Anmeldelink, und ein dritter verlässt das Programm am sechsten Tag beim Aufräumen seines Telefons. Starten Sie mit exakt 12, merken Sie das am zwölften Tag — und fangen von vorn an. Eines sollten Sie klarhaben, bevor Sie jemanden ansprechen: **Sie bitten um eine Anmeldung, nicht um eine Zumutung.** Ihre Tester installieren die App wie jede andere aus dem Play Store, nach einem Klick auf einen Link. Keine Datei von Hand, kein obskures Vorgehen, kein Risiko für ihr Telefon. Wenn das im ersten Satz steht, verdoppelt sich die Zusagequote. | Kanal | Was er bringt | Was Sie hineingeben müssen | | ------------------------------------------------------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------- | | **Ihr direktes Umfeld** (Familie, Freunde, Kollegen) | 5 bis 8 verlässliche Anmeldungen in 48 Stunden | Die **exakte Gmail-Adresse**, nicht die Firmenadresse | | **r/AndroidAppTesters** und **r/AndroidClosedTesting** auf Reddit | Die Ergänzung, die Sie über 12 hinaus bringt | Gegenseitigkeit: Sie testen deren App, die testen Ihre — 14 Tage auf beiden Seiten | | **Discord-Server und Telegram-Gruppen für Testtausch** | Dieselbe Logik, höheres Tempo | Dieselbe Disziplin: Eine Zusage wird eingehalten | | **Die Community Ihres Themas** (No-Code-Foren, Facebook-Gruppen Ihrer Branche, Fach-Slacks) | Das mit Abstand nützlichste Feedback | Eine echte Nachricht, keine Anzeige. Sagen Sie, was die App tut und warum es sie gibt | | **Eine Warteliste-Seite oder der PWA-Link Ihrer App** | Eine Liste, die Sie beim Launch wiederverwenden | Ein Formular mit einem einzigen Feld und der Link zur Web-Version Ihrer App | Zwei ehrliche Warnungen zu diesen Kanälen. **r/androiddev ist nicht der Ort zum Rekrutieren.** Das ist ein technisches Diskussionsforum, Testanfragen werden dort entfernt. Die oben genannten spezialisierten Communities existieren genau deshalb, weil diese Google-Regel den Bedarf geschaffen hat. **Testtausch füllt den Zähler, nicht den Fragebogen.** Zwölf Entwickler, die Ihre App installieren, damit Sie deren App installieren, erfüllen die Zahl — der Produktionsantrag fragt aber, welches Feedback Sie erhalten und was Sie geändert haben. Mischen Sie: ein paar Tausch-Tester, um die Schwelle zu erreichen, und ein paar Menschen, die Ihr Thema wirklich betrifft, damit Sie etwas zu berichten haben. Und wenn Sie Letztere in einer Community suchen: erst geben, dann fragen. Eine Nachricht, die nur einen Link platziert, wird gelöscht — zu Recht. **Die Nachricht, die ein Ja bekommt** Kurz, präzise, mit ehrlich genanntem Aufwand. Etwa so: *„Ich bringe eine App für [Thema] heraus. Google verlangt 12 Menschen, die sie installieren und 14 Tage behalten. Konkret: ein Klick auf einen Link, Installation aus dem Play Store, und Sie lassen sie zwei Wochen auf dem Telefon. Ich brauche die Gmail-Adresse Ihres Android-Telefons. Wenn Sie sie zwei- oder dreimal öffnen und mir sagen, was Sie stört, ist das perfekt."* Wenn Ihr GoodBarber-Tarif die nativen Apps enthält, enthält er auch die **PWA**, die aus derselben Konfiguration entsteht. Schicken Sie diesen Web-Link, bevor Sie um die Anmeldung bitten: Menschen sagen sehr viel leichter Ja zu einer App, die sie schon im Browser laufen gesehen haben. ## Schritt 3 — Den Zugang über eine Google-Gruppe automatisieren Die Play Console akzeptiert zwei Wege, Ihre Tester zu benennen: eine Liste von E-Mail-Adressen oder die Adresse einer **Google-Gruppe**. Nehmen Sie die Gruppe, aus einem sehr handfesten Grund: Bei einer Liste zwingt Sie jeder neue Tester dazu, den Track erneut zu öffnen, die Liste zu bearbeiten und zu speichern. Bei einer Gruppe fügen Sie einmal eine Adresse in der Play Console ein und verwalten Zugänge danach in Google Groups. Über drei Wochen versetztes Rekrutieren sind das ein Dutzend Wege weniger. 1. Gehen Sie auf [groups.google.com](https://groups.google.com) und legen Sie eine Gruppe an — etwa `tester-meineapp@googlegroups.com`. 2. Erlauben Sie sich in den Zugriffseinstellungen, **Mitglieder direkt hinzuzufügen**: Ihre Tester müssen dann selbst nichts tun. 3. Tragen Sie die Gmail-Adressen ein, sobald Sie sie haben. 4. Öffnen Sie in der Play Console **Test and release > Testing > Closed testing**, dann den Reiter **Testers** Ihres Tracks, und hinterlegen Sie die Gruppe über ihre E-Mail-Adresse. 5. Speichern und **die Änderungen zur Prüfung einreichen**. **Den Fehler „App nicht verfügbar" vermeiden** Das sehen Ihre Tester, wenn sie zu früh klicken — und es ist mit Abstand der entmutigendste Moment der ganzen Aktion: Sie haben die Arbeit gemacht, und die ersten zehn Menschen, die Sie angeschrieben haben, melden zurück, dass es nicht funktioniert. **Die Regel passt in einen Satz: erst veröffentlichen, dann den Link verschicken.** Solange Ihr geschlossener Track den Status **Draft** trägt, prüft Google ihn noch, und der Link führt ins Leere. Warten Sie, bis der Status auf **Closed testing** springt — das ist das Signal, und es kann bis zu sieben Tage dauern. Bleibt die Meldung bestehen, obwohl der Track veröffentlicht ist, liegt es fast immer an einem dieser Punkte: - Der Tester hat den Anmeldelink **Join on Android** nicht geöffnet, bevor er die App im Play Store gesucht hat. - Er ist im Play Store mit einem **anderen Google-Konto** angemeldet als dem, das in Ihrer Gruppe steht. - Das Land seines Google-Kontos gehört nicht zu den im Track angehakten Ländern und Regionen. - Er wurde gerade erst zur Gruppe hinzugefügt und die Verteilung läuft noch: einige Minuten bis einige Stunden abwarten. ## Schritt 4 — 14 Tage durchhalten, ohne Ihr Umfeld zu zermürben Der natürliche Reflex ist, täglich nachzufassen. Das ist der sicherste Weg, dass die Menschen, die Sie mögen, Ihre App deinstallieren. **Drei Nachrichten genügen**, und jede hat eine andere Aufgabe. **Tag 0 — der Link und eine einzige Frage.** Der Anmeldelink, das Vorgehen in zwei Zeilen und eine präzise Frage statt eines „Sag mir, was du davon hältst", das nie beantwortet wird. *„Was verstehen Sie auf dem ersten Screen nicht?"* bringt zehn brauchbare Antworten. **Tag 7 — zeigen, dass sich etwas bewegt.** Das ist der Moment, in dem die App im Kopf Ihrer Tester vom Telefon verschwindet, und genau hier hilft die Plattform. Veröffentlichen Sie neue Inhalte über das CMS: Sie erscheinen sofort in der App, ohne neuen Build und ohne neue Google-Prüfung. Begleiten Sie das mit einer Push-Benachrichtigung an Ihre Tester. Sie haben gerade bewiesen, dass die App lebt, ohne irgendetwas neu einzureichen. Wenn Sie ein echtes Binary-Update ausliefern wollen — ein behobener Fehler, ein überarbeiteter Screen —, gehen Sie zurück zu **Sales Channel > Android App > Update**, holen die neue `.aab` und laden sie als neue Version auf denselben geschlossenen Track. Ihre Tester erhalten sie automatisch, und auch das setzt den 14-Tage-Zähler nicht zurück. **Tag 12 — der letzte Aufruf.** Bitten Sie um ein abschließendes Feedback und vor allem ausdrücklich darum, **bis Tag 15 angemeldet zu bleiben**. Zwei Tage Puffer kosten eine Nachricht und ersparen Ihnen, einen Absprung genau in dem Moment zu entdecken, in dem Sie auf Apply for production klicken wollen. Führen Sie zwischen diesen drei Nachrichten ein Protokoll. Eine Zeile pro Rückmeldung: Datum, wer es gesagt hat, was gesagt wurde, was Sie geändert haben, in welcher Version. Diese Datei ist keine Bürokratie — sie ist wörtlich die Antwort auf den dritten Abschnitt des Fragebogens, mühelos entstanden. ## Schritt 5 — Den Fragebogen für den Produktionszugang bestehen Sind die 14 Tage vorbei, öffnen Sie das **Dashboard** der Play Console und klicken auf **Apply for production**. Google stellt seine Fragen in drei Blöcken. **Ihr geschlossener Test.** Wie Sie Ihre Tester gewonnen haben, wie engagiert sie waren, welches Feedback kam. Bleiben Sie faktisch und in Zahlen: *„24 Personen angesprochen, 17 angemeldet, 15 am Ende der 14 Tage noch angemeldet; gewonnen aus meinem beruflichen Umfeld und aus zwei Android-Tester-Communities; 11 haben die App mehr als dreimal geöffnet."* **Ihre App.** Für wen sie ist, was sie bringt, und eine Schätzung der erwarteten Installationen. Eine bescheidene, begründete Schätzung kommt besser an als eine runde Zahl aus dem Nichts. **Ihre Produktionsreife.** Was das Feedback verändert hat und warum Sie die App für bereit halten. Hier zahlt sich Ihr Protokoll aus: Zitieren Sie zwei oder drei konkrete Rückmeldungen und die Korrektur, die darauf folgte. Die Checkliste vor dem Absenden: - mindestens 12 Tester, die zum Zeitpunkt des Antrags **noch angemeldet** sind; - konkrete Antworten, niemals allgemeine — zwei vage Zeilen sind der häufigste Grund für eine zweite Runde; - echtes Feedback zitiert, nicht zusammengefasst; - mindestens eine konkrete Änderung, die einer Rückmeldung zugeordnet ist, mit der Version, die sie enthält; - keine aufgeblasenen Zahlen: Nennen Sie keine 20 Tester, wenn es 15 waren. Rechnen Sie mit sieben Tagen oder weniger bis zur Antwort, per E-Mail an den Kontoinhaber. Bei Zustimmung geht es zu **Test and release > Production**: Sie legen eine Version an, fügen aus der Bibliothek das zuletzt im geschlossenen Test verwendete App Bundle hinzu und schicken alles in die finale Prüfung. ## Der realistische Zeitplan | Etappe | Einzuplanende Dauer | | ----------------------------------------------- | -------------------------------- | | Play-Store-Eintrag vorbereiten und `.aab` holen | 1 bis 2 Tage | | Google-Prüfung des geschlossenen Tracks | Bis zu 7 Tage | | Tester gewinnen (parallel zur Prüfung) | 3 bis 7 Tage | | Geschlossener Test | Mindestens 14 Tage | | Prüfung des Produktionsantrags | In der Regel 7 Tage oder weniger | | Prüfung der Produktionsversion | In der Regel 7 Tage oder weniger | | **Gesamt** | **4 bis 6 Wochen** | Das Rekrutieren ist der einzige Posten, den Sie wirklich in der Hand haben. Starten Sie damit an dem Tag, an dem Sie den geschlossenen Track zur Prüfung einreichen, nicht an dem Tag, an dem er freigegeben wird: So laufen beide Uhren gleichzeitig. ## Häufige Fragen **Beginnen die 14 Tage mit der Einreichung oder mit der Anmeldung der Tester?** Mit der Anmeldung der Tester. Es braucht 12 **durchgehend** angemeldete Konten über 14 Tage: Tag 1 ist der Tag, an dem sich der zwölfte Tester anmeldet, nicht der Tag, an dem Sie Ihre App zur Prüfung geschickt haben. **Darf ich während des geschlossenen Tests ein Update veröffentlichen?** Ja, es ist sogar zu empfehlen. Sie laden eine neue Version auf denselben Track. Der Zähler folgt der Anmeldung Ihrer Tester, nicht Ihren Builds. **Sind es 12 Tester oder 12 Geräte?** 12 Google-Konten, die für Ihren geschlossenen Track angemeldet sind. Eine Person mit zwei Telefonen bleibt ein Tester. **Ist mein Konto betroffen?** Wenn es ein **persönliches** Entwicklerkonto ist, das ab dem 13. November 2023 erstellt wurde: ja. Konten von vor diesem Datum und **Organisationskonten** unterliegen dieser Anforderung nicht. **Umgeht man die Regel mit einem Organisationskonto?** Technisch ja, aber es ist keine Abkürzung: Ein Organisationskonto setzt eine eingetragene juristische Person und eine geprüfte D-U-N-S-Nummer voraus. Wenn Sie als Privatperson veröffentlichen, bleibt der geschlossene Test der kürzere Weg. Und die Regel hängt am Konto, nicht an der Person, die den Knopf drückt — die Veröffentlichung zu delegieren lässt sie nicht verschwinden. **Gibt es dieselbe Auflage im App Store?** Nein. Apple schreibt weder eine Mindestzahl an Testern noch eine Testdauer vor der Veröffentlichung vor. Der iOS-Weg hat eigene Anforderungen, beschrieben unter [Publish your iOS app yourself (Solo)](https://www.goodbarber.com/help/shop/publish-your-ios-app-yourself-solo-r75/) (auf Englisch). **Und wenn Google meinen Produktionsantrag ablehnt?** Sie können ihn erneut stellen. Gehen Sie die drei Abschnitte durch und ersetzen Sie jede allgemeine Formulierung durch eine Tatsache: eine Zahl, ein zitiertes Feedback, eine datierte Änderung. Eine Ablehnung bestraft fast immer eine vage Antwort, selten die App selbst. **Ich möchte mich damit gar nicht befassen. Geht das?** Ja: Mit der Option [GBTC](https://www.goodbarber.com/help/shop/goodbarber-takes-care-gbtc-publication-service-r80/) (auf Englisch) übernimmt das Team von GoodBarber die Veröffentlichung. Mit einer Einschränkung: Wenn Ihr Entwicklerkonto ein neueres persönliches Konto ist, bleibt die Anforderung von 12 Testern über 14 Tage an dieses Konto gebunden. ## Ihre Testversion ist einen Klick entfernt Der technische Teil dieser Geschichte — eine native Android-App kompilieren, eine regelkonforme `.aab` erzeugen, sie bei jedem Update neu generieren — war vor zehn Jahren das, was die meisten Solo-Entwickler aufhielt. Heute ist es eine Schaltfläche in einem Back-office. Zwischen Ihnen und Google Play stehen noch zwölf Menschen und vierzehn Tage — und Sie wissen jetzt, wie Sie beide bekommen. **Projekt bereit?** Öffnen Sie **Sales Channel > Android App > Update** in Ihrem GoodBarber-Dashboard und holen Sie Ihre `.aab`-Datei. Noch keine App? [Starten Sie kostenlos](https://de.goodbarber.com/create/) — keine Kreditkarte erforderlich. ![Flo Luccioni](https://blog.goodbarber.com/_public/profile/6a/6ac86fe0c44e1457a046324ec18c6897e8e94b27-default.jpg) Über den Autor[Flo Luccioni](https://de.goodbarber.com/blog/author/flo-luccioni/)PWA Developer I’m a frontend developer on GoodBarber’s Progressive Web Apps team, where we build the rendering engine of our no-code platform for browsers. I work on the shared UI and performance foundations that make our users’ no-code experience into fast, polished and accessible web products that feel native on every device. [Mehr erfahren](https://de.goodbarber.com/blog/author/flo-luccioni/) [![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/floluccioni/)