Software testing: Obiettivi e limiti del test software
La fase del Software testing
In modo del tutto simile alla maggior parte dei processi fisici, un componente software riceve un insieme di dati di ingresso per elaborarli e produrre un insieme di dati di uscita. Qualsiasi attività finalizzata alla valutazione delle caratteristiche di un programma o un sistema e alla verifica che i comportamenti degli stessi diano i risultati previsti rientra nella definizione di software testing.
Ciò in cui un software differisce dagli altri sistemi fisici è l’insieme solitamente molto ampio di modi in cui è possibile che esso fallisca; benchè un software non risenta di difetti di fabbrica (molto spesso i difetti derivano da errori introdotti in fase di progettazione e non dalla scrittura del codice sorgente) nè di altri fattori ambientali e di usura, cercare di prevedere tutti i possibili errori è di fatto impossibile.
Obiettivi e limiti del software testing
Le attività di testing sono considerate parti integranti dello sviluppo di un software: metà delle risorse impiegate nello sviluppo vengono solitamente allocate a a procedure di collaudo, le quali sono dunque generalmente riconducibili a due importanti scopi finali:
- verifica e validazione: in altre parole, validare che il software soddisfi i requisiti e le specifiche e verificare che lo faccia nel modo atteso;
- migliorare la qualità: la presenza di difetti rappresenta solo uno degli indici di qualità del software (correttezza), il collaudo si propone come obiettivo quello di valutare il software secondo un insieme di parametri.
A tal riguardo è necessario anche parlare dei limiti dell’attività di testing software.
Essendo che la presenza di bug in un software deriva dalla complessità stessa e non è direttamente correlata alle capacità tecniche dei programmatori che ne hanno curato progettazione e implementazione. Per lo stesso motivo, scoprire i difetti è altrettanto difficile. Collaudare un sistema coprendo tutto l’insieme di dati accettabile dallo stesso è impraticabile; si può averne la dimostrazione prendendo in considerazione un semplice programma sommatore a due operandi di numeri interi a 32 bit come oggetto del collaudo: significherebbe testare il funzionamento del sistema con 264 combinazioni, con grande dispendio di tempo e risorse.
Un’ulteriore complicazione deriva dalla frequenza di aggiornamento del software: un test case scritto ed eseguito con successo durante le prime fasi di sviluppo potrebbe fallire in una successiva occasione a causa di modifiche introdotte nel codice sorgente. E’ evidente che l’improvviso fallimento di un test case richiede un’indagine approfondita sia del codice del programma che dello stesso test: potrebbe essere necessario aggiornare il meccanismo di collaudo per renderlo conforme al nuovo comportamento del software. In alternativa, nel caso in cui l’errore non fosse nè nel codice nè nei dati di input del test, bisognerà riparare il difetto all’interno del programma. Infine, sarà necessario eseguire nuovamente il test. E’ evidente come tutte queste operazioni abbiano dei costi. Senza una strategia e degli strumenti di ausilio all’analisi dei requisiti e alla scrittura dei componenti di collaudo, tali costi possono diventare insostenibili.
