La documentazione del processo di testing software

Il processo di testing software, come mostrato in precedenza, genera un quantitativo impressionante di documentazione di vario tipo.

Ognuno di questi documenti è in relazione con gli altri e tutti insieme formano una sorta di reticolo informativo, che deve guidare coloro che si occupano del testing nella pianificazione, nella progettazione, nell’implementazione, nell’esecuzione, nella valutazione e nell’analisi.

Il sistema della documentazione di test è abbastanza complesso e articolato, ma essendo generato da un processo a fasi sequenziali, dove l’output generato dalla fase precedente generalmente costituisce l’input di quella successiva, è possibile ricostruirlo e schematizzarlo.

Come detto in precedenza, un piano di test generale prende corpo essenzialmente dall’analisi dei requisiti e dalle specifiche di progetto nella fase di pianificazione, per essere poi raffinato e integrato con le specifiche dei test da effettuare, con i particolari casi di test e con le procedure per eseguirli.

L’implementazione genera il codice di tutti i casi di test previsti in fase di progettazione, ma anche in questa fase la descrizione di tale codice viene codificata nella documentazione tecnica.
Infine, una volta mandati in esecuzione i test, i risultati prodotti dall’applicazione stessa vengono confrontati con quelli attesi.
I risultati di tale valutazione e analisi vengono salvati in test log e test summary report.

La seguente figura mostra come ogni fase del processo di testing venga meticolosamente documentata per successivi fini.

Importanza della Documentazione di Test

Mentre il processo di testing stabilisce una certa misura per cui un’applicazione soddisfa i suoi requisiti, o meglio non li soddisfa, la documentazione generata, invece, descrive il modo con cui ciò avviene.
Per ogni requisito non soddisfatto, quindi ogni malfunzionamento verificatosi, tramite la documentazione è spesso possibile risalire al difetto applicativo che l’ha causato.
La presenza di documentazione offre vantaggi ancor più tangibili per i test di unità, dove lo scopo principale resta comunque il debugging, estremamente agevolato in fase di localizzazione degli errori nel codice e correzione degli stessi.

Ma non è tutto, poiché può non essere affatto intuitivo tradurre una mancanza o una difformità di un requisito con un difetto applicativo.
Può essere proprio una questione di uso di linguaggi differenti per la stesura e definizione dei requisiti e delle specifiche, rispetto alla sintassi e la semantica usati per definire gli stessi oggetti in un linguaggio di programmazione.

L’attività di testing sembra essere l’interprete più appropriato in questo contesto e la documentazione è il suo dizionario.
Inoltre, la documentazione di test si comporta come un mezzo di comunicazione sia all’interno del team incaricato al testing, che tra questo team e quello di sviluppo, dando una visione globale dell’attività, mettendo a fuoco i collegamenti con la realtà applicativa e spiegandone il significato.
Nonostante queste riflessioni facciano emergere l’importanza della documentazione di test e il ruolo fondamentale da essa giocato, spesso tali documenti risultano imprecisi, scorretti o addirittura mancanti.
Questo si spiega con il grande sforzo in termini di risorse, tempo e denaro necessario alla produzione e aggiornamento di tali documenti.

Considerando che l’attività di testing avviene poco prima del rilascio di un prodotto software, è soprattutto il tempo richiesto alla sua realizzazione ad essere visto come un ostacolo.
Proprio quando i tempi di consegna sono agli sgoccioli o addirittura sono sorpassati e magari il cliente desidera vedere subito in funzione il proprio applicativo, la documentazione di test viene abbandonata.

Inoltre, gli sviluppatori spesso considerano la generazione di tali documenti un compito poco gratificante.
Infatti, se generati manualmente, portano a compiere azioni meccaniche e ripetitive, privando lo sviluppatore di quella componente creativa tipica del suo ruolo.

Mancanza di Documentazione nel Software Open Source

Nel caso in cui l’applicazione in fase di test sia un prodotto Open Source la produzione di documentazione completa e aggiornata risulta un compito ancora più arduo.
Lo sviluppo di tali prodotti coinvolge l’impegno di più programmatori dislocati in diversi luoghi, con uno stile e un approccio di lavoro differente e non appartenenti a realtà organizzate come invece accade per aziende, uffici o imprese.

Inoltre, la comunicazione tra gli sviluppatori spesso avviene mediante canali disorganizzati e non ufficiali, come mailing list e forum, che rendono difficile il coordinamento e l’uniformità di obbiettivi e metodologie utilizzate.

In questo scenario i dati di un Software Open Source risultano essere frammentari e non omogenei, rendendo ancora più difficile la creazione della relativa documentazione.
D’altra parte, però, è proprio la documentazione ad aiutare ad avere una visione globale del prodotto, descrivendolo dal punto di vista strutturale e operativo.
Infatti, uno dei primari motivi che frenano la scelta di utilizzare questo tipo di software, è che vengono spesso rilasciati senza manuali e documentazione delle specifiche.

D’altro canto, le classiche metodologie di testing sono basate sulla separazione dei test dal codice applicativo, che comporta un’ulteriore disgregazione all’interno del codice di un prodotto Open Source.
Questo può portare alla mancanza di una linea comune su come deve avvenire il testing dell’applicativo.
La generazione della relativa documentazione di test assume un ruolo di fondamentale importanza, in quanto può aiutare ad avere una visione di insieme e a chiarire gli obbiettivi e le modalità del testing, facilitando il regolare svolgimento di tutte le fasi del processo.