Google Play „Weitere Tests erforderlich“: Was die E-Mail bedeutet und wie du erneut beantragst (2026)

Die Google-Play-E-Mail „Für den Zugriff auf die Google-Play-Produktion sind weitere Tests erforderlich“ (im Original: „More testing required to access Google Play production“) bedeutet, dass Google deinen Antrag auf Produktionszugriff abgelehnt hat. Das ist kein Richtlinienverstoß und deine App wird nicht gesperrt. Es kostet dich aber Zeit: Du brauchst einen weiteren 14-tägigen Block geschlossener Tests, bevor du erneut beantragen kannst. Dieser Leitfaden erklärt jeden Grund in der E-Mail, listet auf, was du in den zusätzlichen 14 Tagen ändern solltest, und zeigt, wie du den Fragebogen so umschreibst, dass dein zweiter Antrag dein letzter ist. Falls du noch keinen geschlossenen Test gestartet hast, beginne mit unserem Testplan für 12 Tester und 14 Tage.

Was bedeutet „Weitere Tests erforderlich“ für den Google-Play-Produktionszugriff?

Es bedeutet, dass ein Google-Prüfer deinen Antrag auf Produktionszugriff gelesen und entschieden hat, dass dein geschlossener Test nicht genug Belege geliefert hat, dass die App bereit für die Öffentlichkeit ist. Produktion und Vorregistrierung bleiben gesperrt, bis du weiter testest und erneut beantragst.

Stand November 2026 gelten Googles Anforderungen an App-Tests für private Entwicklerkonten, die nach dem 13. November 2023 erstellt wurden. Diese Konten müssen „einen geschlossenen Test für ihre App mit mindestens 12 Testern durchführen, die mindestens 14 Tage lang ununterbrochen teilgenommen haben“. Das Erreichen dieser Zahlen erlaubt dir nur, den Antrag zu stellen. Der Antrag selbst wird geprüft, und Google nennt zwei Gründe, warum weitere Tests nötig sein können: „weniger als 12 teilnehmende Tester oder unzureichendes Tester-Engagement während des Testzeitraums“. Laut Google „dauert die Prüfung in der Regel sieben Tage oder weniger, kann aber gelegentlich länger dauern“, und der Kontoinhaber erhält die Entscheidung per E-Mail.

Was bedeutet jeder Grund in der Ablehnungs-E-Mail?

Jede Zeile in der E-Mail weist auf eine bestimmte Lücke hin: Tester, die die App nicht wirklich genutzt haben, ein Test ohne sichtbare Änderungen als Reaktion auf Feedback oder Antworten im Fragebogen, die zu vage für eine Beurteilung sind. Die E-Mail kann einen, zwei oder alle drei Gründe nennen.

Entwickler, die die E-Mail öffentlich gepostet haben, zitieren dieselben Gründe: „Testers were not engaged with your app during your closed test“ (Tester haben sich während deines geschlossenen Tests nicht mit deiner App beschäftigt), „You didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app“ (du hast die Best Practices für Tests nicht befolgt, wozu das Sammeln von Nutzerfeedback und das Reagieren darauf mit App-Updates gehören kann) sowie Antworten zur App, zum geschlossenen Test oder zur Produktionsreife, die „unvollständig oder unzureichend“ waren. Die abschließende Anweisung lautet: „Bevor du erneut beantragst, teste deine App per geschlossenem Test weitere 14 Tage mit echten Testern.“ Google veröffentlicht nicht, wie Engagement gemessen wird. Die Tabelle ordnet deshalb jedem Grund den passenden Text auf Googles eigener Hilfeseite und eine Lösung zu.

Was solltest du direkt nach der Ablehnung tun?

Lass den geschlossenen Test weiterlaufen, sag deinen Testern, dass sie teilnehmen bleiben sollen, und veröffentliche innerhalb weniger Tage einen neuen Build im geschlossenen Track. Googles Seite sagt, dass du bei fehlender Genehmigung „deinen geschlossenen Test möglicherweise weiterführen musst“. Wer ihn abbaut und einen neuen startet, wirft seine Testerbasis weg.

1. Entferne weder den geschlossenen Track noch deine Testerliste. Google warnt: „Wenn ein Tester austritt und später wieder beitritt, müssen die 14 Tage aufeinanderfolgend sein.“ Jeder Tester, der jetzt geht, startet seine eigene Uhr neu.
2. Schreib jedem Tester. Erkläre, dass der Test weitere 14 Tage läuft, dass alle teilnehmen bleiben müssen und was sie in dieser Runde ausprobieren sollen.
3. Prüfe deine Testerzahl in der Play Console. Ersetze alle, die die App nie installiert haben, durch Leute, die sie tatsächlich nutzen. Freunde, die installieren und die App nie öffnen, sind die übliche Ursache für den Grund „nicht engagiert“.
4. Richte einen einzigen Feedback-Kanal ein. Google schlägt einen Gruppenchat vor; ein geteiltes Formular funktioniert auch. Egal, wofür du dich entscheidest: Speichere jede Nachricht mit Datum.
5. Schreib eine Aufgabenliste, die jede Hauptfunktion abdeckt: Registrierung, die Kernaktion, Einstellungen, Käufe (mit Lizenztestern, falls die App Abrechnung nutzt) sowie alle Offline- oder Benachrichtigungsabläufe.
6. Veröffentliche in der ersten Woche ein Update im geschlossenen Track, das etwas von einem Tester Gemeldetes behebt, und nenne die Korrektur in den Versionshinweisen. Plane ein zweites Update vor Tag 14.
7. Führe den Pre-Launch-Bericht aus und behebe die Abstürze und Barrierefreiheitswarnungen, die er findet.
8. Prüfe vor dem erneuten Antrag, ob Altersfreigabe, Zielgruppe und das Formular zur Datensicherheit korrekt sind. Wenn die App einen Login erfordert, gib wie von Google verlangt „gültige, funktionierende Anmeldedaten“ an.

Wenn deine App vor dem Livegang außerdem ein höheres Target SDK braucht, erledige das im selben Zeitfenster. Unser Leitfaden zu Target API Level 36 behandelt die Frist zum 1. November 2026.

Wie schreibst du die Antworten im Fragebogen zum Produktionszugriff neu?

Ersetze allgemeine Aussagen durch Konkretes: welche Funktionen Tester genutzt haben, wie viele Meldungen eingingen, wie du sie gesammelt hast, welche Version was behoben hat und welche Belege zeigten, dass die App stabil war. Jede Antwort sollte etwas sein, das nur ein Entwickler schreiben kann, der wirklich getestet hat.

Du öffnest das Formular im Dashboard der Play Console über Produktionszugriff beantragen (Apply for production). Es hat drei Teile: deinen geschlossenen Test, deine App und deine Produktionsreife. Der Fortschritt geht verloren, wenn du einen Teil verlässt, bevor du auf Weiter klickst. Entwirf deine Antworten deshalb zuerst in einem Dokument. Ein Entwickler auf itch.io berichtete von „einer Grenze von 300 Zeichen pro Antwort“ – ein weiterer Grund, vorab zu entwerfen und zu kürzen. Die Antworten in Teil 2 werden nicht öffentlich angezeigt und beeinflussen die Sichtbarkeit deiner App nicht.

Durchgerechnetes Beispiel für eine hypothetische Habit-Tracker-App. Die schwachen Antworten sind typisch für Anträge, die mit „unvollständig oder unzureichend“ zurückkommen:

Was haben andere Entwickler nach einer Ablehnung wegen „weiterer Tests“ berichtet?

Die öffentlichen Berichte folgen einem Muster: Tester, die teilnahmen, aber nie Feedback schickten, führten zur Ablehnung, während eine kleine Gruppe, die Feedback gab und die App sich verändern sah, genehmigt wurde. Die Anzahl der Tester war weniger wichtig als Belege für echte Nutzung.

• In der MIT App Inventor Community berichtete der Entwickler shigeki_suzuki im Juli 2024, dass die App Season Clock über eine Tester-Tausch-App 20 Tester für 14 Tage erreichte und dann „More testing required to access Google Play production“ mit „Testers were not engaged with your app during your closed test“ erhielt. Laut dem Beitrag wusste der Entwickler nicht, wer die Tester waren, und hatte kein Feedback bekommen, sodass weder der Testverlauf noch die Änderungen beschrieben werden konnten. Der Test musste wiederholt werden.
• Im Adalo-Forum meldete der Nutzer siang32195 im August 2024 dieselbe Meldung „More testing required“ nach dem Einsatz angeworbener Tester und fragte, wie man überprüfen kann, ob Tester die App wirklich genutzt haben. Die Antwort schlug Zeiterfassungstools oder einen schriftlichen Bericht vor, der die Testszenarien jedes Testers auflistet. Der Thread verrät nicht, ob der zweite Antrag erfolgreich war.
• Ein Solo-Spieleentwickler auf itch.io hatte „gerade so 12 Tester“, schrieb aber, „mehrere Updates für das Spiel veröffentlicht“ und „alles festgehalten“ zu haben, „was ich aus meinen Gesprächen mit den Testern mitnehmen konnte“. Diese Aufzeichnungen flossen in den Antrag ein, mit dem Ergebnis: „Innerhalb von 36 Stunden nach dem Absenden des Antrags erhielt ich den Produktionszugriff.“

Der Vergleich: 20 Tester ohne nachvollziehbares Feedback wurden abgelehnt, während 12 Tester mit dokumentiertem Feedback und Updates genehmigt wurden. Beantrage erneut, wenn deine Notizen jedes Feld im Fragebogen konkret beantworten können – nicht schon dann, wenn der Tageszähler 14 erreicht.

Wann solltest du erneut auf „Produktionszugriff beantragen“ klicken?

Beantrage erneut, sobald mindestens 12 Tester weitere 14 aufeinanderfolgende Tage teilgenommen haben und du in dieser Zeit Updates auf Basis von Feedback veröffentlicht hast. Googles Seite nennt keine Wartezeit, aber ein Antrag mit denselben Belegen bekommt wahrscheinlich dieselbe Antwort.

• Mindestens 12 teilnehmende Tester ohne Austrittslücken für weitere 14 aufeinanderfolgende Tage (peile als Puffer 15 oder mehr an)
• Mindestens zwei Releases im geschlossenen Track seit der Ablehnung, jeweils mit Versionshinweisen, die eine von Testern gemeldete Korrektur nennen
• Ein datiertes Feedback-Protokoll mit Zahlen nach Typ (Fehler, UX, Wünsche) und wie jeder Eintrag gesammelt wurde
• Tester, die jede Hauptfunktion genutzt haben, einschließlich Login, Käufen und Benachrichtigungen, wo relevant
• Ein Pre-Launch-Bericht ohne ungelöste Abstürze
• Korrekte Altersfreigabe, Zielgruppe und Formular zur Datensicherheit sowie funktionierende Anmeldedaten für Prüfer
• Fragebogen-Antworten, in einem Dokument vorformuliert, mit Funktionen, Zahlen und Versionsnummern

Googles Seite warnt außerdem: „Das Einreichen nicht konformer Apps in der Erwartung, dass Prüfer Probleme finden, führt zu Ablehnungen, Prüfverzögerungen und längeren Einspruchsverfahren.“ Behebe Richtlinienprobleme also vor dem Antrag, nicht danach. Wenn du die Einrichtung der Play Console, den Plan für den geschlossenen Test und den Antrag lieber abgeben möchtest: Unser App-Store-Einreichungsservice deckt beide Stores für $599 ab. Gebühren für Entwicklerkonten kommen separat hinzu.