In questa guida
La nuova versione è uscita e i tester segnalano crash che la vecchia non aveva mai avuto. Qualcosa è cambiato tra le due build. Il modo più rapido è seguire un ordine fisso di controlli, dal sospetto più probabile e più economico a quello più raro e più costoso.
Passo 0: separa i due tipi di crash
Fai al tester una sola domanda: è andato in crash dopo l'aggiornamento sopra la vecchia versione, o anche con una installazione pulita?
- Solo dopo l'aggiornamento: il problema è nel percorso di aggiornamento, di solito vecchi dati che incontrano il nuovo codice.
- Anche con installazione pulita: il problema è nella nuova build stessa.
Questa risposta dimezza la ricerca.
I controlli, in ordine
- Leggi il report del crash. Ottieni lo stack trace e la versione esatta. Annota la prima riga nel tuo codice. Vedi [come un tester invia un bug report Android per ciò che i tester possono mandarti.
- Confronta la release. Elenca cosa è cambiato dall'ultima build buona: codice, librerie, impostazioni di build, configurazione. Il crash è quasi sempre in quell'elenco.
- Migrazione dei dati. Hai cambiato lo schema del database, un'impostazione salvata o il formato di un file? I vecchi dati che il nuovo codice non si aspetta sono il classico crash da aggiornamento. Vedi [testare una migrazione del database senza perdere dati.
- Librerie o SDK aggiornati. Una nuova versione può cambiare il comportamento o rimuovere una funzione. Leggi le modifiche di ogni dipendenza che è cambiata.
- Configurazione e chiavi. Valori di configurazione, chiavi API, feature flag o impostazioni del server mancanti o cambiati che la nuova build legge.
- Differenze di build. La riduzione del codice e l'offuscamento possono rimuovere o rinominare qualcosa usato a runtime. Un crash che compare solo nella build di release, e non in debug, punta qui.
- Firma. Una build firmata in modo diverso dalla precedente può rompere l'aggiornamento o l'accesso ai dati protetti. Verifica che le build di test e di release siano firmate come intendi.
- Modifiche al server. Una modifica al backend rilasciata nello stesso momento può sembrare un crash dell'app. Controlla se anche le vecchie versioni dell'app falliscono.
Riproduci l'aggiornamento, non solo la nuova build
La maggior parte dei team prova solo un'installazione pulita della nuova versione. Fai invece così:
- Installa la release precedente e usala finché non ha dati reali.
- Aggiorna sopra di essa alla nuova build.
- Apri ogni schermata principale e ripeti le azioni chiave.
- Ripeti partendo da una versione molto più vecchia, se hai ancora utenti su quella.
[Come testare un aggiornamento di un'app già online spiega questo in dettaglio.
Cosa chiedere ai tester
- Quale versione avevi prima, e quale ora?
- Hai aggiornato o reinstallato?
- Cosa hai fatto subito prima del crash?
- Succede ogni volta?
Contenere il problema
Una volta trovata la causa, decidi in fretta: rilascia una correzione, oppure blocca la distribuzione se i tuoi strumenti dello store lo permettono. Controlla le opzioni attuali nella console dello store. Poi aggiungi il caso di aggiornamento che fallisce alla tua checklist di rilascio.
Correlati
- Hub: [Problemi e cause dei test delle app, con soluzioni
- [Testare cosa succede quando gli utenti negano i permessi
- [I tester non riescono ad accedere: problemi con gli account di test
I tester che eseguono la vecchia versione e poi aggiornano scoprono ciò che un'installazione pulita nasconde. Su AppReviewX ottieni feedback privato e strutturato sulla tua build. Inizia gratis.