Che cos’è, a cosa serve e importanza del test report nel testing software

Monitoraggio e Controllo dei Test

Nell’ambito del testing software, lo scopo del monitoraggio dei test è raccogliere informazioni e fornire feedback e visibilità sulle attività di test. Le informazioni da monitorare possono essere raccolte manualmente o automaticamente e dovrebbero essere utilizzate per valutare l’avanzamento dei test e per misurare se i criteri di uscita del test (o le attività di test associate a una “definition of done” di un progetto Agile) sono soddisfatti, come il raggiungimento degli obiettivi per la copertura dei rischi di prodotto, dei requisiti o dei criteri di accettazione.

Il controllo dei test descrive le linee guida o le azioni correttive adottate a seguito di informazioni e metriche raccolte e (possibilmente) documentate. Le azioni possono coprire qualsiasi attività di test e possono influenzare qualsiasi attività del ciclo di vita del software.

Esempi di azioni di controllo dei test includono:

Ri-prioritizzare i test quando si verifica un rischio identificato (ad esempio software consegnato in ritardo)
Modificare la schedulazione dei test, a causa della disponibilità o indisponibilità di un ambiente di test o di altre risorse
Rivalutare se un elemento di test soddisfa un criterio di ingresso o di uscita, a causa di un rework

Metriche Usate nel Testing

Le metriche possono essere raccolte durante e alla fine delle attività di test, al fine di valutare:

L’avanzamento rispetto alla schedulazione e al budget pianificati
La qualità attuale dell’oggetto di test
L’adeguatezza dell’approccio di test
L’efficacia delle attività di test rispetto agli obiettivi Comuni metriche di test includono:
Percentuale del lavoro svolto nella preparazione dei test case rispetto al pianificato (o percentuale dei test case implementati rispetto ai pianificati)
Percentuale del lavoro svolto nella preparazione dell’ambiente di test rispetto al pianificato
Esecuzione dei test case (ad esempio numero di test case eseguiti/non eseguiti, test case passati/falliti, e/o condizioni di test passate/fallite)
Informazioni sui difetti (ad esempio densità dei difetti, difetti rilevati e corretti, tasso di failure e risultati dei test confermativi)
Copertura del test in termini di requisiti, user story, criteri di accettazione, rischi o codice
Completamento delle attività, allocazione e utilizzo delle risorse, e relativo effort
Costo del testing, che include il costo rispetto al beneficio di tilevare il successivo difetto o il costo rispetto al beneficio di eseguire il test successivo

Scopo, Contenuto e Destinatari dei Test Report

Lo scopo del reporting dei test è di riassumere e comunicare le informazioni sull’attività di test, sia durante che alla fine di un’attività di test (ad esempio un livello di test). Il test report preparato durante un’attività di test può essere definito come Test Progress Report; un report preparato alla fine di un’attività di test può essere definito come Test Summary Report.

Durante il monitoraggio e il controllo dei test, il Test Manager prepara regolarmente i Test Progress Report per gli stakeholder. In aggiunta al contenuto comune dei Test Progress Report e Test Summary Report, tipici Test Progress Report possono includere anche:

Lo stato delle attività di test e l’avanzamento rispetto al Test Plan
I fattori che ne impediscono l’avanzamento
I test pianificati per il prossimo periodo di riferimento
La qualità dell’oggetto di test

Quando vengono raggiunti i criteri di uscita, il Test Manager prapara il Test Summary Report. Questo report fornisce un riepilogo del testing eseguito, sulla base dell’ultimo Test Progress Report e di ogni altra informazione pertinente.

Tipici Test Summary Report possono includere:

Riepilogo dei test eseguiti
Informazioni su quello che è accaduto durante un periodo di test
Deviazioni dal piano, comprese deviazioni nella schedulazione, nella durata o nell’effort delle attività di test
Stato del testing e della qualità del prodotto rispetto ai criteri di uscita (o “definition of done“)
Fattori che hanno bloccato o continuano a bloccare l’avanzamento
Metriche relative ai difetti, ai test case, alla copertura dei test, all’avanzamento dell’attività e all’utilizzo delle risorse
Rischi residui
Prodotti di lavoro del test che possono essere riutilizzabili

Il contenuto di un test report varia in base al progetto, a requisiti organizzativi e al ciclo di vita dello sviluppo software. Ad esempio, un progetto complesso con molti stakeholder o un progetto normativo possono richiedere un reporting più dettagliato e rigoroso, rispetto al reporting di un semplice aggiornamento software. Come altro esempio, nello sviluppo Agile, i Test Progress Report possono essere incorporati nelle task board, nei summary sui difetti e nei burndown charts, e possono essere discussi durante il daily stand-up meeting.

In aggiunta al tailoring (adattamento) dei test report in base al contesto del progetto, i test report possono essere adattati in base ai loro destinatari. Il tipo e la quantità di informazioni che dovrebbero essere inclusi per un audience tecnica o un team di test possono essere differenti da quelli inclusi in un Executive Summary Report. Nel primo caso, può essere importante riportare informazioni dettagliate sui tipi di difetti e sul relativo andamento. Nel secondo caso, può essere più appropriato un report di alto livello (ad esempio un riepilogo sullo stato dei difetti suddivisi per priorità, budget, schedulazione, e sulle condizioni di test passate/fallite/non testate).

Lo standard ISO (ISO/IEC/IEEE 29119-3) fa riferimento a due tipi di test report, il Test Progress Report e il Test Completion Report (chiamato Test Summary Report in questo Syllabus) e riporta strutture ed esempi per ogni tipo.