Anche se i documenti di test report sono tradizionalmente associati a Waterfall, possono contribuire anche al processo di sviluppo Agile. Una sintesi del test report contiene infatti tutti i dettagli degli ambienti in cui il codice è stato testato, chi lo ha testato, quando e come è stato testato, serve come un registro fisico che riporta esattamente anche il codice testato, la configurazione in cui ciò è avvenuto e qualsiasi bug eventualmente emerso durante questo processo.
Ci sono alcune organizzazioni IT che creano test report di oltre 20 pagine ma la lunghezza di questo documento è soggettiva. L’obiettivo generale della sintesi di un test report è quello di riportare le azioni e i risultati di un test per permettere al team di prendere decisioni informate su quali miglioramenti procedurali possono essere fatti per test futuri. Spesso un team di sviluppo può usare i test report per verifiche interne a seguito di un reclamo del cliente, ma questi documenti andrebbero redatti regolarmente durante il processo di test per creare un software migliore in ogni ciclo di sviluppo.
Nello sviluppo Agile, una relazione riassuntiva del test rappresenta una registrazione della sua esecuzione e, rispetto al Waterfall, è meno formale e più focalizzata sui risultati. Qui di seguito una serie di consigli su come scrivere un test report e perché la sua sintesi può essere utile nello sviluppo Agile del software.
Cosa c’è in un report test?
Prima di creare un test report è necessario determinare il target e le motivazioni per cui lo si realizza. Per esempio, se un’applicazione richiede un audit trail per ragioni normative, nel report test probabilmente andranno inseriti dati più specifici, se invece il documento è destinato al management di alto livello che vuole capire cosa il team ha testato per ogni release, allora meglio includere una sintesi che delinei le principali funzioni testate. Oppure, se il report è più un audit che non sarà letto da nessuno a meno che non venga rilevato un bug critico, lo si può strutturare in modo che includa solo informazioni tecniche.
Mentre queste sintesi dovrebbero tutti includere le stesse informazioni di base necessarie per il target di destinazione, non c’è una formula per i report test e si possono aggiungere o sottrarre dati quando serve per raggiungere l’obiettivo. Le quattro componenti principali che devono essere sempre presenti sono:
Obiettivo del test.
Precisare l’obiettivo vuol dire spiegare che tipo di test è stato eseguito, e perché. Per esempio, se il report test riguarda test funzionali, di regressione e di performance, va descritto l’obiettivo per ogni tipo di test.
Nella maggior parte dei casi, il test di regressione è lo scopo principale dell’esecuzione del test e il suo obiettivo può variare, ma un team di solito lo esegue per cercare i difetti una volta che gli sviluppatori aggiungono il codice di nuove funzionalità a una base di codice già esistente. Il test di regressione viene fatto prima di ogni nuovo rilascio e varia in lunghezza di tempo e profondità di test. Se il test di regressione di un team include integrazione, performance o altri tipi di test, va indicato lo scopo di ogni test nella sezione degli obiettivi del report.
Test case, copertura e dettagli di esecuzione.
Il prossimo elemento di questa guida su come scrivere un test report è spiegare la suite di test precisando quale tipo di test è stato eseguito, quando e dove è memorizzato. Si può anche aggiungere il nome del professionista QA che ha eseguito il test, ma non è un requisito specifico come invece lo sono il come/cosa/perché e i risultati effettivi del test.
È necessario anche stabilire quanti test con lo stesso scopo sono stati eseguiti, passati, falliti e i test saltati rappresentano quelli che un team, dopo averli pianificati, non ha effettuato per vincoli di tempo o per segnalazioni di difetti e, in questi casi, andrebbe incluso anche quanto codice hanno testato. Lo si può fare usando applicazioni e strumenti di gestione dei test e se non sono disponibili, ci si può rivolgere al team di sviluppo per una stima della copertura dei test.
I dettagli di esecuzione, registrati manualmente o tracciati da un programma di gestione, includono chi ha testato il codice, quando e dove. Esiste una certa flessibilità su come visualizzare i dati e i dettagli dei test, spesso dipende dal numero di quelli eseguiti ma in generale un test report può includere una griglia di dati generali per visualizzare le informazioni o un altro rapporto di dati. Anche in questo caso non c’è una regola fissa per includere queste informazioni e si può valutare di volta in volta cosa è meglio fare.
Conteggio dei difetti.
Un altro aspetto importante è documentare quali difetti sono stati rilevati: si tratta di una sezione di importanza fondamentale per l’analisi post-test e chi scrive i test report non dovrebbe semplicemente elencare i numeri di identificazione dei bug ma includere una breve descrizione di ogni bug per non far perdere tempo a chi interviene dopo. Non vi è bisogno di elencare ogni bug trovato nei test, meglio verificarne l’esistenza prima di includerlo nel test report.
Va rivisto molto attentamente l’elenco dei difetti per verificare che ci siano bug conosciuti o già nel backlog di riparazione. Questa sezione dovrebbe essere dedicata ai difetti trovati nel rilascio dichiarato organizzati in base alla loro priorità. Difetti e bug vengono trovati sempre ma sono la loro priorità e gravità che determinano se si può effettuare il rilascio verso i clienti oppure servono riparazioni.
Dettagli di configurazione della piattaforma e dell’ambiente di test.
Questo è un tema complesso, i dettagli sono importanti, ma è necessario anche considerare la sicurezza e la compliance quando si condividono informazioni riguardanti il codice di un’applicazione. Si assume che il target di destinazione generalmente comprenda il sistema di test e non è questo il caso in cui è opportuno rivelare dettagli sui server di un’applicazione e sulla memorizzazione del codice.
Una volta condiviso il test report, non è detto che sia conservato in modo sicuro, meglio elencare il nome del server e le date, ma limitandosi ai dati di base. Se la configurazione non era standard, devono essere incluse anche queste informazioni, se invece lo è, la configurazione standard deve essere documentata all’interno del team di test per riferimento.
Per esempio, se, durante il test, la configurazione cambia e causa difetti, nel test report è necessario includere questa informazione perché qualcuno potrà analizzare l’effetto che questo ha sull’ambito o sulla profondità dei difetti e sulla copertura generale dei test.
Capire per chi è un rapporto di test
L’importanza del report test dipende davvero dai bisogni di un particolare business, è un documento comodo per tracciare i risultati dei test per rilascio, così i membri di un’organizzazione IT sanno cosa è stato testato e quando. Che si tratti di un documento formale o di un semplice riassunto di ciò che è stato fatto, un report test contribuisce ad un migliore sviluppo del software.
