Il collaudo del software (anche software testing in lingua inglese), in informatica, indica un procedimento, che fa parte del ciclo di vita del software, utilizzato per individuare le carenze di correttezza, completezza e affidabilità delle componenti software in corso di sviluppo. Consiste nell'esecuzione del software da parte del collaudatore, da solo o in combinazione ad altro software di servizio, e nel valutare se il comportamento del software rispetta i requisiti. A volte il collaudo, che fa parte delle procedure di assicurazione di qualità, viene confuso con il debugging, con il profiling, o con il benchmarking.
Descrizione generale In generale, occorre distinguere i "malfunzionamenti" del software (in inglese, "failure"), dai "difetti" (o "errori" o "bachi") del software (in inglese, "fault" o "defect" o "bug"). Un malfunzionamento è un comportamento del software difforme dai requisiti espliciti o impliciti. In pratica, si verifica quando, in assenza di malfunzionamenti della piattaforma (hardware + software di base), il sistema non fa quello che l'utente si aspetta.
Un difetto è una sequenza di istruzioni, sorgenti o eseguibili, che, quando eseguita con particolari dati in input, genera un malfunzionamento. In pratica, si ha un malfunzionamento solo quando viene eseguito il codice che contiene il difetto, e solo se i dati di input sono tali da evidenziare l'errore. Per esempio, se invece di scrivere "a >= 0", il programmatore ha erroneamente scritto "a > 0" in una istruzione, si può avere un malfunzionamento solo quando viene eseguita quell'istruzione mentre la variabile "a" vale zero. Lo scopo del collaudo è di rilevare i difetti tramite i malfunzionamenti, al fine di minimizzare la probabilità che il software distribuito abbia dei malfunzionamenti nella normale operatività.
Nessun collaudo può ridurre a zero tale probabilità, in quanto le possibili combinazioni di valori di input validi sono enormi, e non possono essere riprodotte in un tempo ragionevole; tuttavia un buon collaudo può rendere la probabilità di malfunzionamenti abbastanza bassa da essere accettabile dall'utente. L'accettabilità di una bassa probabilità di malfunzionamento dipende dal tipo di applicazione.
Il software per cui è richiesta la massima qualità, è quello cosiddetto "life-critical" ("safety critical"), cioè in cui un malfunzionamento può mettere a rischio la vita umana, come quello per apparecchiature medicali o aeronautiche. Per tale software è accettabile solo una probabilità di malfunzionamento molto bassa, e pertanto il collaudo è molto approfondito e rigoroso. Per rilevare il maggior numero possibile di difetti, nel collaudo si sollecita il software in modo che sia eseguita la maggior quantità possibile di codice con svariati dati di input.
Può anche darsi che un errore nel codice sorgente generi un malfunzionamento solo se si utilizza un particolare compilatore o interprete, o solo se eseguito su una particolare piattaforma. Pertanto può essere necessario collaudare il software con vari ambienti di sviluppo e con varie piattaforme di utilizzo.
Le tecniche di collaudo possono essere classificate in molti modi. I principali sono i seguenti: Per modello di sviluppo: a cascata, guidato dal collaudo. Per livello di conoscenza delle funzionalità interne: a scatola bianca, a scatola nera. Per appartenenza o meno dei collaudatori all'organizzazione che modifica i sorgenti, nonché per fase di sviluppo: Alfa, Beta. Per grado di automazione: manuale, semi-automatizzato, completamente automatizzato. Per granularità: collaudo di modulo, collaudo di sistema. Per grado di formalità: da informale a formale.
Verifica e validazione La fase di verifica e di validazione serve ad accertare che il software ottemperi agli obiettivi.
Precisamente:
la verifica serve a stabilire che il software rispetti i requisiti e le specifiche, quindi ad esempio che non ci siano requisiti mancanti o che le diverse prove (esecuzione, moduli/parti del sistema, unità, integrazione, etc) abbiano esito positivo, La verifica può essere eseguita in diverse sotto fasi o riguardare specifici aspetti (categorie di funzioni, sicurezza, architettura, ingegnerizzazione del sistema, prestazioni); spesso si esegue la verifica X per poter procedere alla successiva sottofase X+1; esistono test di verifica della progettazione (analisi funzionale) e altre più propriamente di sviluppo; invece, la validazione serve ad accertare che i requisiti di utilizzo (bisogni e aspettative dell'utente) siano anche soddisfatti nella maniera giusta. Il collaudo per antonomasia è quello finale, eseguito in condizioni che simulino il reale impiego applicativo. La validazione (validare = convalidare, rendere valido) segue sempre la verifica.
Questa fase, infatti, è molto delicata in quanto, se il software passa la verifica, ma non la validazione, dopo tutto il processo si può ottenere un software perfettamente funzionante, senza errori, ma del tutto inutile in quanto non rispecchia quanto era stato chiesto all'inizio (in tal caso non adempiendo all'insieme completo delle funzionalità previste e quindi non servendo allo scopo di progetto, può esserci il rischio che venga rigettato dal cliente). Oltre alla funzioni (tra cui quelle di sicurezza, sempre più rilevanti e spesso date per scontate), la validazione deve accertare anche il raggiungimento dei livelli prestazionionali (in pratica, la velocità di esecuzione e l'efficienza del sistema).
Secondo il modello applicato questa fase si applica su stadi intermedi o su tutto il sistema software (ivi compresa l'ingegnerizzazione della piattaforma SW/HW quando prevista cioè l'ambiente in cui il software verrà eseguito e fruito). La verifica può essere statica, se effettuata su carta, cioè sul progetto, o dinamica, se effettuata attraverso il collaudo dello stesso software con dati di test.
Modello di sviluppo Sviluppo a cascata
Il procedimento tradizionale di sviluppo del software, detto "a cascata" (in inglese "waterfall"), prescrive di iniziare il collaudo appena è completata la prima versione del prodotto. I risultati del collaudo vengono utilizzati per rivedere i requisiti, o il progetto, o il codice, e produrre così la versione successiva.
Questo procedimento è stato sottoposto a una severa critica in quanto ha i seguenti svantaggi: Se è giunta la data prevista per il completamento del prodotto, si tende a consegnarlo anche se il collaudo non è stato completato o ha dato esito negativo, il che significa che probabilmente si sta consegnando un prodotto scadente. Probabilmente, tra i requisiti non è stata inclusa la "collaudabilità" (in inglese, "testability"), cioè il progetto e il codice non contengono accorgimenti che agevolino il collaudo. In tal caso, il collaudo risulterà molto più costoso e meno efficace. Più tempo passa tra l'introduzione di un errore in un sistema e la segnalazione di un malfunzionamento dovuto a tale errore, più risulta difficile e costoso rimediarvi. Dato che il software in tale modello è previsto che venga sottoposto a test solo dopo aver completato la fase di sviluppo, l'eventuale feedback raccolto in fase di prova non può essere usato per alimentare tempestivamente l'apprendimento del team di sviluppo in modo tale che la qualità del codice possa essere migliorata come nei metodi iterativi ed incrementali (come può avvenire ad es. nei metodi "agili"). Pertanto nel modello di sviluppo in cascata le "lezioni apprese" possono essere utilizzate solo in eventuali successivi progetti di sviluppo, il che spesso ne limita l'effettivo valore aggiunto, in quanto la distanza nel tempo dalla fase di raccolta non agevola la applicazione.
Sviluppo guidato dal collaudo
Un procedimento più recente, detto "guidato dal collaudo" (in inglese, "test driven development"), proposto a partire dall'inizio degli anni 1990, consiste nel considerare il collaudo una parte integrante del prodotto: Quando si analizzano i requisiti del software da produrre, si analizzano i requisiti del collaudo. Quando si progetta l'architettura del software da produrre, si progetta l'architettura del collaudo. Quando si scrive il codice del software da produrre, si scrive il codice delle routine di collaudo automatizzato o si preparano i dati e si scrivono le istruzioni per il collaudatore manuale. Quando si costruiscono gli eseguibili compilando i sorgenti, se la compilazione va a buon fine, vengono automaticamente eseguite le routine di collaudo automatizzato. Le prove inerentemente interattive vengono tuttavia relegate a una procedura parzialmente manuale. Quando si archivia o si recupera una versione dei sorgenti, si archiviano o si recuperano tutti i suddetti documenti relativi al collaudo. Anzi, tali documenti devono essere intesi come parti integranti dei sorgenti.
Fasi di distribuzione Il collaudo di tipo Alpha
Appena un software è stato costruito, prima di distribuirlo fuori dall'azienda, viene normalmente sottoposto a un collaudo interno all'azienda stessa.
Il collaudo di tipo Alpha può essere eseguito dagli stessi programmatori o da altro personale dell'azienda.
Spesso, il software prodotto per il collaudo Alpha viene arricchito di istruzioni di controllo a run-time che facilitano il rilevamento degli errori. Esempi di tali istruzioni sono: il controllo che non si acceda a indici non validi di array; il controllo che tutta la memoria allocata venga disallocata prima della terminazione; asserzioni dichiarative scritte dal programmatore.
In alcuni casi, in particolare per lo sviluppo di software di sistema o di software embedded, si utilizza un ambiente hardware di esecuzione che supporta specificamente il debugging e il testing.
Il collaudo di tipo Beta
Spesso, quando un prodotto ha superato il collaudo di tipo Alpha, viene distribuito all'esterno dell'azienda ad alcuni clienti selezionati o anche a tutti i clienti, avvertendo gli utenti che il prodotto distribuito potrebbe non essere di qualità elevata e probabilmente potrebbe richiedere ulteriori correzioni.
Gli utenti della versione Beta possono simulare l'utilizzo del software in casi realistici, e inviare al produttore resoconti dei malfunzionamenti riscontrati. Tale tipo di collaudo eseguito gratuitamente dagli utenti viene detto "collaudo Beta" (in inglese "Beta testing").
Possono esserci più versioni Beta, man mano che vengono corretti gli errori. Quando la frequenza delle segnalazioni d'errore diventa bassa, è il momento di distribuire la versione ufficiale.
Anche dopo che sono state distribuite delle versioni Beta, e quindi si è in fase di collaudo Beta, all'interno dell'azienda può continuare il collaudo Alpha.
Automazione del collaudo
Se il collaudo consiste nell'utilizzo del prodotto quasi come se fosse la normale operatività, si parla di "collaudo manuale".
Se il collaudo consiste nello sviluppo di apposito software che interagisce con il software da collaudare e fornisce un rapporto di qualità in assenza di personale, si parla di "collaudo automatizzato".
Granularità Il collaudo di modulo (Unit Testing)
Quando si costruisce un prodotto complesso come un'automobile, non ci si limita a costruire e ad assemblare i pezzi e alla fine girare la chiave per vedere se tutto funziona. Questo per tre motivi: Alcuni difetti producono malfunzionamenti solo dopo un utilizzo prolungato, ma sono facilmente identificabili esaminando i singoli pezzi prima dell'assemblaggio. Se dopo aver girato la chiave la macchina non si accende, risulta molto difficile capire qual è il difetto. Se dopo aver girato la chiave la macchina non si accende, risulta molto costoso smontare la macchina, sostituire il pezzo difettoso e rimontarla. In alcuni casi potrebbero derivare dei rischi di arrecare danni a persone o cose dal funzionamento difettoso di un componente critico.