Perchè fare testing software per le applicazioni informatiche?

All’interno del ciclo di vita del software, le varie fasi di testing software rappresentano un momento di verifica del processo produttivo. Esistono però diverse interpretazioni su come tale verifica debba essere svolta, soprattutto per ciò che riguarda gli obiettivi da raggiungere.

Storicamente sono state date diverse definizioni di testing software, come ad esempio:

1. Il testing è il processo che si occupa di dimostrare che nel sistema non sono presenti errori.
2. L’obiettivo del testing software è verificare che il sistema svolga correttamente le funzioni ad esso assegnate.

Purtroppo queste definizioni sono da considerarsi errate poiché descrivono esattamente l’opposto di quanto il testing si propone di realizzare. Quando si sottopone un sistema alla fase di testing, l’obiettivo è aumentare il valore del software, dato che la fase di testing una attività molto costosa in termini di tempo e risorse impiegate. All’aumentare del valore corrisponde un aumento della qualità e dell’affidabilità del software, obiettivi raggiungibili tramite la ricerca e rimozione degli errori presenti nel software.

Quindi, un software è sottoposto al test non per verificare che esso funziona, ma per scoprire il maggior numero di errori: errori che sono sicuramente presenti all’interno di qualsiasi software che sia non banale.

Una definizione più appropriata di testing è quindi la seguente:

Il testing è il processo di esecuzione di un programma (o un sistema) con l’obiettivo di ricercare il maggior numero di errori possibile [definizione di Myers].

Il testing software risulta allora un processo di tipo distruttivo, in quanto tende a ricercare tutti gli errori commessi all’interno del software. Se accettiamo il fatto che ogni individuo assume spontaneamente un atteggiamento costruttivo nei confronti di ogni attività, questa caratteristica del testing può essere identificata come la causa principale della grande difficoltà che si incontra nel realizzarlo.

Dopo aver chiarito quali sono gli obiettivi del testing, è necessario definire quale significato assumano i termini successo e insuccesso quando si fa riferimento al testing. Di norma il buon senso ci porta a supporre che un processo ha successo quando raggiunge gli obiettivi preposti; quindi, nell’ambito del testing, parleremo di successo quando si giunge ad identificare almeno un errore all’interno del software; diversamente il testing risulterà uno spreco di risorse e quindi definibile come un insuccesso.

Partendo dall’assunto che in ogni software esistono degli errori, ci troviamo di fronte alla necessità di ricercare delle metodologie, delle tecniche per affrontare al meglio tale ricerca, ottimizzando così le risorse impiegate nel testing e riducendo nel contempo i costi relativi al test.

Best practices del testing software

Affinché il testing riesca a raggiungere al meglio i suoi obiettivi, è necessario che tale processo non venga condotto in maniera casuale, guidato cioè solo dalla fantasia e dall’esperienza del test- engineer.

Da questa esigenza nasce la necessità di definire dei principi generali su cui una metodologia di testing debba fare riferimento. Ogni metodologia di testing dovrebbe perciò osservare i seguenti principi:

Individuare quando deve partire il processo di testing e quale è il criterio di terminazione da utilizzare.

È ritenuto fondamentale all’interno di un processo identificare a priori lo stato di inizio e di fine, per evitare che il processo cominci quando ancora non sono presenti tutte le informazioni necessarie o che si prolunghi eccessivamente, con conseguente crescita dei costi del test.

Definire per ogni test i risultati attesi.

La descrizione dei risultati ottenuti dall’esecuzione di un test case è determinante poiché, senza una precisa connotazione degli output attesi, si corre il rischio di interpretare come corretti dei risultati che viceversa non lo sono.

Il principio resta valido anche quando si ha una generazione di test-case astratti, test-case in cui non è definito puntualmente il valore per ciascun input al sistema; nel momento in cui i valori puntuali vengono istanziati si ricorre ad un oracolo appositamente costruito che permetta di ricavare i risultati derivanti dagli input e quindi la definizione completa del test-case.

Non affidare il testing a chi ha costruito il sistema.

Questo principio è di carattere prevalentemente psicologico in quanto è difficile per chi ha prodotto il sistema, pensare ad esso in termini distruttivi e quindi efficaci per la fase di testing. Spesso accade che il programmatore del sistema incorra negli stessi errori già compiuti in precedenza, progettando in questo modo un insieme di test-case poco efficienti.

Analizzare a fondo i risultati di ciascun test.

Questa affermazione può sembrare banale, ma è stato verificato che sovente i risultati di un test non vengono analizzati completamente, creando così i presupposti per un mancato riconoscimento degli errori.

Esaminare il sistema sia per individuare comportamenti attesi e implementati, sia per osservare comportamenti non attesi ma verificati.

Non è ritenuto sufficiente che un sistema svolga le funzioni ad esso assegnate, ma è necessario che esso non svolga anche funzioni che non gli competono. Esempio tipico è la gestione degli accessi ad un sistema, laddove non è sufficiente che il sistema permetta un accesso autorizzato, ma è necessario che blocchi tutti gli accessi non autorizzati. Allo stesso modo si dovranno verificare tutti i comportamenti del sistema, sia quelli previsti nei documenti di specifica, sia quelli a fronte di richieste non previste.

Non pianificare il testing assumendo tacitamente che nessun errore sarà individuato.

Questo è un comportamento che deriva direttamente da una errata interpretazione del concetto di testing, laddove si crede che il testing sia la verifica delle funzionalità del sistema, mentre il vero processo di testing è la ricerca del maggior numero di errori.

La probabilità di rilevare errori in una sezione di software è proporzionale alla quantità di errori già scoperti in quella sezione.

Una analisi statistica del fenomeno ha messo in luce il rapporto fra gli errori scoperti e la probabilità di scoprirne altri all’interno della stessa sezione di software; la figura che segue rappresenta l’andamento classico:
Questo fenomeno può essere spiegato tenendo conto che gli errori sono sovente legati a cali di concentrazione da parte di chi produce il software; ciò spiega però solo in parte il fenomeno, poiché bisogna anche tenere conto che ogni volta che un errore viene corretto, con la modifica si ha la potenziale creazione di nuovi errori all’interno del modulo, in una sorta di circolo vizioso.

Il principio non deve però inibire il test, ma semplicemente afferma che, nel momento in cui vengono rilevati degli errori, è consigliabile verificare con maggiore attenzione la sezione di software in cui l’errore è stato rilevato, in una sorta di feedback per il test-engineer.

Il miglior test case è quello che ha la più alta probabilità di scoprire errori non ancora rilevati.

Questo principio è ovviamente poco pragmatico, in quanto non è possibile a priori valutare la probabilità di scoprire errori da parte di un test case , ma possiamo affermare che si deve sempre tendere ad una produzione limitata il più possibile di test case di qualità, al fine di massimizzare il rapporto tra gli errori scoperti ed i test utilizzati.

Ovviamente non sempre è possibile riuscire a rispettare tutti i principi guida elencati, per cui si cerca, all’interno delle metodologie, di seguire il più possibile le linee guida che essi tracciano.