Bug software: Definizione e differenza tra priorità e impatto (severity)

Definizione di Bug

Un bug di programma o bug software è un errore che ha come conseguenza un cattivo funzionamento del software. In linea di massima, le origini dei bachi devono essere individuate nei codici sorgenti che vengono scritti dai programmatori, mentre più raramente possono essere dovute al compilatore. In inglese si usa l’espressione “buggy” per segnalare un programma caratterizzato da un numero elevato di bug che hanno l’effetto di interferire e compromettere la sua funzionalità: in italiano si dice, semplicemente, “bacato”.

Come detto, gli effetti dei bug possono essere variegati. A volte sono inesistenti o comunque non visibili perché incidono in maniera poco significativa sulle funzionalità del software, così da restare praticamente nascosti per molto tempo. Altre volte possono essere molto importanti, soprattutto se determinano un blocco del software o un crash, da cui deriva una negazione del servizio che si desidera ottenere.

Definizione della Priority e Severity

I campi severity e priority sono entrambi molto importanti per classificare i bug software e stabilire le priorità se e quando i bug verranno corretti. I livelli di severity e priorità dei bug verranno definiti come indicato nelle seguenti tabelle. Il test assegnerà un livello di severity a tutti i bug. Il responsabile del test sarà responsabile di verificare che a ciascun bug sia assegnato un livello di severity corretto.

Il responsabile del controllo qualità, responsabile dello sviluppo e responsabile del progetto parteciperanno alle riunioni di revisione dei bug per assegnare la priorità di tutti i bug attualmente attivi. Questo incontro sarà noto come “Bug Triage Meetings”. Il responsabile del controllo qualità è responsabile della creazione di queste riunioni su base regolare per affrontare l’insieme attuale di bug nuovi ed esistenti ma non risolti.

Elenco di severity

Il tester che inserisce un bug in un sistema di tracciamento bug è anche responsabile dell’inserimento della severity del bug.

1. Critico: il modulo/prodotto software si arresta in modo anomalo o il bug provoca condizioni non recuperabili. Arresti anomali del sistema, errori GP o danneggiamento del database o dei file o potenziale perdita di dati, blocchi del programma che richiedono il riavvio sono tutti esempi di Sev. 1.
2. Alto: un componente di sistema principale è inutilizzabile a causa di guasti o funzionalità errata. I bug con Sev. 2 causano seri problemi come la mancanza di funzionalità o messaggi di errore insufficienti o poco chiari che possono avere un impatto notevole sull’utente, impediscono il test di altre aree dell’applicazione, ecc. I bug Sev. 2 possono essere aggirati, ma aggirarli è scomodo o difficile.
3. Medio: sono funzionalità errata del componente o del processo. Generalmente esiste una semplice soluzione per il bug se è Sev. 3.
4. Minori: si tratta di errori di documentazione o bug con bassisimo impatto a livello funzionale.

Elenco di priorità

Il tester che inserisce un bug in un sistema di tracciamento bug è anche responsabile dell’inserimento della priorità dello stesso.

1. Must Fix: questo bug deve essere risolto immediatamente; il prodotto non può rilasciato con questo bug.
2. Fix When Have Time: questi sono problemi importanti che dovrebbero essere risolti al più presto. Sarebbe imbarazzante per l’azienda se questo bug sarebbe rilasciato in produzione.
3. Fix When Have Time: il problema deve essere risolto entro un tempo disponibile. Se il bug non ritarda la data di rilascio, deve essere corretto.
4. Low Priority (Bassa priorità): non è importante (in questo momento) affrontare questi bug. Devono essere corretti dopo aver corretto tutti gli altri bug con priotà più alte. Generalmente si tratta di miglioramenti per le funzionalità dell’applicazione software.