Test da eseguire prima della pubblicazione di una nuova release di un’app Flutter per iOS & Android

Ad ogni release è bene strutturare una serie di controlli che ci fanno evitare di pubblicare un’app con bug banali o gravi. La lista è pensata per iOS e Android con Flutter, ma molti controlli sono di carattere generale. Se cerchi un articolo che spieghi come pubblicare una nuova app, leggi questi articoli. Andiamo veloci in modo schematico:

1. Build e configurazione

• Eseguire flutter analyze per verificare che non ci siano errori o warning.
• Eseguire tutti gli unit test con flutter test se ne abbiamo fatti.
• Verificare che la build nel modo Release compili correttamente su Android e iOS
• Controllare version e build number in pubspec.yaml.
• Verificare che ambiente, API URL e configurazioni siano quelli di produzione.
• Controllare che non siano rimasti flag di debug, mock, dati fasulli o endpoint necessari solo per le fasi di staging.
• Verificare che eventuali chiavi e configurazioni sensibili non siano incluse impropriamente nell’app.
• Controllare che logging e strumenti di debug non espongano dati sensibili. Meglio evitare ogni log in produzione.

2. Installazione e aggiornamento

• Installare l’app da zero su un dispositivo Android e iOS reale.
• Verificare il primo avvio.
• Aggiornare una versione precedente dell’app alla nuova versione senza disinstallarla.
• Controllare che dati locali, preferenze e sessioni vengano mantenuti correttamente dopo l’upgrade.
• Verificare eventuali migrazioni di database.
• Verificare il comportamento dopo chiusura forzata e nuovo avvio.

3. Autenticazione (opzionale)

• Registrazione nuovo account.
• Login con credenziali corrette.
• Login con credenziali errate.
• Logout.
• Recupero password.
• Cambio password, se previsto.
• Scadenza della sessione/token.
• Refresh automatico del token.
• Avvio dell’app con sessione già autenticata.
• Cancellazione account, se prevista.
• Verificare che un utente non possa accedere a schermate protette dopo il logout.

4. UX parti principali dell’app

Per ogni funzionalità importante verificare almeno:

• Input vuoti.
• Input non validi.
• Errori restituiti dal backend.
• Dati mancanti o incompleti.
• Liste vuote.
• Liste molto lunghe.
• Loading lento.
• Operazioni ripetute rapidamente.
• Doppio tap sui pulsanti di conferma.
• Navigazione avanti/indietro durante un’operazione.

Eseguire manualmente tutti i principali percorsi che l’utente può fare, per esempio:

• Login → Home → dettaglio → modifica → salvataggio.
• Creazione di un nuovo elemento.
• Modifica di un elemento esistente.
• Eliminazione.
• Ricerca.
• Filtri e ordinamento.
• Paginazione/infinite scrolling.
• Upload/download, se presenti.
• Checkout/pagamento, se presenti.

5. Connessione di rete e API

• App con Wi-Fi stabile.
• App con rete mobile.
• App senza connessione.
• Perdita della connessione durante una richiesta.
• Ripristino della connessione.
• Connessione molto lenta.
• Timeout API.
• Risposta API con dati incompleti o inattesi.
• Verificare retry e messaggi di errore.
• Controllare che uno stesso comando non venga inviato più volte accidentalmente.

6. Navigazione

• Tutte le schermate principali sono raggiungibili.
• Back button Android funziona correttamente.
• Swipe-back iOS funziona dove previsto.
• Bottom navigation mantiene correttamente lo stato.
• Tab navigation mantiene lo stato.
• Apertura di modal e bottom sheet.
• Chiusura delle modal tramite gesture/back.
• Universal Links iOS.
• App Links Android.
• Apertura di una notifica verso la schermata corretta.

7. Lifecycle

Testare l’app quando:

• Passa in background.
• Torna in foreground.
• Rimane in background per diversi minuti.
• Viene terminata dal sistema.
• Viene terminata manualmente dall’utente.
• Viene riaperta dopo essere stata terminata.
• Lo schermo viene bloccato e successivamente sbloccato.
• Arriva una telefonata o un’altra interruzione.
• L’utente cambia applicazione durante un’operazione.

Verificare soprattutto che non vengano perse operazioni o dati inseriti.

8. UI e responsive layout

Testare almeno:

• Smartphone piccolo.
• Smartphone grande.
• Tablet & Watch, se supportati.
• Android con differenti densità dello schermo.
• iPhone con notch/Dynamic Island.
• Dispositivi con bottom gesture indicator.
• Orientamento portrait.
• Orientamento landscape, se supportato.

Controllare:

• Overflow Flutter.
• Testi tagliati.
• Pulsanti fuori schermo.
• SafeArea.
• Tastiera che copre input o pulsanti.
• Scroll delle schermate con molti contenuti.
• Dialog su schermi piccoli.
• Bottom sheet con tastiera aperta.

9. Accessibilità e impostazioni di sistema

• Font di sistema normale.
• Font di sistema molto grande.
• Modalità chiara.
• Modalità scura.
• Contrasto sufficiente.
• Elementi interattivi sufficientemente grandi.
• Screen reader almeno sui flussi principali.
• VoiceOver su iOS.
• TalkBack su Android.
• Label semantiche corrette sui controlli importanti.
• Layout ancora utilizzabile con dimensione testo elevata.

10. Tastiera e form

• Tastiera corretta per email.
• Tastiera numerica per numeri.
• Tastiera telefonica per numeri di telefono.
• Next/Done funzionano correttamente.
• Focus passa correttamente tra i campi.
• Tastiera può essere chiusa.
• Validazione viene mostrata correttamente.
• Errori vengono rimossi quando il valore diventa valido.
• Copy/paste funziona dove previsto.
• Autofill funziona dove previsto.
• Password manager funziona dove previsto.

11. Permessi

Provare ogni permesso almeno in questi stati:

• Permesso concesso.
• Permesso negato.
• Permesso negato definitivamente.
• Permesso revocato successivamente dalle impostazioni di sistema.

Verificare, se utilizzati:

• Fotocamera.
• Microfono.
• Foto/galleria.
• Localizzazione.
• Bluetooth.
• Contatti.
• Calendario.
• Notifiche.

L’app non deve bloccarsi se un permesso viene negato.

12. Push notification

• Richiesta del permesso notifiche.
• Token push registrato correttamente.
• Ricezione con app in foreground.
• Ricezione con app in background.
• Ricezione con app terminata.
• Tap sulla notifica.
• Navigazione verso il contenuto corretto.
• Payload incompleto/non riconosciuto.
• Aggiornamento del push token.
• Logout rimuove/disassocia correttamente il token, se necessario.

Separare i test APNs e FCM quando possibile.

13. Salvataggio locale

• SharedPreferences.
• Secure Storage.
• Database locale.
• Cache.
• File salvati localmente.
• Dati mantenuti dopo riavvio.
• Dati mantenuti dopo aggiornamento app.
• Dati eliminati correttamente al logout quando richiesto.
• Dati sensibili non salvati in storage non sicuro.

14. Performance

• Tempo di cold start accettabile.
• Tempo di warm start accettabile.
• Navigazione fluida.
• Liste lunghe senza evidenti rallentamenti.
• Immagini grandi senza bloccare l’interfaccia.
• Scroll fluido.
• Assenza di freeze durante chiamate API.
• Assenza di operazioni pesanti sul main isolate.
• Consumo RAM ragionevole.
• Consumo CPU ragionevole.
• Consumo batteria ragionevole.
• Nessuna crescita anomala della memoria dopo uso prolungato.

Eseguire queste verifiche utilizzando una build Release/Profile e non solamente Debug perché i sistemi hanno una gestione diversa su in debug o release mode.

15. Error handling

• Nessun errore mostra stack trace all’utente.
• Errori API hanno messaggi comprensibili.
• Errori non recuperabili hanno una schermata/stato coerente.
• Pulsanti Retry funzionano.
• Loading indicator viene sempre rimosso.
• Non esistono schermate bloccate permanentemente in loading.
• Flutter error non gestiti vengono registrati dal sistema di crash reporting.
• Errori async non gestiti vengono registrati.
• Errori del codice nativo Android/iOS vengono registrati.

16. Crash reporting e analytics

Se utilizzati strumenti come Firebase Crashlytics o Sentry:

• Verificare che gli eventi arrivino dall’ambiente di produzione.
• Generare un crash di test.
• Controllare simbolicazione degli stack trace.
• Verificare dSYM iOS.
• Verificare mapping/deobfuscation Android.
• Controllare versione/build associata al crash.
• Verificare gli eventi analytics principali.
• Controllare che analytics non raccolga dati personali non previsti.
• Evitare eventi duplicati.

17. Android specifico

• Test su almeno una versione Android relativamente vecchia ancora supportata.
• Test sull’ultima versione Android supportata.
• Test su dispositivo fisico.
• Back button.
• Gesture navigation.
• Notification channels.
• Runtime permissions.
• App Links.
• Condivisione verso l’app.
• Condivisione dall’app.
• Apertura tramite intent.
• Installazione tramite bundle equivalente alla distribuzione Play Store.
• Verificare applicationId.
• Verificare signing Release.
• Verificare minSdk, targetSdk e compileSdk.
• Verificare icona launcher.
• Verificare nome app.
• Verificare splash screen.
• Verificare adaptive icon.

18. iOS specifico

• Test su almeno una versione iOS relativamente vecchia ancora supportata.
• Test sull’ultima versione iOS supportata.
• Test su iPhone fisico.
• Gesture back.
• Safe Area.
• Dynamic Island/notch.
• Push APNs.
• Universal Links.
• Sign in with Apple, se presente.
• Condivisione.
• Apertura tramite URL Scheme.
• Verificare Bundle Identifier.
• Verificare provisioning profile.
• Verificare certificati.
• Verificare icona.
• Verificare splash screen.
• Verificare stringhe di spiegazione dei permessi in Info.plist.
• Testare una build distribuita tramite TestFlight.

19. Sicurezza

• Nessuna password salvata in chiaro.
• Nessun access token nei log.
• Nessuna API key privata inserita impropriamente nel client.
• HTTPS utilizzato per le comunicazioni sensibili.
• Sessione invalidata correttamente al logout.
• Dati appartenenti ad altri utenti non accessibili modificando ID lato client.
• Endpoint protetti realmente lato server.
• Input potenzialmente malevoli non causano comportamenti inattesi.
• Dati sensibili non finiscono negli analytics.
• Clipboard utilizzata con cautela per informazioni sensibili.
• Screenshot/app switcher non espongono schermate sensibili, se questo è un requisito dell’app.

20. Store e distribuzione

Google Play

• AAB Release generato correttamente.
• Signing corretto.
• Version Code incrementato.
• Version Name corretta.
• Target API compatibile con i requisiti Play.
• Data Safety aggiornata.
• Permessi dichiarati coerenti con l’utilizzo reale.
• Screenshot aggiornati, se necessario.
• Release notes corrette.
• Test tramite Internal/Closed Testing.

App Store

• Archive Release corretto.
• Bundle ID corretto.
• Build Number incrementato.
• Marketing Version corretta.
• Signing corretto.
• Privacy Manifest/configurazioni privacy corretti.
• Descrizioni dei permessi corrette.
• App Privacy aggiornata.
• Screenshot aggiornati, se necessario.
• Release notes corrette.
• Test tramite TestFlight.

21. Smoke test sulla build realmente candidata alla pubblicazione

La build verificata deve essere esattamente quella che verrà pubblicata.

• Installare la Release Candidate Android dal canale di testing Play.
• Installare la Release Candidate iOS da TestFlight.
• Login.
• Eseguire il flusso principale.
• Eseguire almeno una scrittura verso il backend.
• Verificare notifiche/deep link.
• Chiudere e riaprire l’app.
• Logout.
• Controllare crash reporting e log server.
• Confermare numero di versione e build visualizzati/installati.

Criterio minimo di go/no-go

Non pubblicare se esiste almeno uno di questi problemi:

• Crash riproducibile in un flusso principale.
• Perdita o corruzione dei dati.
• Login/logout non affidabile.
• Migrazione dalla versione precedente non funzionante.
• Pagamento non affidabile.
• Problema di sicurezza noto.
• Funzionalità principale inutilizzabile.
• Backend di produzione configurato in modo errato.
• Signing/versioning errato.
• Build candidata diversa da quella effettivamente testata.

Naturalmente questo è un elenco esteso e non tutti questi controlli sono sempre necessari, ma tanti sì (prossimamente scriverò un articolo dove riassumo i testi principali, soprattutto in caso di minor release).