Verifica e validazione: introduzione
Definizione
Verifica e validazione sono due processi strettamente correlati. A questa coppia di processi si dà spesso il nome di "qualifica" o "V&V". Il loro obiettivo è assicurare la qualità del prodotto durante il suo ciclo di vita.
Questi due processi rispondono a due domande separate:
- Verifica:
Did I build the system right?
- Validazione:
Did I build the right system?
La verifica attiene alla coerenza, completezza e correttezza del prodotto. È un processo che si applica ad ogni "segmento" temporale di un progetto (ad ogni prodotto intermedio) per accertare che le attività svolte in tale segmento non abbiano introdotto errori nel prodotto.
La validazione, invece, non si applica ad un particolare segmento temporale ma è una conferma finale, una self-fulfilling prophecy che accerta la conformità di un prodotto alle attese; essa fornisce una prova oggettiva di come le specifiche del prodotto siano conformi al suo scopo e alle esigenze degli utenti. La validazione, a differenza della verifica, coinvolge sempre il committente.
Forme di verifica
La verifica è un processo analitico. Si può fare in due forme:
- analisi statica (senza eseguire il software);
- analisi dinamica (eseguendo il software o una sua parte).
L'analisi statica viene fatta prima di quella dinamica: quest'ultima necessita di (una parte di) software eseguibile, mentre l'analisi statica si può applicare già a frammenti di prodotto.
Test
L'analisi dinamica viene effettuata tramite prove (test). Un test, per essere utile, dev'essere facilmente ripetibile; per questo, bisogna sempre:
- tener conto dell'ambiente (non solo dell'input);
- specificare le pre-condizioni e i comportamenti attesi;
- descrivere le procedure per eseguire il test e per analizzarne i risultati.
Per fare ciò, servono tre strumenti:
- Un logger, che scriva l'esito della prova in un file.
- Un driver, cioè un "pilota" che guidi l'esecuzione del test. Ogni test di unità dev'essere chiamato da qualcuno: costui è il driver.
- Uno stub, cioè un "calco" che sostituisca del codice non ancora scritto: una componente passiva fittizia che simula una parte del sistema[1].
Lo stub è quindi il duale del driver: mentre il primo simula le dipendenze della procedura testata (quelle che ne accrescono il fan-out, per capirci), il secondo simula un chiamante di tale procedura (che contribuisce al fan-in).
Tipi di test
Distinguiamo quattro tipi di test, a seconda del livello a cui vengono eseguiti nell'architettura:
- collaudo o test di accettazione (stabilito durante l'analisi del capitolato d'appalto);
- test di sistema (stabiliti durante l'analisi dei requisiti);
- test di integrazione (stabiliti durante la progettazione logica);
- test di unità (stabiliti durante la progettazione di dettaglio).
Nell'architettura di un software, l'unità è la più piccola quantità di software che conviene verificare da sola. Un test di unità è un'attività di analisi dinamica che verifica la correttezza del codice. Può essere responsabilità del programmatore che ha implementato l'unità[2], di un verificatore indipendente oppure (meglio!) di un automa. Questi test vengono svolti con un alto grado di parallelismo (rispecchiando lo stesso parallelismo che caratterizza il lavoro dei programmatori).
I test di integrazione servono per verificare il sistema in modo incrementale. Questi test stanno a livello di componente e integrano il funzionamento di più unità.
Il test di sistema serve ad accertare la copertura dei requisiti. È un'attività interna all'organizzazione, mentre il collaudo è la corrispondente attività esterna (supervisionata dal committente). Al collaudo segue il rilascio del prodotto e la fine della commessa (con eventuale manutenzione).
Infine, esistono anche i test di regressione: a seguito di un test andato male e di una relativa correzione, i test di regressione sono l'insieme di test necessari ad accertare he la correzione non causi errori nelle parti del sistema che dipendono da essa. La regressione può essere complicata e dev'essere studiata ad hoc.
Forme di analisi statica
L'analisi statica si applica ad ogni prodotto intermedio (non solo software) per tutti i processi attivi nel progetto. Distinguiamo due tecniche principali per fare analisi statica:
- Metodi di lettura (desk check), svolti da un umano che controlla coerenza, completezza e correttezza; impiegati solo per prodotti semplici.
- Metodi formali, svolti da macchine.
Tra i metodi di lettura, due importanti sono inspection (cerco cose specifiche) e walkthrough (attraversamento a pettine: non so cosa cerco ma cerco ovunque), che si completano a vicenda.
Inspection consiste nell'eseguire una lettura mirata, alla ricerca di errori noti. Si basa sull'individuazione di errori presupposti e fa profiling del prodotto in esame. Si suddivide nelle seguenti attività: pianificazione; definizione di una lista di controllo[3]; lettura; correzione dei difetti. È una tecnica molto più rapida del walkthrough. In termini statistici, inspection può generare falsi negativi.
Walkthrough, invece, consiste nell'eseguire una lettura critica del prodotto in esame. È una lettura "a largo spettro", senza l'assunzione di presupposti. Si articola nelle seguenti attività: pianificazione; lettura; discussione; correzione dei difetti. Rispetto all'inspection, richiede più attenzione. In termini statistici, walkthrough può generare falsi positivi.
Quality assurance
Analisi statica e analisi dinamica sono parte dell'attività di quality assurance (cioè garanzia di qualità). Questa attività è un controllo che non viene fatto dopo ma prima di fare, per assicurare la qualità tempestivamente; viene svolta sui processi con i quali si sviluppa il prodotto (non sul prodotto stesso) ma si basa su un modello di qualità di prodotto (ad esempio ISO/IEC 9126).