Glossario · Fondamenti del testing
Priorità del bug
In inglese: Bug priority
Detto anche: priorità del difetto, livello di priorità, livelli di priorità
Definizione
Quanto è urgente correggere un difetto rispetto al resto del lavoro, in base alle esigenze di business. Di solito la decide il product owner o il bug triage.
La priorità di un bug descrive l’ordine in cui i difetti vengono corretti. È una decisione di business che soppesa l’impatto sugli utenti, le scadenze, gli impegni con i clienti, la reputazione e il costo della correzione. I tester possono suggerire una priorità, ma l’ultima parola spetta di solito al product owner, spesso in una riunione di triage con sviluppo e QA.
Scala tipica
| Priorità | Significato |
|---|---|
| P1 / Urgente | Correggere subito, può servire un hotfix fuori dal normale rilascio |
| P2 / Alta | Correggere nello sprint corrente o prima del prossimo rilascio |
| P3 / Media | Pianificare in uno sprint futuro |
| P4 / Bassa | Correggere quando conviene, oppure accettare e chiudere |
Priorità e severità
La severità misura l’impatto: quanto è compromesso il prodotto. La priorità misura l’urgenza: quanto presto va corretto. Si valutano separatamente perché spesso non coincidono.
- Severità bassa, priorità alta: un prezzo sbagliato mostrato in un banner per una campagna che parte domani. Non si blocca nulla, ma deve essere corretto prima del lancio.
- Severità alta, priorità bassa: un crash in un report amministrativo che viene eseguito solo a fine anno, tra undici mesi.
Inoltre la priorità cambia nel tempo, mentre la severità di solito no. Quello stesso crash di fine anno diventa P1 a dicembre.
Come si decide la priorità
Domande utili durante il triage:
- Quanti utenti sono colpiti, e quali (clienti paganti, personale interno, un solo tenant)?
- Esiste un workaround, e il supporto è in grado di spiegarlo?
- C’è una scadenza legata a un rilascio, una demo, obblighi legali o contrattuali?
- Qual è il costo e il rischio della correzione stessa? Una correzione rischiosa a fine rilascio può essere rimandata deliberatamente.
Errori comuni
- Usare un solo campo per entrambe. I team che tracciano solo la “priorità” perdono l’informazione sull’impatto, che conta per il rischio di rilascio e per le metriche.
- Tutto è P1. Quando quasi tutti i bug sono urgenti, nessuno lo è. Mantieni il livello più alto raro e ben definito.
- Non rivedere mai la priorità. Rivaluta i bug aperti quando cambiano il piano di rilascio o la situazione dei clienti.