Significato, importanza e approcci del software testing

Software testing

Il software testing viene utilizzato per controllare la qualità del prodotto, trovare eventuali bachi o funzionalità non coperte quando invece è previsto che lo siano: in questo modo si accresce la robustezza del prodotto.
Le tecniche di test utilizzate non sono effettuate al solo scopo di trovare dei bachi all’interno del software, ma anche con l’intento di verificare e certificare che il software risponda ai requisiti richiesti dagli sviluppatori e dai committenti, anche in diverse condizioni sia climatiche che elettriche.
Il testing del software può essere eseguito sia in parallelo al processo di sviluppo del codice, sia a processo ultimato, a seconda di quando il test viene effettuato si utilizzano metodologie differenti.

In molti modelli tradizionali la quasi totalità dei test viene eseguita dopo che il processo di sviluppo del codice è già stato completato, allungando in questo modo i tempi di accertamento della qualità. Nel momento in cui gli sviluppatori ritengono di aver terminato la scrittura del codice, rilasciano una versione, denominata beta version, che deve passare a chi si occupa di analisi della qualità.
Effettuando dei test sul software non si avrà mai la certezza di aver trovato tutti i bachi, ma si può cercare di andare a testare il maggior numero di funzionalità possibile. Infatti, la quantità di software di test dipende dalla qualità che si vuole dare al prodotto e da chi dovrà utilizzarlo: ad esempio il software di agenzie governative deve avere meno probabilità di errore di un normale video game.

Diversi studi hanno dimostrato come gli errori e i bachi presenti nel software siano più costosi, sia in termini economici che di risorse, rispetto al costo di realizzazione del software di test.
Solitamente la fase del processo di sviluppo del software nella quale viene trovato un fallimento, determina il costo che questo implicherà per lo sviluppatore: prima viene trovato e meno costoso è risolverlo.
In generale, un software di test non può stabilire che un determinato prodotto funzioni in tutte le condizioni, ma può trovare in quali condizioni questo prodotto non funzionerà.

Tipologie di test software

Esistono numerose classificazioni dei test del software: principalmente questi si possono suddividere in test funzionali o non funzionali. I test funzionali fanno riferimento alle specifiche proprietà del prodotto, solitamente descritte nella documentazione, e vanno quindi a testare se effettivamente la funzionalità specifica agisce come descritto.
I test non funzionali, invece, controllano altri aspetti del prodotto che possono variare dalla sicurezza alle performance a diverse condizioni.

Alcune volte i programmatori sono a conoscenza di alcuni difetti del loro software, questi però non devono essere considerati dei fallimenti, ma solamente dei limiti del prodotto. Il software di test può servire anche a prendere atto dei limiti del prodotto, in modo che si possa decidere se investire risorse nell’eliminazione del limite o risparmiare le forze e modificare le caratteristiche nella documentazione. Alcuni difetti del prodotto, per il cambiamento di diverse condizioni, possono divenire dei fallimenti.
Una delle cause maggiori di fallimento è la compatibilità con il sistema, nel senso che un software può non funzionare nella versione più aggiornata di un sistema in cui prima funzionava. D’altro canto può accadere anche l’opposto e utilizzare il software su versioni precedenti del sistema può far incorrere in fallimenti.
Uno dei problemi più importanti del software testing è coprire tutte le condizioni e le diverse combinazioni di input che il prodotto da testare può ricevere.

Ci sono diversi approcci alla metodologia di test, comunemente si parla di black box, white box e grey box.

1. Si parla di black box quando il programmatore non è a conoscenza del contenuto del software da testare. Il tester, basandosi sulle specifiche del prodotto, inserisce alcuni input e deve aspettarsi degli output certi, se ciò non avviene ha trovato un fallimento.
2. Per white box si intende quando il tester ha a disposizione il codice da verificare, le strutture interne e gli algoritmi. Questa metodologia di test viene anche utilizzata quando si vuole valutare la completezza di un test realizzato con il metodo Black box. Così facendo si può stabilire una percentuale di copertura del test. Utilizzando il metodo del Black box vengono trovati molti bachi che con il white box non vengono rilevati. D’altro canto però sono necessari molti più test per verificare una singola funzionalità.
3. Il grey-box è quando viene a crearsi una situazione ibrida in cui il tester è a conoscenza delle strutture e degli algoritmi interni del prodotto, e fornisce alcuni input necessari a verificare che determinate funzionalità avvengano.

Una tipologia di test che si può considerare un black box è il regression testing. Questo tipo di test si focalizza sul trovare dei bachi nel prodotto principale quando viene introdotto un cambiamento. Principalmente il software di regression serve per trovare errori non presenti nelle vecchie versioni del prodotto e che emergono quando viene effettuata una modifica, magari anche in parti di programma che non dovrebbero essere intaccate dal problema. Anche la correzione di un baco può indurre errori in altre parti del codice che prima non erano presenti. Un metodo abbastanza comune di verifica del software è eseguire i test sul prodotto prima della modifica (tutti i test devono passare), apportare la modifica e poi rieseguire i test di regression. A questo punto, se si generano dei fallimenti, è chiaro che sono state le ultime modifiche apportate a inserire nuove instabilità: è quindi necessario analizzare il codice del TestWare per risolvere problema.

E’ buona norma, quando viene trovato un baco, creare un test di regression dedicato che faccia emergere il fallimento. In questo modo, ogni volta che verrà rilasciata una nuova versione di codice, sarà eseguito un test apposito che verificherà l’assenza del fallimento specifico. I test di regression possono essere utilizzati, oltre che per trovare bachi nel sistema, per studiare le performance e la qualità degli output. Le regression devono coprire tutte le funzionalità del dispositivo e devono generare il maggior numero possibile di testcase in modo da verificare il funzionamento del prodotto in un numero considerevole di condizioni.