Crash report analysis: workflow
I crash report sono una miniera di informazioni, ma senza un workflow strutturato si rischia di reagire ad ogni picco senza migliorare davvero. Un buon processo riduce il time-to-fix e aumenta la stabilita dell'app nel tempo.
Raccolta e simbolizzazione
Crashlytics, Sentry, Bugsnag e App Center raccolgono crash, simbolizzano stack trace e raggruppano report simili. La simbolizzazione richiede dSYM (iOS) e mapping ProGuard (Android). Senza simboli, gli stack trace sono inutili.
Prioritizzazione
Ordina i crash per impatto: numero di utenti colpiti, frequenza per sessione, versioni interessate. Un crash che colpisce il 5% degli utenti merita più attenzione di uno che colpisce 5 device. Usa il crash-free user rate (target >99,5%) come KPI.
Riproduzione e fix
Riproduci il crash localmente quando possibile. Quando non lo e, usa breadcrumb e log custom per ricostruire lo scenario. Aggiungi test di regressione automatici. Dopo il deploy, monitora il trend del crash specifico.
Triage process
Settimanale: il team mobile rivede i top 20 crash per impatto. Categorizza: P0 (>5% utenti, blocking), P1 (>1%, frequente), P2 (rare ma su flow critico), P3 (edge case). P0 fix nello stesso sprint, P1 entro 2 sprint, P2 in backlog ordinato.
Crash attribution per release
Confronta crash-free rate tra release. Se nuova release ha rate inferiore di >0.2%, blocca il rollout. Crashlytics e Sentry forniscono Release Health dashboard. Imposta CI checks: build viene promoso a production solo se il rate beta supera la soglia.
Breadcrumb strategici
Aggiungi breadcrumb in: navigazione tra screen, chiamate di rete (URL e status), tap su bottoni critici, cambiamenti di stato. Ogni breadcrumb e una traccia che permette di ricostruire il flusso. Limita a 50-100 per non superare il limite di 64KB del crash report.
Post-mortem culture
Per crash gravi (P0), scrivi post-mortem: timeline, root cause, fix applicato, lezioni apprese, azioni preventive. Condividi nel team per crescita collettiva. Strumenti come Blameless e Incident.io strutturano il processo. Trasforma crash da emergenza in apprendimento sistematico.
Crashlytics e Sentry confronto
Crashlytics: gratis, focalizzato su crash, integrato Firebase. Sentry: a pagamento per volumi alti, error tracking completo (crash, errors, performance, replay). Per startup, Crashlytics e sufficiente. Per team che vogliono unified observability anche backend, Sentry diventa più attraente. Considera anche Bugsnag, Embrace, Datadog Mobile per scenari enterprise.
Reproducible test environment
Per crash che riguardano specifico device/OS, riproduci con Firebase Test Lab o BrowserStack. Configura matrice device-OS rappresentativa del tuo audience. Crash che colpiscono solo Galaxy A12 con Android 10 richiedono test su quel device specifico. Investi in device farm o cloud testing per coverage adeguata.
Procedura passo-passo
- Configura simbolizzazione automatica nel CI.
- Definisci alert su nuove crash con impatto > soglia.
- Triage settimanale dei crash top per impatto.
- Riproduci il crash o ricostruisci con breadcrumb.
- Sviluppa il fix con test di regressione.
- Rilascia su track di test prima della produzione.
- Verifica la chiusura del crash nei dashboard.
Test specifici per device problematici
Identificati device/OS con crash rate disproporzionato (vedi Firebase Device Distribution), aggiungi a matrice di test obbligatoria. Galaxy A12 e Android 10 spesso emergono come problematici. iPhone 8 e iOS 15 sono il floor minimo per molte app. Investe in physical device farm o cloud testing per coverage adeguata.
Errori comuni e come risolverli
- Reazione caotica: senza prioritizzazione si fissano crash irrilevanti.
- Simbolizzazione manuale: rallenta e introduce errori. Automatizza.
- Mancanza di breadcrumb: il crash e nudo, impossibile capire.
- Fix senza test: il crash ritorna con la prossima release.
- KPI assenti: senza crash-free user rate non sai se migliori.
Domande frequenti
D: Crashlytics o Sentry?
R: Crashlytics e gratuito e integrato con Firebase; Sentry e più potente per error tracking esteso (anche backend).
D: Quanti crash sono accettabili?
R: Crash-free user rate > 99,5% e un buon target standard; > 99,8% per app finanziarie.
D: I crash report contengono PII?
R: Possono. Configura il filtering per non inviare dati sensibili.
D: Come trattare crash di librerie terze?
R: Aggiorna la libreria, segnala issue al maintainer, isola con try-catch se possibile. Ultima risorsa: rimpiazza la libreria.
Conclusione
Crash report sono goldmine se gestiti con disciplina. Workflow strutturato (triage, priorità, fix, verifica) trasforma reazione caotica in processo predicibile. Combina con post-mortem per apprendimento continuo. Team mobile maturi hanno crash-free rate >99.5% come norma, non eccezione.
Triage crash settimanale come ritual del team mobile: 30 minuti, top 10 crash, decisioni di priorità. Documenta in shared dashboard. Crea ticket per i top 3-5 ogni settimana. Misurare progress nel tempo: crash-free rate trend, time-to-fix trend, recurring patterns. Disciplina paga in qualità prodotto migliorata significativamente nel tempo.
Integrazione con sistema di ticketing (Jira, Linear, Asana) automatizza creation di ticket per crash più impattanti, mantenendo backlog ordinato.
Documentazione di crash storici in wiki interno aiuta a riconoscere pattern. Quando un crash riemerge dopo mesi, la documentazione storica accelera diagnosis. Mantieni sezione "Lessons Learned" con casi notevoli, root cause, fix applicato. Per team mobile maturi, questa knowledge base diventa asset di valore significativo.
Hai bisogno di aiuto?
Se vuoi sviluppare la tua app con G Tech Group, scrivici tramite il modulo di contatto.