In diesem Ratgeber
Eine Go-/No-go-Checkliste macht aus „fühlt sich fertig an“ eine Entscheidung, die du begründen kannst. Jedes Kriterium hat eine verantwortliche Person, eine Schwelle und einen Beleg. Bist du allein, bist du jede Rolle, aber das Aufschreiben hindert dich daran, unbequeme Punkte zu überspringen.
Text zum Kopieren
RELEASE-ENTSCHEIDUNG: [App], Version [x.y.z] (Build [n]), Datum [Datum]
Entscheider/in: [Name]
| # | Kriterium | Verantw. | Beleg (Link / Notiz) | Go? |
|---|----------------------------------------------|----------|-------------------------|-----|
| 1 | Keine offenen Absturz- oder Datenverlust-Bugs| [Name] | [Issue-Liste, Crash-Log]| J/N |
| 2 | Kernabläufe laufen im Release-Build | [Name] | [Testnotiz, Datum] | J/N |
| 3 | Neuinstallation und Update von der Vorversion| [Name] | [Gerät, Versionen] | J/N |
| 4 | Bekannte Fehler dokumentiert und akzeptiert | [Name] | [Liste bekannter Fehler]| J/N |
| 5 | Anmeldung, Zahlung, Berechtigungen laufen | [Name] | [Testnotiz] | J/N |
| 6 | Store-Eintrag, Notes, Screenshots passen | [Name] | [Entwurf-Link] | J/N |
| 7 | Rollback- bzw. Stopp-Plan liegt vor | [Name] | [Link zum Plan] | J/N |
| 8 | Jemand beobachtet Abstürze nach dem Release | [Name] | [wer, bis wann] | J/N |
Ein „N“ bei 1-3 oder 5 = NO-GO, außer der/die Entscheider/in schreibt auf, warum nicht.
Entscheidung: GO / NO-GO / GO mit Auflagen: [Auflagen]
Beispiel (erfunden)
RELEASE-ENTSCHEIDUNG: Pocket Budget, 1.2.0 (Build 57), 17.10.2026
Entscheider: Sam
1 Abstürze/Datenverlust: keine offen - Issue-Liste um 10:15 geprüft - J
2 Kernabläufe: Eintrag anlegen, ändern, löschen laufen im Release-Build - J
3 Update von 1.1.4: auf zwei Geräten getestet - J
4 Bekannte Fehler: CSV-Export langsam, akzeptiert - J
5 Anmeldung/Berechtigungen: Pfad „Benachrichtigung abgelehnt“ nicht getestet - N
...
Entscheidung: GO mit Auflagen: Pfad „Berechtigung abgelehnt“ vor dem Einreichen testen.
So passt du sie an
- Ändere die Kriterien auf deine App. Eine Offline-App braucht eine Offline-Zeile, eine App mit In-App-Käufen eine Kaufzeile.
- Formuliere Schwellen als Ja/Nein. „Wirkt stabil“ ist kein Kriterium, „keine offenen Absturz-Bugs im Release-Build“ schon.
- Teste den Release-Build, nicht den Debug-Build. Das Verhalten kann abweichen, Belege vom falschen Artefakt zählen nicht.
- Benenne genau eine Person als Entscheider. Abstimmungen in Gruppen zerfasern. Eine Person entscheidet, nachdem sie die Verantwortlichen gehört hat.
- Hebe die ausgefüllte Kopie auf. Beim nächsten Release siehst du, was du zuletzt in Kauf genommen hast.
Passend dazu: Hotfix-Checkliste, Rollback- und Rollout-Stopp-Plan und der Hub Checklisten für mobile App-Tests.
Du brauchst Tester auf dem Release-Build, bevor du entscheidest? Kostenlos starten.