Un nome di azienda scritto in modo errato nella home page e un arresto anomalo di una funzionalità di esportazione utilizzata raramente: quale risolvere per prima? Argomentazioni come queste sono il motivo per cui i team di test separano gravità e priorità. Uno descrive il danno tecnico e l’altro descrive l’urgenza aziendale.

Senza questa distinzione, ogni bug viene etichettato come “critico”, le etichette perdono il loro significato e gli sviluppatori smettono di fidarsi di loro. Questa guida fornisce definizioni ed esempi chiari, insieme a un semplice processo per prendere queste decisioni. Gli esempi sono illustrativi e le scale esatte differiscono a seconda dei team e degli strumenti.

La risposta breve

Severità risponde: quanto gravemente questo bug influisce sul prodotto? Un arresto anomalo o una perdita di dati sono gravi, mentre un problema estetico non lo è.

Risposte Priority: quanto presto dovremmo risolverlo? Ciò dipende dai clienti interessati, dalle scadenze, dai ricavi, dall’esposizione legale e dalla reputazione del marchio.

Pensa a un ospedale. La gravità indica la gravità delle condizioni del paziente. La priorità è l’ordine in cui i pazienti vengono curati, che dipende anche da altri fattori, come chi può aspettare in sicurezza e quali risorse sono disponibili.

Gravità e priorità fianco a fianco

Livelli di gravità

La maggior parte delle squadre utilizza circa quattro o cinque livelli. Ecco una scala comune:

Livelli di priorità

Annota cosa significa ogni livello per la tua squadra, idealmente con un tempo di risposta target per ciascuno. “P1 significa che qualcuno inizierà entro un’ora” è molto più utile di “P1 significa molto importante”.

Le quattro combinazioni, con esempi

Il modo più chiaro per capirlo è guardare ciascuna combinazione:

Alta gravità, alta priorità

Il pagamento fallisce per tutti, l’azienda perde denaro di minuto in minuto e non esiste alcuna soluzione alternativa. Questo è il caso ovvio: molla tutto e aggiustalo.

Gravità alta, priorità bassa

L’applicazione si arresta in modo anomalo durante l’esportazione in un formato precedente. Tecnicamente si tratta di un grave fallimento. Ma se solo una piccola parte di utenti tocca questa funzionalità e un formato moderno funziona bene, può attendere un rilascio programmato.

Bassa gravità, alta priorità

Il nome dell’azienda è scritto male nella home page. Niente è rotto e nessun dato è a rischio. Eppure ogni visitatore lo vede, ciò danneggia la fiducia e se domani è previsto un lancio importante, è necessario risolverlo oggi.

Bassa gravità, bassa priorità

Un piccolo errore di battitura in un articolo della guida visitato raramente. Risolvilo quando è conveniente. Se il tuo arretrato è pieno di questi, valuta la possibilità di raggrupparli in un’unica attività di pulizia.

Un bug, due priorità diverse

Lo stesso difetto può meritare priorità diverse a seconda del contesto. Supponiamo che un’e-mail di conferma dell’ordine venga inviata con il logo sbagliato.

La gravità non è cambiata perché l’impatto sul sistema è lo stesso. Ma la situazione aziendale sì. Anche il tempo può cambiare le cose. Un bug che oggi è P3 potrebbe diventare P1 la settimana prima del go-live di un cliente importante.

Chi decide severità e priorità?

• I tester solitamente propongono la severità, poiché hanno visto il comportamento e compreso l’impatto sul sistema.
• I proprietari o i gestori del prodotto di solito decidono la priorità, poiché valutano i clienti, le entrate e la tabella di marcia.
• Gli sviluppatori aggiungono informazioni sulla causa, sul rischio di una soluzione e sul tempo necessario.
• I team di supporto forniscono prove di quanti clienti sono colpiti e in che misura.

Le fonti e i team variano in base a queste responsabilità e in una piccola startup una persona può fare tutto. Ciò che conta è che tutti sappiano chi fa la decisione finale, quindi i disaccordi finiscono con una decisione.

Come valutare un bug

Quando non sei sicuro, risolvi queste domande.

Per gravità:

1. Perde o danneggia dati o espone informazioni private?
2. Interrompe il funzionamento di una funzione principale?
3. Esiste una soluzione alternativa e un utente normale potrebbe trovarla?
4. Quanta parte della funzionalità è interessata?

Per priorità:

1. Quanti utenti sono interessati e quali?
2. Costa denaro o crea rischi legali o di conformità?
3. È in arrivo una release, una demo o una vendita?
4. Quanto è visibile e potrebbe danneggiare la tua reputazione?
5. Blocca altri lavori, come i test?

Esecuzione del triage dei bug

Il triage è la riunione regolare in cui un team esamina i nuovi bug e decide cosa succede dopo. Un formato semplice funziona bene:

1. Prepararsi. Il tester si assicura che ogni nuovo bug abbia passaggi chiari, prove e gravità proposta.
2. Conferma. Controlla che sia riproducibile e che non sia un duplicato.
3. Decidi. Concorda la gravità, imposta una priorità e assegna un proprietario.
4. Chiudi il ciclo. Rifiuta, rinvia o pianifica ogni bug e registra il motivo.

Mantienilo breve e frequente. Durante gli ultimi giorni prima del rilascio, è comune un triage quotidiano di 15 minuti. La gravità e la priorità alimentano anche la tua decisione di rilascio, quindi concorda subito delle regole, come “nessun bug S1 o S2 aperto al momento del rilascio”, come parte dei tuoi criteri di uscita.

Gravità e priorità in una segnalazione di bug

Una voce breve e chiara aiuta tutti a prendere una buona decisione:

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Queste cifre sono esempi. In un rapporto reale, utilizza i numeri misurati dai tuoi registri e spiega il tuo ragionamento. Scopri di più nella nostra guida su come scrivere una segnalazione di bug. È utile anche sapere cosa significano i codici di errore, quindi tieni a portata di mano il nostro trucco sui codici di stato HTTP.

Errori comuni

• Trattarli come lo stesso campo. Se i due corrispondono sempre, stai perdendo informazioni utili.
• Aumentare la gravità per attirare l’attenzione. Una volta che tutto è critico, niente lo è.
• Lasciare che siano i tester a stabilire da soli le priorità. Raramente hanno il quadro completo dell’azienda.
• Non rivedere mai il backlog. Le priorità diventano obsolete, quindi ricontrolla regolarmente i vecchi bug.
• Non esistono definizioni scritte. Senza di esse, le persone applicano le etichette in modo diverso e si finisce per discutere sulle parole.
• Ignorare gli accumuli di problemi di bassa gravità. Cinquanta problemi minori possono far sembrare un prodotto rotto, anche se nessuno di essi è grave da solo.

Considerazioni finali

Mantieni separate le due domande: quanto è grave la situazione e quanto presto deve essere risolta? Concordare definizioni scritte per ciascun livello e chiarire chi decide. Come passaggio successivo, prendi i dieci bug più vecchi nel tuo tracker e rivalutali utilizzando le domande sopra. Probabilmente ne troverai alcuni che dovrebbero essere spostati e altri che dovrebbero essere chiusi.

Domande frequenti

Continua a imparare