La gestione dei difett

Quando un sistema fornisce un output differente dai requisiti in input, ovvero in caso di deviazione dai requisiti di business, è possibile affermare di essere in presenza di un difetto del software.

Quando il team dedicato ai test esegue i casi di test, si imbatte in una situazione in cui il risultato effettivo del test è diverso dal risultato atteso. Questo gap è definito come un difetto. Fondamentalmente, un difetto del software è una condizione che non soddisfa i requisiti del software stesso. Il difetto è un errore che produce un comportamento imprevisto o errato del sistema. Per gestire i progetti in modo appropriato, è necessario sapere come gestire lo sviluppo e il rilascio, ma oltre a ciò è necessario sapere come gestire i difetti.

Se l’identificazione dei difetti, la risoluzione e la loro tracciatura avvenisse verbalmente, il processo di gestione si perderebbe nel mezzo di difetti effettivamente corretti e funzionanti come previsto, risolti ma ancora non funzionanti, difetti posticipati. Per controllare e gestire efficacemente i difetti, è necessario un processo di gestione dei difetti strutturato.

Il ciclo di vita del difetto assicura che il processo sia uniforme e standardizzato. Un difetto raggiunge diversi stati durante il proprio ciclo di vita. Dopo che un difetto è stato trovato passa attraverso varie fasi che compongono quello che è noto come Defect Life Cycle, ciclo di vita del difetto. Generalmente, il ciclo di vita del difetto inizia dalla fase in cui il difetto viene rilevato dal team di test e termina quando un difetto viene chiuso.

Esistono una varietà di modelli, metodi e strumenti per aiutare le organizzazioni a gestire i difetti riscontrati nello sviluppo di un software. La tracciatura e l’elaborazione dei difetti devono essere integrati nel ciclo di vita del progetto e nel processo di test del software.

In breve, il processo di correzione inizia con la scoperta di un difetto del prodotto e normalmente termina con la correzione dello stesso o con la decisione che il difetto non deve essere corretto in quel preciso momento. Il processo di gestione dei difetti solitamente rientra all’interno di un processo più grande a cui ci si riferisce

126

semplicemente come ciclo di vita del progetto che, come detto, può assumere differenti forme che vanno da un modello di progetto a cascata (Waterfall) a un modello Agile oppure Extreme Programming (XP), come presentato in figura 77:

Figura 77: Metodologie di progetto secondo sondaggio di Forrester

L’intersezione del processo di gestione dei difetti con il ciclo di vita del progetto può essere meglio apprezzata pensando a un difetto che non può essere corretto nel ciclo di rilascio in corso, ma può, dovrebbe e verrà corretto prima della versione finale del software. Allo stesso modo, il processo di gestione dei difetti rientra nell’ambito di un altro processo, ovvero il test del software (Humphrey). L’intersezione di quest’ultimi processi può essere vista in due aree: anzitutto, ci sono difetti che possono essere risolti come duplicati di altri difetti già registrati. In secondo luogo, verificare che i difetti che sono stati corretti in un test precedente continuino a funzionare come previsto anche nei test successivi, come ad esempio nei test di regressione. Dal momento che il processo di gestione dei difetti spesso è più formale dei processi utilizzati nel ciclo di sviluppo, esistono occasioni in cui questo viene utilizzato per guidare progetti, processi di test o entrambi nei punti di intersezione.

Il processo di gestione dei difetti inizia quando un difetto viene scoperto e termina quando il difetto viene risolto, sperabilmente eliminato, prima del rilascio della versione più immediata del software (Jacobson, Booch, Rumbaugh, 1999).

127

5.3.1 Modelli di gestione

Molte se non la maggior parte delle aziende che sviluppano e gestiscono applicazioni software utilizzano delle metodologie di gestione dei difetti (Black, 1999, Rahman, 2004). Mentre esistono ampie differenze tra le diverse metodologie di implementazione, i diversi modelli di gestione dei difetti hanno molte caratteristiche in comune. La forma più semplice di modello rappresenta due stati con tre cambiamenti di stato: scoperta del difetto, correzione o altra risoluzione, e verifica della risoluzione. Il modello è riportato in figura 78:

Figura 78: Modello a due stati con tre cambiamenti di stato

In pratica, questo modello viene espanso in un modello a tre stati rappresentato in figura 79. Per esempio, il difetto prevalente, o “bug process”, come viene chiamato in Microsoft (Kipman) ha tre stati di base:

• Submitted/Open; • Resolved;

• Closed.

Figura 79: Modello a tre stati con quattro cambiamenti di stato

Lo stato closed riflette che i difetti risolti e testati sono attività chiuse, ma che possono di fatto essere riaperte in un secondo momento. Il semplice modello a tre stati è la base per la maggior parte dei difetti segnalati per un sistema software.

128

5.3.2 La metodologia di gestione dei difetti adottata

Durante l’esecuzione dei test E2E e degli UAT, attività durata circa un mese come rappresentato in figura 80, sono stato responsabile della gestione dei difetti riscontrati in seguito ai test svolti, nonché tester di alcuni di questi.

Figura 80: Sovrapposizione E2E testing e UAT

Il processo di gestione dei difetti adottato, riportato in figura 81, è così articolato:

129

1. Il tester esegue lo step contenuto nel file excel; 2. Il tester riscontra un problema;

3. Il tester comunica il difetto riscontrato; 4. Il tester imposta il difetto come Open;

5. Il tester mi invia un’email riportante la descrizione del difetto, il tipo di sistema impattato, il nome dell’assegnatario che si dovrà occupare della sua risoluzione, la priorità del difetto e la sua severità;

6. Il difetto viene preso in carico dall’assegnatario che imposta lo stato come In progress e lavora alla risoluzione del difetto;

7. Una volta risolto, l’assegnatario imposta lo stato come Fixed ed esegue nuovamente il test;

8. Se il test al punto precedente ha successo, lo step relativo al difetto è pronto per essere assegnato nuovamente al tester e viene impostato come Ready for retest;

9. Lo step relativo al difetto viene testato nuovamente. Se il difetto è definitivamente risolto, questo viene impostato come Closed e il corrispondente step di test viene contrassegnato come Completed. Se il difetto non è ancora risolto, il suo stato viene impostato come Re-Opened e viene inviata a me una nuova email.

Per quanto riguarda la compilazione del file creato per tracciare i difetti raccolti, visibile in figura 82, per ogni nuovo difetto riscontrato il relativo processo di tracciatura è il seguente:

1. Lo step dello script di test correlato al difetto riscontrato viene impostato come Blocked;

2. Nella lista dei difetti contenuti nel file viene creato un nuovo difetto, compilando i seguenti campi: il numero progressivo ID che identifica il difetto (Defect Id), la sua descrizione (Defect Summary), la data di rilevazione (Detected On), il sistema impattato dal difetto (System impacted), il tipo (Type) di difetto (funzionale, di integrazione, di dato), colui che l’ha riscontrato (Defect Owner), lo stato (Status), la priorità (Priority), la severità (Severity), la data di risoluzione attesa (Fix Due Date), e il numero identificativo del caso di test impattato (Scripts impacted).

130

Figura 82: Metodo di tracciatura dei difetti

In generale, un difetto può assumere uno dei seguenti stati: • Open: il difetto viene impostato come aperto dal tester;

• In progress: il difetto si trova attualmente sotto investigazione; • Fixed: il difetto è risolto e quindi testato dallo sviluppatore;

• Ready for Retest: il difetto è pronto per essere testato di nuovo dal tester; • Duplicate: il difetto è identico a uno vecchio ancora open;

• Rejected: il difetto non è considerato un reale difetto;

• Re-Opened: il difetto, che è già stato risolto, viene nuovamente riscontrato durante i test eseguiti e quindi riaperto;

• Closed: il difetto viene confermato come risolto dal tester;

• Deferred: il difetto viene posticipato. La sua risoluzione verrà presa in considerazione prossimamente.

La priorità e la severità di un difetto possono assumere 4 stati: 1. Critica;

2. Elevata; 3. Media; 4. Bassa.

131

Figura 83: Priorità e severità di un difetto

La priorità è definita come l’impatto del difetto su unità di business differenti da quelle che l’hanno riscontrato.

La severità è l’impatto che il difetto ha su altri casi di test.

La risoluzione di tutti i difetti contenuti nella lista coincide con il rilascio del software nell’ambiente di produzione e, quindi, con il go-live.