Il testing software: la gestione degli incidenti

Dato che uno degli obiettivi del testing è di trovare difetti (bug), le discrepanze tra i risultati attuali e quelli attesi necessitano di essere registrati come incidenti. Un incidente deve essere analizzato e può tramutarsi in difetto. Per questo motivo, devono essere definite appropriate azioni per gestire gli incidenti e i difetti. Di fatto, gli incidenti devono essere tracciati dalla scoperta e classificazione fino alla correzione e conferma della loro soluzione. Un’ organizzazione deve definire un processo di gestione degli incidenti e delle regole per la loro classificazione.
Bisogna anche dire che gli incidenti possono emergere durante lo sviluppo, le review, il testing o l’utilizzo di un prodotto software. Essi possono presentarsi per problemi nel codice o nel funzionamento del sistema o in ogni tipo di documentazione, compresa quella sui requisiti, documenti di sviluppo, documenti di testing, e informazioni per l’utente come l’ “Help” o le guide di installazione.

Le registrazioni degli incidenti hanno i seguenti obiettivi principali:

1. Fornire agli sviluppatori e ad altri ruoli dei riscontri sui problemi per facilitarne l’identificazione, l’isolamento e le correzioni necessarie.
2. Fornire ai responsabili di test uno strumento di tracciamento per valutare la qualità del sistema sotto test e l’avanzamento del testing.
3. Fornire idee per il miglioramento del processo di testing.

D’altro canto, i dettagli nei report degli incidenti possono includere:

1. Date del problema rilevato, organizzazione e autore.
2. Risultati attuali ed attesi.
3. Identificazione dell’ elemento di test (elemento sotto configurazione) e dell’ambiente di testing.
4. Processo del ciclo di vita del software o del sistema nel quale è stata riportato l’incidente.
5. Descrizione dell’incidente per consentirne la riproduzione e la risoluzione, comprendente logs, dumps di database o screenshots.
6. Portata o grado dell’impatto sugli interessi degli stakeholders.
7. Severità dell’impatto sul sistema.
8. Urgenza/priorità di risoluzione.
9. Stato dell’ incidente (ad esempio, aperto, differito, duplicato, in attesa di essere risolto, risolto in attesa di essere ritestato, chiuso).
10. Conclusioni, raccomandazioni e approvazioni.
11. Problemi globali, come altre aree che possano essere affette da una modifica risultante dall’ incidente.
12. Storico delle modifiche (change history), come la sequenza delle azioni prese dai membri del team di progetto con riferimento all’isolamento dell’ incidente, della sua riparazione e della conferma della sua risoluzione.
13. Riferimenti, compresi l’identificazione del test case specifico che ha rilevato il problema.

Infine bisogna notare che, la struttura di un report di incidente è descritta precisamente anche nello ‘Standard for Software Test Documentation’ (Standard IEEE 829).