Testing software: Cos’è, a cosa serve e come scrivere il Test Plan

Il Test Plan è un documento obbligatorio che deve essere presentato come allegato alla fase di test di un prodotto. I seguenti campi devono essere presenti in un Test Plan.

Un Test Plan redatto in maniera corretta aumenta le possibilità che il software funzioni in modo corretto; risulta infatti possibile concentrare l’attenzione dei test sulle aree che vengono identificate come quelle più a rischio di malfunzionamento. Queste riguardano non soltanto gli aspetti fondamentali del programma che devono sistematicamente funzionare in maniera corretta, ma anche in quali aspetti le conoscenze tecniche degli sviluppatori sono più deboli. Per identificare queste aree è di assoluta importanza raccogliere il maggior numero di informazioni possibili dai vari attori che hanno contribuito alla realizzazione del programma, oltre a consultare gli archivi contenenti dati ed errori riscontrati e catalogati in programmi precedenti al fine di evitare di commetterli nuovamente. Quando un errore viene trovato, è necessario scegliere il metodo più efficace per affrontarlo: questo significa avere una metodologia volta ad assegnare un valore d’importanza al difetto, affinché i maggiori sforzi per le correzioni del programma si concentrino prima di tutto sugli errori ai quali è stato assegnato il massimo peso. Uso comune è quello di identificare con un valore pari a 1 gli errori che impattano maggiormente sul corretto funzionamento del software, mentre con 6 quelli che influiscono marginalmente su di esso:

1. Impedimento: è impossibile continuare il test a causa della gravità del difetto
2. Critico: il test può continuare ma il prodotto non potrà essere rilasciato finché l’errore non verrà corretto
3. Importante: il test può continuare ma il difetto potrebbe non soddisfare i requisiti richiesti
4. Medio: il test può continuare ed il difetto comporta conseguenze minime rispetto al suo corretto funzionamento
5. Minore: il test può continuare ed il prodotto svolge correttamente i compiti richiesti. I difetti possono essere corretti senza difficoltà
6. Cosmetico: difetti minori, come font e colori non corretti, che non incidono sulla bontà dell’output

Normalmente un Test Plan viene condotto in maniera schematica, eseguendo prima quelli che vengono definiti test unitari, ossia su singole parti del programma, e successivamente dei test di sistema per verificarne, ad alto livello, il corretto funzionamento. Questa esecuzione ordinata di istruzioni è poco realistica, in quanto l’utente finale potrebbe non utilizzare le funzionalità del programma nel medesimo ordine, portando nei casi più gravi ad ottenere risultati errati; è necessario quindi realizzare un Test Plan tenendo in considerazione il fatto che il software potrebbe essere utilizzato su diversi dispositivi hardware, sistemi operativi differenti oppure in combinazione con altri programmi. Un test fondamentale consiste nel vedere come si comporta il programma sotto carichi di lavoro normali e sotto stress, ad esempio quando è necessario gestire una grande mole di dati: l’obiettivo è vedere se l’applicazione risponderà comunque in maniera corretta soddisfacendo i requisiti richiesti o se, sotto opportune ipotesi, presenterà un comportamento diverso da quello nominale. I test sotto stress sono solitamente svolti alla fine dell’intero ciclo, quando tutti gli altri problemi legati al normale funzionamento riscontrati in precedenza sono stati risolti; sfortunatamente questo si traduce nell’avere poco tempo a disposizione per realizzare le opportune modifiche nel caso si presentassero ulteriori problemi.