Il test, che abbiamo dimostrato non essere una tecnica valida per ottenere la qualità globale, resta pur sempre una valida via di verifica del lavoro svolto.

Analizziamo la "storia" degli errori e malfunzionamenti di un programma rispetto a quello di un oggetto fisico.

Una automobile nuova, appena uscita dal concessionario, va trattata con cura nei primi chilometri di vita. E’ la fase di "rodaggio", durante la quale possono esserci dei malfunzionamenti dovuti alla giovinezza dell’oggetto.

Passata questa prima fase, la nostra macchina funziona con una necessità costante di manutenzione fino all’"obsolescenza", dove incomincia a presentare i problemi dovuti all’usura dei materiali, finchè siamo costretti a portala dal rottamatore.

Un programma ha invece una storia dei malfunzionamenti completamente diversa. Alla nascita vengono riscontrati parecchi errori, che vengono via via corretti. L’uso non introduce usura, e tutto procede con un rateo sempre decrescente di nuovi problemi.

Idealmente potremmo arrivare ad avere, dopo un adeguato lasso di tempo, delle applicazioni praticamente privi di errori.

Ma il software "invecchia", e dopo un certo periodo è necessario apportare grosse modifiche per implementare nuove caratteristiche, per adeguare il programma alle mutate esigenze.

Questi interventi fanno ripartire la storia degli errori finchè i nuovi pezzi di codice non hanno avuto una verifica esaustiva.

Questi continui cicli di produzione "stressano" l’architettura originale fino ad arrivare al punto in cui mantenere è impossibile perchè non c’è più lo spazio per inserire nuove possibilità. A questo punto il programma è diventato vecchio ed è da "rottamare".

Il modello più attendibile degli errori è quindi una funzione decrescente nel tempo: all’inizio vengono rilevati parecchi nuovi errori, poi il numero pian piano scende, fino ad un valore che tende a zero.

Questo comportamento porta ad una naturale strategia: rilasciare il programma solo dopo aver superato la fase "di rodaggio", in cui il numero di errori è molto elevato.

Terminata la codifica viene svolta quindi una fase di "alfa test", cioè una serie di test "in house", finchè il numero di errori sia sceso ad un livello accettabile dalle specifiche iniziali.

I test non possono completare esaustivamente ogni percorso ed ogni dato, per cui accade che alla consegna del programma l’utente rileva nuovi errori.

Questo avviene perchè il programma viene usato con dati completamente diversi da quelli di prova, cosicchè vengono percorse nuove strade mai verificate.

Ancora vi sarà una fase in cui gli errori sono molti, con una rapida diminuzione fino a rientrare nel livello accettato. Questo momento viene indicato con "beta test".

Raggiunto un livello di confidenza con il programma compatibile con le specifiche stabilite in analisi, sia da parte degli sviluppatori che degli utenti, si considera rilasciato il programma. Ogni ciclo di manutenzione o di nuova implementazione ripercorre questo schema.

I test, come abbiamo già evidenziato, non possono essere svolti a casaccio: troverebbero casualmente errori qui e là, ma potrebbero lasciarne molti nascosti all’interno del prodotto software.

Occorre quindi stabilire a priori quali sono le caratteristiche da testare, le zone di programma che svolgono funzioni critiche o complesse, e quindi richiedono una maggiore attenzione.

A partire dall’analisi e via via nelle altre fasi è quindi necessario stabilire un piano dei test, che sarà attuato in questa fase. Senza un preciso piano non ci sono garanzie sufficienti per la qualità finale del prodotto.

Le tecniche strutturate devono essere applicate anche al test: per prima cosa si testano i singoli moduli, quindi l’integrazione dei blocchi fino al programma completo.

Un programma alla fine non sarà mai totalmente privo di errori, al massimo avrà un numero basso di errori residui. Raggiunta una situazione accettabile sarà rilasciato e l’utente dovrà convivere con gli errori residui.