In questa guida
Sono convenzioni, non regole: i team usano le parole in modi diversi. La tabella dà una lettura comune. I track dello store (interno, chiuso, aperto) sono un concetto a sé; vedi test chiuso vs rilascio graduale vs soft launch.
Le fasi
| Alpha | Beta | Release candidate | |
|---|---|---|---|
| Obiettivo | Il nucleo funziona affatto? | Funziona per persone diverse da te? | Questa build è pronta per essere rilasciata così com'è? |
| Completezza | Funzioni possono mancare o essere grezze | Completa o quasi | Completa; solo correzioni bloccanti |
| Chi testa | Tu, il team, alcune persone fidate | Tester esterni simili ai tuoi utenti | Gli stessi tester, più un controllo finale da parte tua |
| Feedback che vuoi | Crash, flussi rotti | Usabilità, problemi sui dispositivi, parti poco chiare | Solo i blocchi gravi |
| Modifiche ammesse | Qualsiasi | Correzioni e rifiniture; funzioni raramente | Solo correzioni bloccanti |
| Condizione di uscita | I flussi principali funzionano | Nessun problema noto importante | Nessun problema bloccante; la pubblicheresti |
Uso pratico
- Non saltare la fase intermedia. Passare dai tuoi test direttamente al lancio significa che sono gli utenti reali a trovare i problemi.
- Blocca l'ambito alla RC. Se aggiungi funzioni, torni a beta.
- Scrivi le condizioni di uscita prima di ogni fase. Senza, le fasi non finiscono mai.
- Abbina i tester alla fase. Alpha: persone che tollerano le asperità. Beta: persone come i tuoi utenti. RC: chiunque noti una regressione.
Dove si inserisce AppReviewX
Soprattutto la fase beta, per le app già pubblicate negli store: altri sviluppatori danno feedback privati e strutturati (1 feedback accettato = 1 credito; i nuovi account partono da 0). Build e installer non vengono distribuiti.
Correlati: tutte le opzioni di test, beta test vs soft launch, test chiuso vs rilascio graduale vs soft launch.