Differenza tra Piano di test, Specifica dei test case e Rapporto del test

Documentazione del testing software: il Piano di test

La documentazione di test software (IEEE 829) si compone di tutti gli elaborati prodotti durante la progettazione del test e nell’analisi, che vanno raccolti e conservati nell’organizzazione. Lo scopo è quello di creare un punto di riferimento per futuri utilizzi. I documenti sono di solito custoditi gelosamente all’interno dell’azienda in quanto costituiscono un patrimonio operativo, nel senso che racchiudono informazioni circa l’organizzazione del lavoro, delle competenze, delle conoscenze maturate dall’impresa nel tempo ed utilizzate in quel particolare progetto.

I costi di sviluppo del software sono fortemente legati anche alla attività di testing, in particolare se si desidera attribuire a questa fase un ruolo importante nella fase di progettazione e validazione. Nel caso di progetti complessi, non si può parlare solo di costo, ma anche di complessità aggiunta che questa fase si porta dietro. Creare una documentazione precisa, che si basi su uno standard consolidato permette di minimizzare notevolmente la difficoltà di creazione di tali elaborati. Ci chiediamo dunque:

“esistono delle linee guida che ci aiutino nella realizzazione della documentazione di test?”

La risposta è sì, ed il punto di riferimento è costituito dal documento ANSI/IEEE 829: esso richiede l’elaborazione di una esaustiva documentazione nella quale venga descritta la fase di test in tutti i suoi aspetti, il che costituisce una buona base per una eventuale certificazione ISO che l’azienda possa interessata ad ottenere.

Come prima considerazione, emerge il concetto di “buona documentazione”. Una buona documentazione è spesso un giudizio soggettivo, ma proprio per questo possiamo affermare che la sua utilità è centrata introno al concetto di specificità, o meglio, “una documentazione è valida quando è disegnata in maniera specifica per un pubblico particolare”. È possibile utilizzare dei template generali, ovvero dei modelli predefiniti da seguire che vanno però adattati alle specifiche esigenze di progetto; tale scelta è tipica delle organizzazioni che intendono standardizzare le loro attività ed abituare i clienti (lettori del documento) ad una certa forma organizzativa. Un buon documento è difficile da generare, per questo possiamo affermare che la sua validità sia collegata alla sua facilità di creazione, di uso e di lettura.

L’IEEE 829 schematizza i documenti necessari per il test del software:

1. Piano delle specifiche (Test Design Specification)
2. Specifica dei test case (Test case Specification)
3. Rapporto del test (Test Log)
4. Rapporto dei problemi di testing (Test Incident Report)
5. Rapporto complessivo di test (Test Summary Report)

L’unione di tali elementi produce il Piano di Test.

Vediamo maggiormente nel dettaglio le fasi e la documentazione richiesta dal IEEE 829:

Piano delle specifiche (Test Design Specification)

Il documento del Piano delle specifiche descrive i requisiti della prova. In particolare, identifica le caratteristiche o le funzioni generali da esaminare, dettaglia il metodo della prova, propone una spiegazione razionale per l’insieme dei casi della prova e stabilisce i test di verifica di pass/fail. Fornisce quindi una linea di base della prova.

Specifica dei test case (Test case Specification)

Questo documento descrive precisamente che cosa deve essere esaminato. Può consistere in un documento molto voluminoso; similmente ad un software richiede la documentazione dei contenuti. Richiede un identificazione di ogni prova, input ed output previsti. Per la sua realizzazione sarebbe necessario un linguaggio formale in grado di esprimere le caratteristiche dei casi della prova, cioè un linguaggio di specifica di prova. Poiché non esistono standard per tale linguaggio, ogni organizzazione è obbligata a definire i propri.

Rapporto del test (Test Log)

Il rapporto del test dovrebbe registrare i casi, o le transazioni elaborate, i percorsi della prova attraversati, i valori in input ed i valori intermedi così come i risultati finali. È un importante mezzo di documentazione della quantità e della qualità della prova, oltre che lo sforzo sostenuto.

Rapporto dei problemi di testing (Test Incident Report)

Il rapporto di problemi del testing segnala tutti i problemi che possono verificarsi durante la prova. Include gli errori, i difetti, le discrepanze e qualunque altro comportamento che differisce da quanto previsto. Il tester è invitato a registrare l’avvenimento celermente, documentando il momento in cui si è presentato, il test case usato ed i risultati ottenuti. Tale rapporto è usato come garanzia della qualità, come base per l’analisi dei difetto e, naturalmente per la correzione degli errori. Può essere standardizzato facilmente. I campioni sono forniti dallo standard dello IEEE.

Rapporto complessivo di test (Test Summary Report)

Il documento complessivo di test è il resoconto sommario della prova. Valuta la comprensività del processo, ricapitola i risultati delle prove e documenta lo sforzo della prova. È inteso come informazioni per la valutazione della gestione, ma può anche servire da base per fare un’analisi di costi/benefici e una valutazione generale di qualità.

Elaborazione del Piano di Test (Testplan)

Il documento descrive gli obiettivi, la portata del test ed i riferimenti. Vengono poi definiti gli oggetti della prova, le funzioni da esaminare, le funzioni da non esaminare, il metodo della prova, l’ambiente della prova, i test di verifica di accettazione della prova, i risultati della prova, le attività della prova, i requisiti della prova, le responsabilità della prova, i personali, le scadenze, i rischi e le misure di contingenza.

L’importanza della documentazione nel testing

Il paragrafo precedente mostra come il piano di test, la progettazione delle specifiche e la specifica delle prove siano le fasi di creazione della documentazione di test, indispensabile punto di riferimento dei tester per la loro attività; l’attenzione su questo particolare non è dettata dalla norma IEEE, che lascia per’altro libera l’organizzazione di scegliere le tecniche che ritiene più idonee per questo aspetto, dal formato elettronico al cartaceo alla unione di entrambi. È comunque importante considerare che il tester deve disporre di una documentazione valida e completa, che gli permetta di seguire un percorso logico di riferimento nelle sue prove: in assenza di essa si avrebbe uno svolgimento molto più lungo in termini di tempo, disorganizzato, ovviamente incompleto e sommario.
Ma il tester possiede anche un ruolo attivo in questo contesto: se dalla sua attività emerge che nuove prove sono necessarie al fine di scoprire bug latenti o di indagare sulla loro origine, egli stesso può progettarne di nuove, comunicarle ai relatori che provvederanno ad aggiornare la documentazione e predisporre l’attività di test. La collaborazione è dunque indispensabile per la riuscita di un buon lavoro.