Una checklist go / no-go trasforma "sembra pronto" in una decisione che sai spiegare. Ogni criterio ha un responsabile, una soglia e una prova. Se sei uno sviluppatore solitario, sei tu tutti i responsabili, e scriverla ti impedisce comunque di saltare i punti scomodi.
Modello da copiare e incollare
DECISIONE DI RILASCIO: [App], versione [x.y.z] (build [n]), data [data]
Chi decide: [nome]
| # | Criterio | Responsabile | Prova (link / nota) | Ok? |
|---|---------------------------------------------|--------------|------------------------|-----|
| 1 | Nessun bug aperto di crash o perdita dati | [nome] | [elenco problemi, log crash] | S/N |
| 2 | I flussi principali passano sulla build di rilascio | [nome] | [note di test, data] | S/N |
| 3 | Installazione e aggiornamento dalla versione precedente | [nome] | [dispositivo, versioni] | S/N |
| 4 | Problemi noti documentati e accettati | [nome] | [lista problemi noti] | S/N |
| 5 | Accesso, pagamenti, permessi funzionano | [nome] | [note di test] | S/N |
| 6 | Scheda nello store, note e screenshot corrispondono | [nome] | [link della bozza] | S/N |
| 7 | Esiste un piano di rollback o di blocco | [nome] | [link del piano] | S/N |
| 8 | Qualcuno monitora i crash dopo il rilascio | [nome] | [chi, fino a quando] | S/N |
Ogni "N" sui punti 1-3 o 5 = NO-GO, a meno che chi decide scriva perché.
Decisione: GO / NO-GO / GO con condizioni: [condizioni]
Esempio (inventato)
DECISIONE DI RILASCIO: Pocket Budget, 1.2.0 (build 57), 2026-10-17
Chi decide: Sam
1 Crash/perdita dati: nessuno aperto - elenco problemi controllato alle 10:15 - S
2 Flussi principali: aggiungi, modifica, elimina voce passano sulla build di rilascio - S
3 Aggiornamento dalla 1.1.4: testato su due dispositivi - S
4 Problemi noti: esportazione CSV lenta, accettata - S
5 Accesso/permessi: percorso di permesso negato non testato - N
...
Decisione: GO con condizioni: testa il percorso di permesso negato prima di inviare.
Come adattarla
- Adatta i criteri alla tua app. Un'app che funziona prima offline ha bisogno di una riga offline; un'app con acquisti in app ha bisogno di una riga per gli acquisti.
- Scrivi le soglie come sì/no. "Sembra stabile" non è un criterio. "Nessun bug di crash aperto sulla build di rilascio" lo è.
- Testa la build di rilascio, non quella di debug. Il comportamento può differire, quindi le prove con l'artefatto sbagliato non valgono.
- Indica una sola persona che decide. I gruppi che votano si disperdono. Una persona decide dopo aver ascoltato i responsabili.
- Conserva la copia compilata. Alla release successiva vedi cosa hai accettato l'ultima volta.
Correlati: checklist per le correzioni urgenti, piano di rollback e blocco, e l'hub checklist per il test delle app mobile.
Ti servono tester sulla build di rilascio prima di decidere? Inizia gratis.