In questa guida
I tester perdono la prima sessione quando il backend è giù, l'account di test non funziona o l'app punta al server sbagliato. Esegui questa lista prima di inviare qualsiasi invito. Ogni voce ha un motivo e un modo per verificarla.
| # | Voce | Perché | Come verificare |
|---|---|---|---|
| 1 | La build punta al backend di test, non a quello di produzione | Le azioni di test non devono toccare utenti reali o denaro reale | Controlla l'URL di base nella build installata; esegui un'azione e cercala nel database di test |
| 2 | Il backend di test è raggiungibile dall'esterno della tua rete | I tester non sono sul tuo Wi-Fi o sulla tua VPN | Aprilo dai dati mobili su un telefono |
| 3 | Esistono account di test per ogni ruolo (nuovo utente, utente abituale, admin se pertinente) | I tester non devono perdere tempo a registrarsi o a indovinare | Accedi con ciascuno da un'installazione pulita |
| 4 | Le credenziali sono nell'invito, non solo nella tua testa | Evita la prima domanda di supporto | Rileggi l'invito come se fossi un estraneo |
| 5 | I dati di esempio sono realistici (nomi lunghi, liste vuote e piene, caratteri speciali) | Dati vuoti o troppo ordinati nascondono bug di layout e di logica | Scorri le liste principali con questi dati |
| 6 | I dati si possono ripristinare in fretta | Dopo una sessione di test andata male serve uno stato pulito | Esegui il ripristino una volta e misura il tempo |
| 7 | Pagamenti ed email funzionano in modalità sandbox/test | Nessun addebito reale né email a indirizzi reali | Fai un acquisto di prova; verifica dove finiscono le email |
| 8 | I feature flag sono impostati per la build da testare | Le funzioni non finite devono essere nascoste o segnalate | Elenca i flag e i loro valori per questa build |
| 9 | Le chiavi di servizi terzi (mappe, push, autenticazione) sono valide per la build di test | Le chiavi legate a un altro ID app falliscono in silenzio | Attiva ogni servizio una volta su un dispositivo |
| 10 | Le notifiche push arrivano a un dispositivo di test | Spesso sono configurate male solo nelle build di test | Inviane una dal backend |
| 11 | La segnalazione di crash ed errori è attiva, con il numero di build allegato | Altrimenti non riceverai log dai tester | Provoca un crash di prova e trovalo nella dashboard |
| 12 | Il logging non salva password o dati personali | I dati di test possono comunque essere di persone reali | Leggi un campione di righe di log |
| 13 | I tester possono installare la build (link, gruppo o invito funziona) | È il primo intoppo più comune | Installa seguendo il percorso esatto che useranno i tester, su un secondo dispositivo |
| 14 | Il numero di build è visibile nell'app | Ogni segnalazione ha bisogno di una versione | Apri le impostazioni o la schermata "Info" |
| 15 | Esiste una lista dei problemi noti | Evita ai tester di segnalare ciò che già sai | Scrivila prima dell'invito |
| 16 | C'è un solo posto dove inviare il feedback e lo vedrai | Il feedback sparso va perso | Invia a te stesso una segnalazione di prova |
Modello: nota di prontezza pre-invito
Ambiente: [URL di staging] Build: [numero] Data: [data]
Verificato da: [nome]
[ ] voci 1-16 completate. Eccezioni: [elenco]
Problemi noti: [elenco]
Procedura di ripristino: [passi]
Come adattarla
Elimina le voci che non si applicano (nessun backend, nessun pagamento). Aggiungi ciò che è specifico del tuo stack, come una migrazione del database o una modalità demo con dati di esempio. Per come testare le migrazioni, vedi i controlli collegati su testare le migrazioni del database senza perdere dati.
Correlati
- Hub: hub delle checklist per il test delle app mobili
- Checklist della privacy policy per app mobili
- Checklist pre-lancio dell'app: 30 cose da verificare
Quando l'ambiente è pronto, AppReviewX può fornirti feedback privato e strutturato dai tester. Un feedback = 1 credito; i nuovi account partono da 0. Inizia gratis.