In diesem Ratgeber
Das sind Konventionen, keine Regeln: Teams benutzen die Wörter unterschiedlich. Die Tabelle zeigt eine gängige Lesart. Store-Tracks (intern, geschlossen, offen) sind ein eigenes Konzept; siehe geschlossener Test, gestaffelter Rollout oder Soft Launch.
Die Phasen
| Alpha | Beta | Release Candidate | |
|---|---|---|---|
| Ziel | Funktioniert der Kern überhaupt? | Funktioniert es auch für andere als dich? | Ist dieser Build so versandfertig? |
| Vollständigkeit | Funktionen fehlen oder sind roh | Funktionsumfang komplett oder fast | Komplett; nur blockierende Fixes |
| Wer testet | Du, dein Team, wenige Vertraute | Externe, die deinen Nutzern ähneln | Dieselben, dazu ein letzter Check von dir |
| Gewünschtes Feedback | Abstürze, kaputte Abläufe | Bedienbarkeit, Geräteprobleme, Unklares | Nur Showstopper |
| Erlaubte Änderungen | Alles | Fixes und Feinschliff; selten Funktionen | Nur blockierende Fixes |
| Ausstieg | Kernabläufe laufen | Keine bekannten großen Probleme | Nichts Blockierendes; du würdest veröffentlichen |
Praktisch
- Die Mitte nicht überspringen. Direkt von eigenen Tests zum Launch heißt: echte Nutzer finden die Probleme.
- Umfang beim RC einfrieren. Kommen Funktionen dazu, ist es wieder eine Beta.
- Ausstiegsbedingungen aufschreiben, vor jeder Phase. Ohne sie enden Phasen nie.
- Tester zur Phase wählen. Alpha: Leute, die rohe Kanten aushalten. Beta: Leute wie deine Nutzer. RC: wer einen Rückschritt bemerkt.
Wo AppReviewX passt
Vor allem in der Beta-Phase, für Apps, die bereits in einem Store veröffentlicht sind: andere Entwickler geben privates, strukturiertes Feedback (1 akzeptiertes Feedback = 1 Credit; neue Konten bei 0). Builds und Installer werden nicht verteilt.
Weiter: alle Testing-Optionen, Beta-Test oder Soft Launch, geschlossener Test, gestaffelter Rollout oder Soft Launch.