In questa guida
Uno smoke test risponde a una sola domanda: questa build vale il tempo di qualcuno? È un controllo rapido, non un test completo. Se un controllo fallisce, fermati, correggi e crea una nuova build. Non inviare ai tester una build che va in crash all'avvio.
Eseguilo su un dispositivo reale, sul file di build che stai per condividere (non su un'esecuzione di debug dal tuo IDE).
Modello (copia e incolla)
SMOKE TEST: <nome app> build <numero> Data: <data>
Dispositivo / OS: <dispositivo, versione> Tester: <nome>
Fermati al primo fallimento.
[ ] 1. Si installa correttamente (installazione da zero, non aggiornamento)
[ ] 2. Si avvia senza crash né schermata vuota
[ ] 3. Versione e numero di build mostrati sono quelli attesi
[ ] 4. La schermata principale si carica con dati reali o di test
[ ] 5. Registrazione o login funzionano (account di test)
[ ] 6. L'azione principale funziona dall'inizio alla fine: <indicala>
[ ] 7. I dati sopravvivono alla chiusura e riapertura dell'app
[ ] 8. Navigazione indietro e cambio app non rompono la schermata
[ ] 9. Offline: l'app si apre e mostra un messaggio sensato, senza crash
[ ] 10. La build di rilascio punta al back-end e alla configurazione giusti (non a test o locale)
Esito: SUPERATO / FALLITO (voce: __ )
Note:
Perché questi dieci, e come verificarli
- Installazione pulita. Gli aggiornamenti nascondono i problemi di installazione. Verifica: disinstalla prima.
- Avvio. I crash all'avvio sono l'errore più comune che blocca una build. Verifica: avvia due volte, una a freddo.
- Versione e numero di build. Intercetta l'invio del file sbagliato. Verifica: confronta con i tuoi appunti.
- Schermata principale. Dati vuoti o livelli dati rotti emergono qui per primi. Verifica: aspetta che il caricamento finisca.
- Registrazione o login. La maggior parte dei tester non può andare avanti senza. Verifica: usa un account di test preparato.
- Un'azione principale. Dimostra che la ragion d'essere del prodotto funziona ancora. Verifica: nominala nel modello e falla una volta.
- Persistenza. I bug di archiviazione costano caro. Verifica: chiudi forzatamente, riapri, cerca i tuoi dati.
- Navigazione. Uno stack di navigazione rotto frustra subito. Verifica: indietro, Home, ritorno.
- Offline. Gli utenti reali perdono il segnale. Verifica: modalità aereo, poi avvia.
- Configurazione. Spedire un indirizzo di server di test è un classico. Verifica: guarda l'indicatore dell'ambiente o il log, oppure fai una richiesta che puoi verificare.
Esempio (illustrativo)
SMOKE TEST: Example Notes App build 87 Data: 2026-11-04
Dispositivo / OS: telefono di fascia media, Android 13 Tester: Sam
[x] 1 [x] 2 [x] 3 [x] 4 [x] 5
[ ] 6. Azione principale: crea e salva una nota -> FALLITO: il pulsante di salvataggio non fa nulla
Esito: FALLITO (voce 6). Build non condivisa.
Come adattarlo
- Sostituisci la voce 6 con la tua azione principale, e aggiungi una riga se c'è un secondo requisito indispensabile (un acquisto, per esempio).
- Mantienila a dieci voci. Se supera i cinque minuti, sposta le aggiunte nella lista di regressione.
- Automatizza più avanti, se serve. Un test manuale basta finché non compili spesso.
Correlati
- Hub: Hub dei test per app mobili: tutte le aree in un posto
- [Modello di charter per il test esplorativo
- Matrice di gravità e priorità dei bug
Build pronta? Inizia gratis per ottenere un feedback privato e strutturato su di essa.