In questa guida
Due parole vengono confuse continuamente. Gravità indica quanto è grave il bug per l'utente: cosa si rompe. Priorità indica quanto presto lo correggi: una decisione che dipende anche da quante persone sono colpite, da quanto è facile un workaround e dalla data di rilascio. Chi lavora da solo ha bisogno di definire entrambe una volta, così lo stesso bug riceve la stessa valutazione di lunedì e di venerdì.
Definizioni di gravità (copia e adatta)
S1 Critica L'app va in crash, i dati si perdono o si corrompono, si addebita un importo sbagliato,
oppure un flusso principale non si può completare. Nessun workaround.
S2 Grave Una funzione principale è rotta o molto difficile da usare, ma esiste un workaround.
S3 Minore Una funzione non principale non funziona bene, oppure una principale in un caso limite.
S4 Banale Estetica: refuso, disallineamento, piccolo difetto visivo.
Portata (quante persone sono colpite)
Molti La maggior parte degli utenti, o tutti, su un dispositivo / OS / flusso comune
Alcuni Un gruppo chiaramente definito (una famiglia di dispositivi, una lingua, un tipo di account)
Pochi Condizioni rare o un solo caso segnalato
La matrice
Priorità in base a gravità (righe) e portata (colonne):
| Molti | Alcuni | Pochi | |
|---|---|---|---|
| S1 Critica | P0: correggi subito, blocca il rilascio | P0: correggi subito | P1: correggi prima del rilascio |
| S2 Grave | P1: correggi prima del rilascio | P1: correggi prima del rilascio | P2: prossimo rilascio |
| S3 Minore | P2: prossimo rilascio | P2 o P3 | P3: backlog |
| S4 Banale | P3: backlog | P3: backlog | P3: backlog, o chiudi |
Significato delle priorità: P0 lascia tutto. P1 va corretto prima che questo rilascio esca. P2 si pianifica per il prossimo rilascio. P3 backlog, si corregge quando capita.
Modello per valutare un bug (copia e incolla)
BUG: <titolo>
Gravità: S<1-4> Portata: <molti / alcuni / pochi> Priorità: P<0-3>
Workaround: <sì: descrivi / no>
Perché questa valutazione: <una frase>
Decisione: <correggi subito / prima del rilascio / prossimo rilascio / backlog> Data: <data>
Esempio (illustrativo)
BUG: L'app va in crash salvando con un titolo vuoto
Gravità: S1 Portata: Alcuni (solo gli utenti che saltano il campo titolo) Priorità: P0
Workaround: inserisci un titolo
Perché questa valutazione: crash con perdita di dati sull'azione di salvataggio principale; un workaround non elimina il crash.
Decisione: correggi subito Data: 2026-11-05
Come adattarlo
- Cambia la priorità con una ragione. Le regole valgono per il 90 percento dei casi; annota perché ne hai infranta una.
- Alza la priorità per i rischi fuori dalla matrice: problemi di sicurezza o privacy, errori di pagamento e tutto ciò che potrebbe violare le regole dello store non devono aspettare. Controlla per ultime le policy attuali.
- Usa dati reali quando li hai. I report sui crash mostrano la portata; vedi [come dare priorità ai report sui crash e [come dare priorità al feedback sull'app.
- Al massimo quattro livelli. Più livelli significano più discussioni e nessuna decisione migliore.
- Di' ai tester cosa intendi, così le loro stime di gravità coincideranno con le tue; l'ultima parola resta a te.
Correlati
- Hub: Hub dei test per app mobili: tutte le aree in un posto
- [Lista dei problemi noti per i tester
- [Checklist go / no-go per il rilascio
Inizia gratis per raccogliere segnalazioni di bug in modo strutturato, poi valutale con questa matrice.