Corso ISTQB — Modulo 8: Monitoraggio, controllo e gestione dei difetti

Nei moduli precedenti abbiamo guardato come si pianifica e si progetta il testing. Qui ci spostiamo sul versante operativo e gestionale: come si tiene sotto controllo l’attività mentre procede, come la si misura, come la si comunica a chi deve decidere, come si tracciano le versioni degli oggetti coinvolti e, infine, come si gestiscono i difetti dal momento in cui emergono fino alla loro chiusura. All’esame ISTQB Foundation questi temi pesano in modo concreto: le domande raramente chiedono definizioni mandate a memoria, più spesso chiedono di distinguere ruoli che si somigliano (monitoraggio contro controllo, rapporto di avanzamento contro rapporto di sintesi) oppure di riconoscere quali informazioni rendono completo un rapporto di difetto. I temi corrispondono al capitolo 5 del syllabus, in particolare alla gestione delle attività di test (monitoraggio e controllo, gestione della configurazione e gestione dei difetti).

Monitoraggio e controllo del test

Conviene tenere ben distinti tre concetti che a parole sembrano vicini, ma che l’esame sfrutta proprio per separare le risposte.

Monitoraggio del test: è l’attività di osservare e raccogliere informazioni su come procede il testing rispetto a quanto pianificato. In sé non modifica nulla: misura e riporta. Esempio: ogni sera annoto quanti casi di test ho eseguito, quanti sono passati, quanti falliti e quanti difetti nuovi sono stati registrati.
Controllo del test: è l’attività di prendere decisioni e mettere in atto azioni correttive sulla base di ciò che il monitoraggio ha mostrato, allo scopo di riportare il lavoro verso gli obiettivi. È la parte che agisce. Esempio: notando che una funzionalità produce troppi difetti, decido di assegnarvi più tester oppure di rinviare le aree che dipendono da quella ancora instabile.
Completamento del test (test completion): è la chiusura ordinata dell’attività, con archiviazione del testware, raccolta delle lezioni apprese e consegna del rapporto finale. Non va confuso con il controllo.

Il legame da fissare per l’esame è semplice: il monitoraggio fornisce i dati, il controllo li usa per agire. Le decisioni di controllo nascono dal confronto fra la situazione osservata e ciò che era stato definito in pianificazione, compresi i criteri di uscita.

Metriche e copertura

Per monitorare servono metriche, cioè misure che danno una lettura oggettiva di avanzamento e qualità. È utile distinguerle per ambito:

Metriche di progetto e di processo: per esempio la percentuale di attività di preparazione completate, il numero di casi di test pronti, la disponibilità dell’ambiente di test.
Metriche di test (esecuzione): casi eseguiti, passati, falliti, bloccati; tempo impiegato; copertura raggiunta.
Metriche dei difetti: numero di difetti individuati, densità, tempo medio di correzione, percentuale di difetti riaperti dopo la correzione.
Metriche di confidenza e di rischio: rischi residui e valutazioni del team sulla maturità del prodotto.

La copertura (coverage) richiede un’attenzione particolare, perché ricorre spesso nelle domande. La copertura indica quanta parte di un determinato insieme di elementi è stata esercitata dal testing, rispetto al totale di quegli elementi, ed è sempre riferita a un criterio dichiarato. Si può parlare di copertura dei requisiti, di copertura del codice (istruzioni, decisioni), di copertura dei rischi e così via. Il punto chiave: una copertura del 100% rispetto a un criterio non equivale a “nessun difetto” né a “tutto testato”; dice soltanto che quel particolare insieme di elementi è stato coperto secondo quel criterio. Resta quindi un indicatore parziale, da leggere insieme alle altre metriche.

Esempio concreto: in un’applicazione di prenotazione voli ho 80 requisiti e i miei casi di test ne esercitano 72. La copertura dei requisiti è 72/80 = 90%. Questo dato non dice nulla su quanto siano approfonditi quei casi, né su quanti difetti restino nel prodotto: indica solo che 8 requisiti su 80, cioè il 10%, non sono ancora coperti da alcun test.

Rapporti di test: avanzamento e sintesi

L’andamento del testing va comunicato agli stakeholder, e l’esame chiede di distinguere bene due tipi di rapporto.

Test progress report (rapporto di avanzamento): redatto durante un’attività di test, in modo periodico (per esempio ogni giorno o ogni settimana), per sostenere le decisioni di controllo in corso d’opera. Risponde alla domanda “a che punto siamo ora?”. Di solito riporta lo stato rispetto al piano, gli ostacoli incontrati, le metriche aggiornate di esecuzione e difetti, ed eventuali nuovi rischi.
Test summary report (rapporto di sintesi): redatto al termine di un’attività o di un livello di test, per riassumere ciò che è stato svolto. Risponde alla domanda “come è andata nel complesso?”. Di solito riporta il riepilogo dell’attività, la valutazione rispetto ai criteri di uscita, le metriche aggregate finali, i rischi residui, le raccomandazioni e le lezioni apprese.

Un aspetto rilevante, ribadito dal syllabus, è che il rapporto va adattato al destinatario: un rapporto rivolto al team tecnico conterrà dettagli su difetti e copertura del codice, mentre un rapporto destinato alla direzione sarà più sintetico e orientato a rischi, costi e decisione di rilascio. Oggi parte della comunicazione passa anche da dashboard aggiornate quasi in tempo reale, ma il principio non cambia: far arrivare le informazioni giuste alle persone giuste nel momento giusto.

Gestione della configurazione

La gestione della configurazione (Configuration Management, CM) serve a stabilire e mantenere l’integrità dei prodotti di lavoro: codice, documentazione, ambienti, dati di test e, in particolare, il testware (casi di test, script, dati, risultati attesi). Senza CM il testing diventa inaffidabile, perché si perde traccia di quale versione del software è stata provata con quale versione dei casi di test.

Per sostenere correttamente il testing, la CM dovrebbe assicurare che:

tutti gli elementi di test, testware compreso, siano identificati in modo univoco, posti sotto controllo di versione e collegabili tra loro;
ogni elemento citato nella documentazione di test sia riconducibile a una versione precisa;
resti documentato su quale baseline è stato eseguito ciascun test, così da poter riprodurre i risultati.

Esempio: un tester apre un difetto scrivendo “il login fallisce”. Senza CM lo sviluppatore non sa su quale build sia stato osservato. Con la CM il rapporto indica la build 2.4.17 e il set di dati set_clienti_v3: il difetto diventa riproducibile e gestibile.

Da ricordare: una baseline è una versione “congelata” e approvata di un insieme di elementi, dalla quale si parte e rispetto alla quale si misurano i cambiamenti successivi.

Il processo di gestione dei difetti

I difetti emergono lungo tutto il ciclo di vita, comprese le revisioni statiche e non solo i test dinamici, quindi serve un processo che li accompagni dalla scoperta alla chiusura. Conviene ripassare i termini, perché l’esame li mette spesso a confronto:

Errore (error/mistake): l’azione umana che porta a un risultato scorretto, per esempio uno sviluppatore che interpreta male un requisito.
Difetto (defect/bug/fault): l’imperfezione introdotta nel prodotto di lavoro a seguito dell’errore, per esempio una porzione di codice scritta in modo errato.
Malfunzionamento (failure): il comportamento osservabile non corretto che si manifesta quando il difetto viene eseguito.
Anomalia: qualunque condizione che si discosta dalle aspettative; può rivelarsi un difetto oppure no, come nel caso di un falso positivo o di un problema dell’ambiente di test.

Un tipico processo di gestione dei difetti prevede la registrazione dell’anomalia, l’analisi e la classificazione (è davvero un difetto? con quale priorità e quale severità?), la decisione su come trattarlo, la correzione da parte dello sviluppo, la verifica e la chiusura tramite confirmation testing, oltre alla raccolta di statistiche per migliorare il processo nel tempo. Una precisazione terminologica importante: la priorità esprime l’urgenza con cui affrontare il difetto, soprattutto in ottica di business, mentre la severità esprime la gravità del suo impatto sul prodotto. Un difetto può avere severità alta ma priorità bassa, e viceversa: all’esame questa distinzione è una trappola ricorrente.

Contenuto di un rapporto di difetto

Un defect report (rapporto di difetto) ha tre scopi: dare agli sviluppatori le informazioni necessarie per riprodurre e correggere, consentire di tracciare lo stato del difetto e fornire dati per valutare la qualità del prodotto e del processo. Un rapporto ben fatto contiene di norma elementi come:

un identificativo univoco e un titolo sintetico;
la data di scoperta, chi lo ha individuato e l’attività in cui è emerso (test di sistema, revisione e così via);
l’oggetto di test e l’ambiente coinvolti, con le relative versioni: qui emerge il legame con la gestione della configurazione;
una descrizione chiara con i passi per riprodurre il problema, il risultato atteso e quello osservato, integrati da log o screenshot quando utili;
la severità dell’impatto e la priorità dell’intervento;
lo stato all’interno del ciclo di vita del difetto (per esempio aperto, in correzione, risolto, chiuso, respinto o duplicato);
eventuali riferimenti al requisito, al caso di test o alla regola violata.

Esempio poco utile: “Il carrello non funziona.” Esempio efficace: “ID#1287 — Build 2.4.17, ambiente di staging: aggiungendo al carrello un prodotto con sconto del 50% (passi: …), il totale mostrato resta il prezzo pieno (atteso: 10 €, osservato: 20 €). Severità: alta; priorità: alta; collegato al requisito REQ-CHK-09.” Il secondo è riproducibile, tracciabile e misurabile.

Termini chiave

Monitoraggio del test = raccolta e osservazione continua dei dati sull’andamento del testing rispetto al piano.
Controllo del test = decisioni e azioni correttive intraprese sulla base dei dati di monitoraggio per riallineare il lavoro agli obiettivi.
Metrica = misura usata per valutare avanzamento o qualità di processo, test, difetti o livello di confidenza.
Copertura = quota di un insieme di elementi (requisiti, codice, rischi e così via) esercitata dal testing rispetto a un criterio definito.
Test progress report = rapporto periodico prodotto durante l’attività, a sostegno del controllo in corso d’opera.
Test summary report = rapporto conclusivo che riassume e valuta un’attività o un livello di test.
Gestione della configurazione = pratica per identificare, versionare e mantenere integri gli elementi di lavoro e il testware.
Baseline = versione approvata e “congelata” di un insieme di elementi, usata come riferimento per i cambiamenti.
Difetto = imperfezione in un prodotto di lavoro che, se eseguita, può provocare un malfunzionamento.
Severità = gravità dell’impatto di un difetto. Priorità = urgenza con cui affrontarlo. Sono indipendenti.
Rapporto di difetto = documento che descrive un’anomalia per riprodurla, tracciarla e analizzarla.

Errori comuni all’esame

Confondere monitoraggio e controllo. Il monitoraggio osserva e misura; il controllo agisce. Se la risposta parla di “decidere di spostare risorse”, siamo nel controllo, non nel monitoraggio.
Scambiare rapporto di avanzamento e rapporto di sintesi. L’avanzamento è prodotto durante l’attività (per decidere ora), la sintesi al termine (per riepilogare). Tempistica e scopo sono l’indizio decisivo.
Credere che una copertura del 100% significhi assenza di difetti. La copertura è relativa a un criterio e non garantisce qualità né esaustività.
Trattare severità e priorità come sinonimi. Sono indipendenti: un blocco raro su una pagina poco usata può avere severità alta ma priorità bassa.
Confondere errore, difetto e malfunzionamento. L’errore è umano, il difetto è nel prodotto, il malfunzionamento è ciò che si osserva durante l’esecuzione.
Pensare che i difetti nascano solo dai test dinamici. Anche le revisioni statiche li individuano e vanno gestiti con lo stesso processo.
Dimenticare le versioni nel rapporto di difetto. Senza build e ambiente (il legame con la CM) il difetto rischia di non essere riproducibile.

In sintesi

Il monitoraggio raccoglie dati e metriche; il controllo usa quei dati per intraprendere azioni correttive verso gli obiettivi.
Le metriche e la copertura sono indicatori parziali: utili, ma da interpretare insieme e mai come prova di “software senza difetti”.
Il rapporto di avanzamento serve durante l’attività a supporto del controllo, il rapporto di sintesi serve al termine per riepilogare; entrambi vanno adattati al destinatario.
La gestione della configurazione rende il testing affidabile e riproducibile, legando ogni risultato a versioni precise di software e testware.
Il processo di gestione dei difetti accompagna l’anomalia dalla registrazione alla chiusura, tenendo sempre distinte severità e priorità.
Un buon rapporto di difetto è riproducibile, tracciabile e misurabile: identificativo, versioni, passi, atteso contro osservato, severità, priorità e stato.