Come avviene la gestione dei difetti nel processo di testing

Fasi del processo di testing

La complessità dei sistemi sviluppati oggi assegna grande importanza ad una buona pianificazione e realizzazione della fase di testing software. L’introduzione delle tecnologie legate alla Rete, inoltre, ha portato ad una sostanziale modifica dell’architettura applicativa e ad una più specifica e, spesso, più critica necessità di soddisfare le esigenze dell’utenza. Questa, diventata più eterogenea, vasta e globale (è il caso delle applicazioni di ebusiness) pone in luce nuovi aspetti tecnici e qualitativi del software: sicurezza delle transazioni, tempi di risposta della rete e dell’applicazione stessa, disponibilità h24 e 7/7 dei servizi offerti dall’applicazione, usabilità ed altre caratteristiche ancora ( il tema è trattato in un capitolo specifico di questo manuale).

La metodologia di test identifica le seguenti fasi o macro attività (tra parentesi sono riportati i nomi in inglese):

1. Pianificazione dei test (Test Planning);
2. Preparazione e sviluppo dei test (Test Preparation / Development);
3. Esecuzione dei test (Unit Test, Integration Test, System Test, Acceptance Test);
4. Gestione dei difetti (Defect Management);
5. Monitoraggio e reportistica dei test (Test Monitoring and Reporting);
6. Gestione del processo di test (Test Process Management);
7. Gestione della configurazione di test (Test Configuration Management).

Gestione dei difetti

La gestione dei difetti (o gestione dei bug) rilevati durante l’esecuzione dei test è generalmente definita a livello di processo di test ed è seguita da tutti i progetti (a meno di richieste specifiche del cliente che andranno comunque concordate, documentate e conservate come evidenze). Ogni progetto ne fa menzione nel proprio documento di piano di test. Eventuali deviazioni saranno chiaramente descritte e quindi approvate insieme al piano. L’attività include la registrazione dei difetti, la loro segnalazione, la correzione degli errori, la verifica della correzione, la gestione dello stato delle segnalazioni, l’analisi statistica dei difetti.

Flusso di gestione dei difetti

La presenza di più stati dell’anomalia implica la definizione di un flusso come quello mostrato nella Figura 10 (esempio generale).
La gestione degli stati è facilitata dall’utilizzo di uno strumento informatico.
La gestione manuale risulta comunque semplice e richiede l’utilizzo di un modello (scheda) per la registrazione dei difetti e la relativa risoluzione. In Appendice è riportato un esempio di modello da utilizzare per la registrazione manuale dei difetti e la relativa gestione dello stato di risoluzione, inclusi i rapporti periodici da produrre.

Segue la descrizione del flusso:

1. Apertura del problema.
   Colui che riscontra il problema (generalmente il tester) registra l’anomalia con lo stato “Aperto” e riporta le informazioni di base necessarie a gestire il problema (data e ora, nominativo, descrizione del difetto rilevato, tipo di attività svolta, gravità, fase di test, caso di test che ha rilevato il malfunzionamento, altre informazioni utili quali, ad esempio, documentazione disponibile, ecc.).
2. Notifica del problema.
   L’anomalia è notificata al responsabile della risoluzione dei problemi (generalmente il coordinatore del gruppo di sviluppo). La notifica è automatica quando si utilizzi uno strumento informatico, altrimenti dovrà essere eseguita manualmente. In ogni caso è registrato il tempo (data e ora) della notifica ai fini della rilevazione del tempo di risoluzione dei problemi.
3. Assegnazione del problema.
   Il responsabile della risoluzione dei difetti analizza il problema per verificarne la validità e può proseguire su due diverse linee di condotta:
   1. Accettazione del problema.
      Se il problema è ritento “valido”, lo si accetta come tale e lo si assegna ad un membro del team di sviluppo per la sua risoluzione. Questi lo analizza nei dettagli, individua la soluzione più opportuna, individua i componenti da modificare, effettua le correzione, valida le correzioni eseguendo i casi di test opportuni, aggiorna i campi relativi alla risoluzione del problema ed aggiorna lo stato del problema come “Risolto”; i dati relativi alla risoluzione del problema (data e ora, tipo di problema identificato, tipo di soluzione adottata, elenco dei componenti modificati, tipo di test effettuato, risultato dei test effettuati) sono memorizzati per consentire l’analisi statistica dei problemi e poter intervenire per il miglioramento dei processi..
   2. Rifiuto del problema.
      Se il problema è ritenuto “non valido”, lo si rifiuta (in gergo, lo si “rigetta”) e notifica di ciò chi ha aperto il problema. Costui, se d’accordo, pone l’anomalia in stato di “Chiuso” segnalando che il problema è stato “rigettato”; altrimenti innesca un processo di negoziazione per trovare un accordo. Anche in questo caso si registrano le informazioni relative allo stato (data e ora, motivazione del rifiuto, accettazione del rifiuto).
4. Disponibilità della soluzione.
   Lo sviluppo notifica il tester della disponibilità della soluzione marcando il problema come “Risolto”. Anche in questo caso si registra la data e l’ora della notifica.
5. Validazione della soluzione.
   Il tester riesegue il caso di test che ha rilevato l’anomalia per verificare la correttezza della soluzione. A seconda dell’esito della verifica, può quindi proseguire secondo due diverse linee di condotta:
   1. Accettazione della soluzione.
      Se l’esito del test è positivo, accetta la soluzione e pone l’anomalia nello stato “Validato”. Il responsabile dei test deciderà in seguito di passare lo stato dell’anomalia come “Chiuso”. Anche in questo caso sarà registrata la data e l’ora del passaggio di stato.
   2. Rifiuto della soluzione.
      Se l’esito dei test è negativo, si rinvia il problema al gruppo di sviluppo per la risoluzione definitiva. In questo caso l’anomalia, dallo stato “Risolto” in cui l’aveva posta il programmatore ritorna allo stato di “Assegnato”, come lo era prima della sua risoluzione. Anche in questo caso si registra la data e l’ora del passaggio di stato con un commento sulla motivazione del rifiuto. Quindi si ritorna al punto 3 del flusso, opzione a). Sarà infatti improbabile che si possa verificare l’opzione b).

Lo stato “chiuso” è quindi indotto da due diverse situazioni: “Problema rigettato” (perché non valido o duplicato) o “Test con esito positivo”.

Come si vede dalla descrizione del flusso, ogni cambiamento di stato è registrato in termini di data e ora e informazioni che ne consentono la gestione.

Analisi statistica

La registrazione dei momenti di passaggio di stato permettono di calcolare i tempi di gestione dei problemi secondo i seguenti punti di vista:

Lato gruppo di test:

• Tempo medio di notifica dei problemi;
• Tempo medio di validazione della soluzione;

Lato gruppo di sviluppo:

• Tempo medio di risoluzione del problema;

Lato project management:

• Tempo medio di gestione dei problemi.

L’utilizzo di uno strumento informatico permette una gestione automatica di tali misurazione e la produzione altrettanto automatica di rapporti statistici per la valutazione dell’efficacia del team di progetto.

La registrazione delle anomalie permette quindi di gestire la qualità del software prodotto e la capacità di risoluzione degli errori. Il rapporto periodico (Test Report) fornisce i valori sul numero dei difetti rilevati, degli errori risolti e di quelli in attesa di essere risolti. Un progressivo accumulo di difetti da analizzare e risolvere (backlog) indica, per esempio, che il gruppo di sviluppo non è in grado di far fronte al processo di rimozione degli errori. Analogamente un eccessivo accumulo di errori risolti e non ancora validati indica l’inadeguatezza (in termini di prestazioni) del gruppo di test.

Inoltre, la registrazione dei difetti permette di effettuare la l’analisi delle cause degli errori e di migliorare il processo di sviluppo.

Indicando la tipologia di errore corretto (per esempio, errore imputabile al codice, alla progettazione, ai dati, alle specifiche, ai requisiti, alla documentazione utente, al caso di test eseguito, all’ambiente, ecc.) è possibile creare delle statistiche sulle cause più frequenti dei difetti ed intervenire sulle attività di sviluppo (migliorare la fase di analisi e progettazione, potenziare le ispezioni, imporre standard di programmazione, ecc.).

Infine, l’analisi causale dei difetti permette quindi il miglioramento del processo e si basa sulla disponibilità dei dati registrati.