Nein: es setzt nie zurück
Aktualisieren Sie frei; ein neuer Build lässt Ihre 14-Tage-Uhr weiterlaufenEs gibt keine Regel, dass ein neuer Release die Uhr des geschlossenen Tests zurücksetzt. Die 14-Tage-Anforderung misst, ob mindestens 12 Tester fortlaufend angemeldet bleiben: sie hat nichts mit Ihrer App-Version, dem Version Code oder der Anzahl der hochgeladenen Builds zu tun.
Ihre Zahl angemeldeter Tester fällt unter 12.
Wenn sich Tester formell abmelden und Sie unter das Minimum fallen, bricht die fortlaufende Serie: nicht weil Sie geupdatet haben, sondern weil Sie unter 12 gerutscht sind.
Kurze Antwort
Nein: ein Update Ihrer App während des 14-tägigen geschlossenen Tests (closed testing) setzt die Uhr nicht zurück, also können Sie so oft neue Builds pushen, wie Sie brauchen. Einen neuen Build (AAB) auf Ihren bestehenden Test-Track des geschlossenen Tests hochzuladen startet die 14 Tage nicht neu. Die Uhr hängt daran, mindestens 12 Tester fortlaufend angemeldet zu halten, nicht an App-Version, Version Code oder Signing Key. Das fortlaufende Fenster bricht nur, wenn Ihre Zahl angemeldeter Tester unter 12 fällt oder sich Tester formell abmelden. Updates pushen ist sicher, und Google ermutigt dazu sogar. PrimeTestLab hält mindestens 12 echte Tester fortlaufend angemeldet, damit Ihre Uhr weiterläuft, während Sie Korrekturen ausliefern.
Es ist eine der häufigsten Ängste im geschlossenen Test: Sie sind mitten im 14-Tage-Fenster, entdecken einen Bug und erstarren, aus Angst, dass ein Fix-Upload den Fortschritt löscht und die zwei Wochen von vorn beginnt. Das tut es nicht. Die 14-Tage-Uhr beobachtet Ihre Tester, nicht Ihre Builds. Dieser Leitfaden trennt genau, was den Timer des geschlossenen Tests zurücksetzt und was nicht, gibt Ihnen zwei interaktive Tools, um jede Aktion selbst zu prüfen, und erklärt, warum Google Updates aktiv sehen will. Stand: 30. Juni 2026.
In diesem Leitfaden
Setzt ein App-Update die 14-Tage-Uhr des geschlossenen Tests zurück?
Nein. Das ist die häufigste Sorge von Entwicklern im Testfenster, und die Antwort ist beruhigend: ein neues App Bundle auf Ihren bestehenden Test-Track des geschlossenen Tests hochzuladen setzt die Anforderung von 14 fortlaufenden Tagen nicht zurück.
Die 14-Tage-Uhr hängt an Ihren Testern, nicht an Ihrem Build. Googles Anforderung misst, ob Sie mindestens 12 angemeldete Tester über die letzten 14 Tage fortlaufend gehalten haben. Versionsnummer, wie oft Sie ein neues AAB hochladen und was in den Release Notes steht, sind schlicht kein Teil dieses Timers.
Genau diese Frage taucht immer wieder in der Google Play Developer Community auf: ob ein neuer Release für den geschlossenen Test die 14 Tage zurücksetzt, oder ob der Zähler bei einem App-Update neu startet. Statt Forenantworten wörtlich zu zitieren, die wir nicht unabhängig verifizieren konnten, stützt sich dieser Leitfaden auf Googles eigene Play Console-Hilfe, die die Anforderung rein über angemeldete Tester und Zeit definiert, nie über Build-Uploads.
Bei den über 7.400+ Apps, die wir durch diesen Prozess begleitet haben, hat ein routinemäßiges Build-Update auf demselben Track des geschlossenen Tests allein noch nie eine Uhr zurückgesetzt. Unsicher bei einer bestimmten Aktion? Nutzen Sie den Checker unten: wählen Sie, was Sie vorhaben, und er sagt sofort, ob es Ihre 14-Tage-Uhr berührt.
Welche Aktion bereitet Ihnen Sorgen?
Basierend auf Googles veröffentlichter Play Console-Anforderung (angemeldete Tester × fortlaufende Tage) plus weit berichteter Entwicklererfahrung. Die zwei community-markierten Risiken sind entsprechend gekennzeichnet.
Was setzt den 14-Tage-Timer wirklich zurück?
Das fortlaufende 14-Tage-Fenster versteht man am besten als Konsistenzprüfung, nicht als passiven Kalendercountdown. Google will sehen, dass Sie mindestens 12 angemeldete Tester ohne Unterbrechung gehalten haben. Es gibt nur zwei bestätigte Auslöser, die diese Kontinuität brechen:
Angemeldete Zahl fällt unter 12
Wenn sich auch nur ein Tester abmeldet und Sie auf 11 fallen, kann die fortlaufende Serie brechen und die vollen zwei Wochen starten neu. Das ist der häufigste Grund, warum DIY-Entwickler scheitern.
Tester melden sich formell ab
Ein Tester meldet sich ab, indem er den Testlink öffnet und den Test verlässt. Das ist etwas anderes als Deinstallieren, und es schadet der Uhr nur, wenn es Sie unter 12 drückt.
Einen neuen Build hochzuladen steht nicht auf dieser Liste. Ebenso wenig ein Tippfehler im Store-Listing, Feedback eines Testers oder ein Crash auf dem Gerät eines Testers: letzteres ist der ganze Sinn des Tests. Der Simulator unten macht den Unterschied klar: drücken Sie den Update-Button so oft Sie wollen und nichts bewegt sich; verlieren Sie Tester unter 12 und die Serie bricht zusammen.
Was die Uhr NICHT zurücksetzt
Neues AAB auf denselben Track hochladen
Release Notes oder Store-Listing bearbeiten
Ein Tester sendet Feedback
Ihre App stürzt auf dem Gerät eines Testers ab
Version Code oder Versionsname erhöhen
Ein Tester deinstalliert ohne Abmeldung
Wie pushe ich ein Update in einen geschlossenen Test?
Ein Update zu pushen ist derselbe Ablauf wie bei Ihrem allerersten Release, mit einem wichtigen Unterschied: Sie erstellen den neuen Release auf dem selben Test-Track des geschlossenen Tests, in den Ihre Tester bereits angemeldet sind. Sie starten keinen neuen Test, Sie fügen dem laufenden Test einen Build hinzu, und genau deshalb tickt die 14-Tage-Uhr weiter. Hier die zwei Schritte in der Play Console.
Neuen Release auf Ihrem Track des geschlossenen Tests erstellen Testing > Closed testing > Manage track
Öffnen Sie den Track des geschlossenen Tests, den Sie laufen lassen, klicken Sie auf Create new release und laden Sie Ihr aktualisiertes App Bundle (AAB) hoch. Fügen Sie kurze Release Notes hinzu, was sich geändert hat, und speichern Sie. Bleiben Sie auf demselben Track: das erhält Ihr fortlaufendes 14-Tage-Fenster.
Update prüfen und ausrollen Review release > Start roll-out
Gehen Sie über Next und Review release, starten Sie dann den Roll-out auf Ihren Track des geschlossenen Tests (und klicken Sie bei Aufforderung in der Publishing overview auf Send changes for review). Sobald der neue Release live ist (Google merkt an, dass eine veröffentlichte Änderung bis zu mehrere Stunden brauchen kann, bis sie Tester erreicht), aktualisieren sich ihre Geräte automatisch auf den neuen Build: keine Neuinstallation und keine zweite Anmeldung.
Das setzt Ihre Uhr nie zurück. Weil Sie auf denselben Track des geschlossenen Tests releasen, in den Ihre Tester bereits angemeldet sind, läuft das fortlaufende 14-Tage-Fenster unter dem neuen Build weiter. Sie fügen einen Build hinzu, starten keinen neuen Test: das ist die ganze Antwort auf die Frage, um die dieser Leitfaden gebaut ist.
Was ist der Unterschied zwischen eingeladenen und angemeldeten Testern?
Diese Unterscheidung stolpert mehr Erstveröffentlicher als jede andere, und sie ist der Schlüssel, warum Builds für die Uhr irrelevant sind. Googles System führt Tester durch einen Trichter, und nur die späteren Stufen zählen.
Eingeladen
Sie haben eine E-Mail-Adresse zu Ihrer Testerliste oder Google Group hinzugefügt. Mehr ist noch nicht passiert.
Angemeldet
Sie haben Ihren Link zum Teilen geöffnet, sich mit ihrem Google-Konto angemeldet und „Betatester werden“ gewählt. Das ist der Status, den die 14-Tage-Uhr misst.
Installiert und aktiv
Sie haben die App heruntergeladen und nutzen sie weiter. Das ändert die Rohzahl nicht, aber genau das gewichtet Google für Engagement beim Produktionszugriff.
Wie Googles Dokumentation klar macht, reicht es nicht, eine E-Mail hinzuzufügen. Jeder Tester muss den Link zum Teilen öffnen, sich authentifizieren und ausdrücklich Tester werden, bevor er zählt. Genau deshalb setzt ein App-Update Ihren Fortschritt nie zurück: Ihre Tester verlassen den angemeldeten Status nie, also läuft die Uhr über jeden neuen Build weiter. Den vollständigen Ablauf finden Sie in unserem Leitfaden, wie Sie Tester korrekt einladen.
Tipp aus Tausenden von Tests: führen Sie Ihre Tester über eine Google Group statt über eine statische E-Mail-Liste. Mit einer in die Play Console eingebundenen Group tauschen Sie einen Tester per Group-Edit aus: der Link zum Teilen bleibt gleich und der Track läuft weiter. So entfällt das Risiko, aktive Tester versehentlich zu löschen, während Sie die Liste anpassen: eines der wenigen Dinge, die Ihre Serie wirklich brechen können.
Wie lautet die exakte Google-Anforderungsformulierung?
Googles offizielle Play Console-Hilfeseite „Anforderungen an App-Tests für neue private Entwicklerkonten“ formuliert es präzise:
„Wenn Sie ein neu erstelltes privates Entwicklerkonto haben, müssen Sie einen geschlossenen Test für Ihre App mit mindestens 12 Testern durchführen, die mindestens während der letzten 14 Tage fortlaufend angemeldet waren.“
Google Play Console Help · Antwort 14151465Und separat, im Moment, in dem Sie Produktionszugriff beantragen:
„Mindestens 12 Tester müssen an Ihrem geschlossenen Test teilnehmen, wenn Sie den Produktionszugriff beantragen. Diese Tester müssen außerdem über die letzten 14 Tage fortlaufend angemeldet gewesen sein.“
Google Play Console Help · Antwort 14151465Google stellt in eigenen Worten auch klar, dass die Tage aufeinanderfolgen müssen: es zählt keine Tester, die sich angemeldet, weniger als 14 Tage getestet und sich dann abgemeldet haben, und selbst wenn sie sich wieder anmelden, müssen die 14 Tage aufeinanderfolgen, um zu zählen. Diese eine Klausel widerlegt den Mythos „14 Tage sind kumulativ“ allein, und genauso wichtig: sie sagt nichts über Ihre Builds.
Drei Fakten zum Merken
Sind Updates während des Tests gut oder schlecht?
Hier dreht sich Entwicklerangst in Chance. Updates während Ihres geschlossenen Tests zu pushen gilt weithin als positives Engagement-Signal. Es lohnt sich, zu trennen, was Google offiziell sagt und was die Entwickler-Community geschlossen hat, weil sich beides überschneidet, ohne identisch zu sein:
Weiter iterieren und fixen
Die Play Console-Hilfe ermutigt zu laufender Iteration: nutzen Sie den geschlossenen Test weiter, während Sie von Nutzern gemeldete Probleme und Bugs beheben, und Ihre App im geschlossenen Test zu aktualisieren, bevor Sie in die Produktion gehen, ist „eine gute Möglichkeit, schlechte Bewertungen und Rezensionen zu minimieren.“
Wenn Sie Produktionszugriff beantragen, fragt der Fragebogen, welches Engagement Sie erhalten haben und was Sie mit dem Feedback der Tester gemacht haben.
Aktiv schlägt eingefroren
Praktiker gehen weiter: eine App, die 14 Tage auf Version 1.0 ohne Aktivität steht, wirkt wie abgehaktes Testing, während eine, die Updates auf Feedback liefert, echte Entwicklung zeigt. Manche Entwickler pushen absichtlich zwei oder drei kleine Updates, um Reaktionsfähigkeit zu zeigen.
Das ist Community-Konsens und vernünftige Schlussfolgerung, keine veröffentlichte Google-Regel. Google hat keine numerische Anforderung „X Updates ausliefern“ festgelegt.
Das Fazit: Updaten ist sicher und erwünscht, und die Engagement-Story, die Sie damit bauen, kann Ihnen helfen, den Fragebogen zum Produktionszugriff zu beantworten. Das einzige echte Risiko kommt von dem, was Sie ausliefern, nicht vom Akt des Auslieferns: das führt zum einen echten Vorbehalt.
Kann ein schlechtes Update meine Uhr indirekt zurücksetzen?
Ja: und das ist der eine Vorbehalt, der zählt. Während der Akt des Updatens den Timer nie direkt zurücksetzt, können die Folgen eines kaputten Updates das tun. Folgen Sie der Kette:
Die Regel ist also einfach: updaten Sie frei, aber prüfen Sie jeden Build auf Basisstabilität, bevor Sie ihn auf Ihren Track des geschlossenen Tests pushen. Und laufen Sie nie mit genau 12 Testern, weil eine einzige Abmeldung nach einem schlechten Build Sie versenken kann. Ein Puffer an Testern über 12 absorbiert dieses Risiko.
Lesen Sie die Kette sorgfältig: der Reset kommt nie vom Update. Er kommt vom Fallen unter 12 angemeldete Tester. Der kaputte Build ist nur das, was die Abmeldungen ausgelöst hat. Halten Sie Builds stabil und halten Sie einen Puffer, und das indirekte Risiko verschwindet ebenfalls.
Müssen Tester nach einem Update neu installieren oder sich neu anmelden?
Nein. Sobald ein Tester sich angemeldet und Ihre App installiert hat, übernimmt Google Updates automatisch. Es gibt nichts zum Klicken und nichts, das Sie erneut senden müssten.
Updates rollen automatisch aus
Googles Play Console-Hilfe stellt in Offenen, geschlossenen oder internen Test einrichten (Antwort 9845334) klar: „Sobald Ihre Tester Ihre App installiert haben, werden sie innerhalb weniger Minuten automatisch auf die Testversion aktualisiert.“ Tester bleiben über jeden Build angemeldet: keine Neuinstallation, kein zweiter Klick auf den Link zum Teilen.
Ein Timing-Hinweis von derselben Google-Seite: wenn Sie zusätzliche Änderungen veröffentlichen, „stehen sie Testern möglicherweise mehrere Stunden nicht zur Verfügung“, bevor das automatische On-Device-Update greift. Aber der angemeldete Status der Tester, den die 14-Tage-Uhr misst, bleibt über jedes neue AAB erhalten. Genau deshalb setzt ein Build-Update die Uhr nicht zurück: die Tester sind nie gegangen.
Wichtige Ausnahme Neue Berechtigungen können das stille Update unterbrechen
Eine Art Build rollt nicht immer still aus: ein Update, das eine neue gefährliche (sensible) Berechtigung hinzufügt, etwa ACCESS_FINE_LOCATION, Kamera oder Mikrofon. Je nach Berechtigung und Target-API-Level kann Google Play eine Aktualisieren-Aufforderung zeigen, die der Tester manuell tippen und bestätigen muss, statt sie im Hintergrund zu installieren, und wer sie ignoriert, bleibt auf dem alten Build. Selbst wenn es still installiert, wird die neue Berechtigung erst zur Laufzeit gewährt, sodass eine berechtigungsgeschützte Funktion kaputt wirken kann, bis der Tester sie erlaubt.
Im geschlossenen Test ist das eine stille Falle: pushen Sie an Tag 5 ein berechtigungsreiches Update und Ihre Zahlen aktiver Tester können absacken, genau das Engagement-Signal, das Google beim Produktionszugriff gewichtet, weil die Hälfte Ihrer Tester die Aufforderung nie gesehen hat. Eine neue Hochrisiko-Berechtigung kann auch eine Überprüfung der Berechtigungserklärung auslösen, die den Build überhaupt erst verzögert veröffentlicht.
Bevor Sie mitten im Test ausrollen: vergleichen Sie die Berechtigungen Ihres neuen Manifests mit dem Live-Build. Hat sich der Berechtigungssatz geändert, bitten Sie Ihre Tester, den Play Store zu öffnen und manuell zu aktualisieren (und die neue Aufforderung zu gewähren), und planen Sie eine mögliche Erklärung-Überprüfung ein.
Häufige Mythen zum geschlossenen Test, entlarvt
Der meiste Panik ums Updaten läuft auf eine Handvoll Mythen hinaus. Hier die fünf, die Entwickler am meisten Schlaf kosten, mit dem, was wirklich gilt:
Mythos 1„Einen neuen Release zu erstellen setzt die Uhr zurück.“
Mythos 2„Deinstallieren ist dasselbe wie Abmelden.“
Mythos 3„Die 14 Tage sind kumulativ.“
Mythos 4„Genau 12 Tester reichen.“
Mythos 5„Tester müssen die App jeden einzelnen Tag nutzen.“
Was setzt die Uhr zurück und was nicht
Hier die ganze Frage auf einem Bildschirm. Speichern, screenshotten oder an alle im Team schicken, die weiter fragen. Alles, was an Ihren Build gebunden ist, ist sicher; nur was an Ihre Testerzahl gebunden ist, ist es nicht.
| Aktion | Setzt die 14-Tage-Uhr zurück? |
|---|---|
| Neues AAB auf denselben Track des geschlossenen Tests hochladen | Nein |
| Release Notes oder Store-Listing-Metadaten bearbeiten | Nein |
| Ein Tester sendet Feedback | Nein |
| Ihre App stürzt auf dem Gerät eines Testers ab | Nein |
| Ein Tester deinstalliert (ohne Abmeldung) | Nein* |
| Angemeldete Testerzahl fällt unter 12 | Ja |
| Ein Tester meldet sich formell über den Web-Link ab | Ja** |
| Kaputten Build pushen, der Abmeldungen unter 12 treibt | Indirekt |
| Track des geschlossenen Tests pausieren | Gemeldetes Risiko |
| Testerliste überschreiben und aktive Tester auslassen | Gemeldetes Risiko |
* Der Timer läuft technisch weiter, aber Deinstallierer kehren selten zurück. ** Nur wenn es Sie unter 12 drückt. Die letzten zwei Zeilen sind community-berichtete Vorsicht, keine bestätigte Google-Dokumentation: behandeln Sie sie als „nicht riskieren“ statt als festgeschriebene Regeln. Eine Google Group umgeht das Risiko des Listenüberschreibens ganz.
Wie sich die Anforderung im Laufe der Zeit geändert hat
Wenn Sie ältere Tutorials lesen, liegt hier der Grund, warum die Zahlen nicht passen. Die Dauer war immer 14 fortlaufende Tage; nur die Testerzahl hat sich bewegt.
Vor November 2023 gab es keinen erforderlichen geschlossenen Test, um in die Produktion zu gelangen. Sie konnten ohne Tester-Rekrutierung veröffentlichen.
Private Konten, die nach dem 13. November 2023 erstellt wurden, mussten einen geschlossenen Test mit 20 angemeldeten Testern über 14 fortlaufende Tage durchführen. Organisationskonten waren ausgenommen.
Am 11. Dezember 2024 fiel das Minimum von 20 auf 12, die 14-Tage-Dauer blieb unverändert. Organisationskonten bleiben ausgenommen.
Jeder Leitfaden, der Ihnen noch rät, 20 Tester zu rekrutieren, ist veraltet. Den Wechsel behandeln wir ausführlich unter was sich von 20 zu 12 Testern geändert hat.
Richtlinienänderungen 2026, die Sie kennen sollten
Der geschlossene Test existiert nicht im Vakuum. Einige Fristen 2026 können mit Ihrem Launch-Zeitplan kollidieren: keine ändert, wie die 14-Tage-Uhr funktioniert, aber sie können mit Ihrem Fenster kollidieren, wenn Sie den Kalender nicht im Blick haben:
Fristen 2026, die Ihren Zeitplan kreuzen
Daten laut Google Play Console Help (Target API Level) und Android Developers Blog (Developer Verification). Der Verifizierungszeitplan ist gestaffelt und kann sich 2026-2027 erweitern: prüfen Sie die offiziellen Seiten, bevor Sie danach planen. Unser Leitfaden zu den Veröffentlichungsanforderungen 2026 führt die volle Liste.
Wie PrimeTestLab Ihre Uhr am Laufen hält
Der schwerste Teil des geschlossenen Tests ist nicht, die Regeln zu verstehen; es ist, 12 oder mehr echte Menschen 14 ununterbrochene Tage angemeldet und engagiert zu halten, während Sie iterieren. Genau dafür ist PrimeTestLab gebaut. Wir stellen Tester auf echten Geräten bereit, die angemeldet sind, und führen Sie durch die Play Console-Einrichtung, damit die Uhr sauber startet und weiterläuft, während Sie Fixes ausliefern. Den vollen Service für den geschlossenen Test bei Google Play finden Sie dort. Wir halten eine Erfolgsquote von 99.9% bei über 7.400+ Apps, mit Teststart in 4-6 Stunden.
Sie fügen unsere Tester in der Play Console hinzu, teilen Ihre Test-URL, und Ihre Uhr startet. Danach können Sie Ihren Build so oft updaten, wie Sie möchten: die Tester bleiben angemeldet, die Serie läuft unter Ihnen weiter.
+5% Servicegebühr · Kostenloser neuer Test oder vollständige Rückerstattung
Die meisten Entwickler wählen mehr als das Minimum von 12 Testern genau deshalb, damit eine einzige Abmeldung, auch durch einen schlechten Build, sie nicht unter 12 drücken und die Uhr zurücksetzen kann. Ein Puffer ist die günstigste Versicherung gegen das Einzige, was Ihre Serie wirklich bricht.
Häufig gestellte Fragen
Kann ich meine App im geschlossenen Test aktualisieren, ohne die 14 Tage neu zu starten?
Ja. Einen neuen Build auf Ihren bestehenden Test-Track des geschlossenen Tests hochzuladen startet das fortlaufende 14-Tage-Fenster nicht neu. Die Uhr hängt daran, mindestens 12 Tester fortlaufend angemeldet zu halten, nicht an Ihrer App-Version. Tester werden automatisch aktualisiert und bleiben angemeldet, sodass Ihr Fortschritt über Builds hinweg fortbesteht.
Was setzt die Uhr des geschlossenen Tests als Einziges zurück?
Das fortlaufende 14-Tage-Fenster bricht, wenn Ihre angemeldete Testerzahl unter 12 fällt, oder wenn sich Tester formell abmelden und Sie unter das Minimum drücken. Build-Updates, Store-Listing-Edits und Crashes setzen sie nicht zurück. Ein Puffer an Testern über 12 ist der zuverlässigste Schutz für Ihre Serie.
Was ist der Unterschied zwischen eingeladenen und angemeldeten Testern?
Eingeladen heißt, Sie haben jemandes E-Mail zur Liste hinzugefügt: das zählt für nichts. Angemeldet heißt, sie haben Ihren Link geöffnet, sich angemeldet und „Betatester werden“ gewählt: das ist der Status, den die 14-Tage-Uhr misst. Nur angemeldete Tester zählen für die Anforderung, bestätigen Sie also immer, dass Tester den Anmeldeschritt wirklich abgeschlossen haben.
Müssen sich Tester nach einem Update erneut anmelden?
Nein. Sobald ein Tester sich anmeldet und installiert, liefert Google Ihre Updates automatisch innerhalb von Minuten. Sie installieren nicht neu und klicken den Link zum Teilen nicht erneut. Ihr angemeldeter Status, den die 14-Tage-Anforderung misst, läuft ununterbrochen über jeden neuen Build auf demselben Track des geschlossenen Tests weiter.
Ist Deinstallieren dasselbe wie Abmelden?
Nein. Ein Tester meldet sich formell nur ab, indem er den Testlink besucht und den Test verlässt. Wenn er nur deinstalliert, läuft der Timer technisch weiter. In der Praxis kehren deinstallierende Tester aber selten zurück, was das Engagement schwächen kann, das Sie beim Beantragen des Produktionszugriffs zeigen, also lohnt es sich, Tester aktiv zu halten.
Will Google, dass ich während des Tests Updates pushe?
Googles Dokumentation empfiehlt, Probleme im geschlossenen Test vor der Produktion weiter zu beheben und künftige Updates routinemäßig zu testen. Der Community-Konsens geht weiter und behandelt aktive Updates als positives Engagement-Signal gegenüber einer eingefrorenen App, die wie abgehaktes Testing wirkt. Google hat keine erforderliche Update-Anzahl veröffentlicht, iterieren Sie also echt statt nur der Statistik wegen zu updaten.
Wie viele Tester brauche ich wirklich für den geschlossenen Test?
Googles Minimum sind 12 angemeldete Tester über 14 fortlaufende Tage für private Konten, die nach dem 13. November 2023 erstellt wurden. Weil eine einzige Abmeldung Sie unter 12 drücken und die Serie brechen kann, laufen viele Entwickler mit 20 bis 25 Testern als Puffer. PrimeTestLab bietet Pläne mit 12, 20 und 25 Testern ab $19.99.
Fazit
Zusammenfassung
Ihre App während des 14-tägigen geschlossenen Tests zu aktualisieren ist sicher, normal und erwünscht. Die Uhr misst, dass mindestens 12 Tester fortlaufend angemeldet bleiben, also setzt ein neuer Build sie allein nie zurück. Die echten Risiken sind, unter 12 angemeldete Tester zu fallen, formelle Abmeldungen oder einen Build so kaputt auszuliefern, dass Tester aussteigen. Liefern Sie Ihre Fixes, iterieren Sie auf Feedback und schützen Sie Ihre Testerzahl mit einem Puffer über dem Minimum. Wenn Sie eine Uhr wollen, die einfach nicht bricht, hält PrimeTestLab 12 bis 25 echte Tester angemeldet ab $19.99, mit Teststart in 4-6 Stunden. Preispläne ansehen →