Processo di Verifica e Validazione (V&V) nelle fasi del controllo qualità software

Per quanto riguarda il controllo della qualità prodotta (controllo qualità software), le revisioni tecniche ed i collaudi del software rimangono le due tecniche principali per verificare il livello qualitativo raggiunto e ricercare il maggior numero di errori presenti nella progettazione e nel codice.
Le revisioni tecniche si eseguono sui singoli oggetti (documenti, codice, casi di prova, ecc.) prodotti nelle diverse fasi del ciclo di sviluppo (analisi, progettazione, codifica e test). Aiutano a scoprire e a rimuovere gli errori concettuali nelle fasi alte del ciclo di sviluppo ed evitano la loro propagazione nel codice prodotto. Le revisioni tecniche verificano, per ogni oggetto ispezionato, il livello di uniformità agli standard stabiliti per le singole categorie di oggetti prodotti, la completezza, la correttezza e la coerenza con i prodotti della fase precedente.

I collaudi ai vari livelli (test unitario, test d’integrazione, test di sistema, test utente) rimuovono gli errori dal codice prima della sua messa in esercizio (rilascio in produzione). L’efficacia dei test dipende dal livello di copertura dei requisiti funzionali e delle caratteristiche qualitative (sicurezza, interoperabilità, usabilità, prestazioni, robustezza, ecc.). I test devono verificare non solo la correttezza delle funzionalità sviluppate ma anche la gestione delle condizioni di errore e delle condizioni di eccezione. La progettazione dei test deve includere la predisposizione di ambienti di test adeguati (componenti tecnologiche e basi di dati) il più possibile simili a quelle di esercizio.

Le attività di revisione tecnica e di collaudo del software, quindi, devono essere pianificate, eseguite e controllate per verificarne l’efficacia e che i livelli qualitativi attesi siano stati raggiunti, e risultano le fasi più costose del processo di sviluppo. A fronte dell’analisi dei risultati raggiunti si valuta quanto i processi sono seguiti dall’organizzazione e l’efficacia dei processi; quindi si interviene per rimuovere eventuali ostacoli organizzativi o errori nei processi.
Molto spesso i termini di Verifica e Validazione (V&V) sono usati in modo intercambiabile, in realtà ci sono delle differenze. Secondo lo Standard IEEE, la Verifica è definita come ” The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase”. La Validazione, invece, è definita come ” The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies user requirements”.

Quindi la Verifica dimostra semplicemente se l’output di una fase è conforme con l’ingresso della fase stessa piuttosto che dimostrare che l’uscita sia effettivamente corretta. La Verifica non rileva errori derivanti dalla specifica non corretta dell’ingresso e questi errori possono propagarsi, senza essere ritrovati, attraverso fasi successive del ciclo di sviluppo. Non è sufficiente effettuare solo la Verifica, è necessaria anche una fase di Validazione per verificare i problemi con le specifiche e per dimostrare che il sistema funziona correttamente.
Nella figura seguente si mostra il rapporto tra le attività di Verifica e Validazione rispetto ai manufatti prodotti in un progetto di sviluppo software.

Per capire come affrontare il problema di verificare il software, è bene porsi alcune domande:

1. Quando iniziare la fase di Verifica e Validazione? Quando completarle?
2. Quali tecniche particolari devono essere applicate durante lo sviluppo del prodotto, per ottenere software di qualità ad un costo accettabile?
3. Come possiamo capire se un prodotto è pronto per il rilascio?

Anche se alcuni processi di sviluppo software si concentrano su test e analisi, alla fine del ciclo di sviluppo, e il ruolo del “tester” in alcune organizzazioni si riferisce ancora ad una persona che esegue soltanto i casi di test su un prodotto completo, oggi è ampiamente diffusa l’idea che l’esecuzione dei test è una piccola parte del processo di verifica e validazione necessaria per valutare e mantenere la qualità di un prodotto software.
L’inizio della fase di Verifica e Validazione coincide con la decisione di realizzare un prodotto software, o anche prima. Si parte dallo studio di fattibilità del prodotto, considerando non solo le funzionalità e i costi di sviluppo, ma anche le qualità richieste e la loro incidenza sul costo globale. Il responsabile della qualità partecipa con gli altri progettisti allo studio di fattibilità, con particolare attenzione all’analisi dei rischi e alle misure necessarie per valutare e controllare la qualità in ogni fase di sviluppo. Il team valuta l’impatto delle nuove funzionalità e dei nuovi requisiti di qualità per l’intero sistema e considera il contributo delle attività di controllo di qualità sui costi di sviluppo e pianificazione. Uno studio di fattibilità che ignora la qualità potrebbe portare a maggiori costi e ritardi imprevisti e molto probabilmente al fallimento del progetto.
Lo studio di fattibilità comporta necessariamente un’architettura sperimentale, per esempio, una divisione della struttura del software corrispondente a una divisione di responsabilità tra la squadra che si occupa del design dell’interfaccia e i gruppi responsabili del core business (business logic) e le infrastrutture di supporto.
Nel complesso il lavoro di progettazione divide i compiti e separa le qualità che possono essere verificate in modo indipendente in diversi sottosistemi, facilitando così il lavoro del team di testing così come di altri sviluppatori.

Tenendo conto dei vincoli di qualità, la ripartizione in sottosistemi permette una migliore allocazione delle risorse e facilita sia la progettazione dettagliata che il collaudo. Tuttavia, molte proprietà non possono essere garantite da un unico sottosistema.
Lo studio di fattibilità è il primo passo di un complesso processo di sviluppo che dovrebbe portare alla consegna di un prodotto soddisfacente, attraverso le attività di progettazione, verifica e validazione. L’attività di Verifica guida il processo verso la costruzione di un prodotto che soddisfa i requisiti, controllando la qualità dei manufatti intermedi, nonché il prodotto finale. L’attività di Validazione verifica la corrispondenza dei manufatti intermedi e del prodotto finale rispetto alle aspettative degli utenti.
Per la business logic, il team di responsabili della qualità prevede di utilizzare un prototipo preliminare per la validazione delle specifiche dei requisiti. Si prevede di utilizzare tool automatici per semplici verifiche strutturali delle architetture e delle specifiche di progettazione. Il personale sarà formato per la progettazione e i controlli del codice, che saranno basati su checklist che individueranno le discrepanze con le regole di progettazione così da garantire la manutenibilità, la scalabilità e la corrispondenza tra progetto e codice.
Le specifiche dei requisiti sono scritte in un formato strutturato semiformale. Esse non sono sottoponibili a controlli automatizzati, ma come ogni altro artefatto software possono essere controllate dagli sviluppatori. Le checklist sono compilate in base alle regole della software house per strutturare documenti di specifica e in base all’esperienza acquisita in passato con i problemi di estrazione dei requisiti dai sistemi.

Il piano di analisi e test richiede l’ispezione delle specifiche dei requisiti, delle specifiche di progettazione, del codice sorgente e della documentazione dei test. La maggior parte delle ispezioni del codice sorgente e della documentazione dei test sono semplici prove off-line effettuate da un altro sviluppatore, anche se una parte dei componenti critici sono poi destinati ad un esame supplementare approfondito. Le specifiche di interfaccia dei componenti sono controllate da piccoli gruppi che comprendono sia il “fornitore” che il “consumatore”, ancora per lo più off-line, con scambio di opinioni attraverso discussioni. Un gruppo più grande effettua poi un’ispezione delle specifiche dei requisiti.

Gli sviluppatori producono i Functional test unit per ogni singola situazione, così come gli oracoli ed ogni altra struttura richiesta per l’esecuzione del test. Le strutture richieste in fase di V&V sono codice aggiuntivo necessario per eseguire l’isolamento di un’unità o di un sottosistema. Gli oracoli consentono di controllare i risultati dell’esecuzione del codice e le differenze tra gli output attuali e quelli previsti.

I casi di test si basano principalmente sulle specifiche di interfaccia, e la misura in cui gli unit test testano l’intera struttura dei programmi è sotto controllo. Se inferiore al 90% di tutte le istruzioni che vengono eseguite dai test funzionali, allora è un’indicazione del fatto che o le specifiche di interfaccia sono incomplete, oppure dietro l’interfaccia si nasconde ulteriore complessità di implementazione. In entrambi i casi, i casi di test aggiuntivi sono concepiti sulla base di una descrizione più completa del comportamento dell’unità.

I test di integrazione e di sistema sono generati dal “team di qualità”, considerando un insieme di pattern e di test possibili. Il comportamento di alcuni sottosistemi o di componenti è modellata con una macchina a stati finiti, quindi il team crea una Test Suite che rappresentano diversi percorsi sulla macchina a stati finiti con le relative transizioni di stato.
Gli oracoli per il test di integrazione sono parte dell’architettura complessiva del sistema. Gli oracoli per i singoli componenti e per le unità sono progettate e implementate dai programmatori con strumenti per l’analisi e il controllo del codice con le condizioni e le invarianti.
Infine gli sviluppatori utilizzano un tool per unire le strutture ausiliare e gli oracoli al codice; con lo stesso tool schedulano poi i test, tracciano i fault, e organizzano e aggiornano le Test Suite di regressione.

Il piano di qualità prevede attività di analisi e di test per diverse proprietà, a partire dalla correttezza funzionale, comprese le prestazioni, l’usabilità e la sicurezza. Anche se analisi e test sono parte integrante del piano di qualità, la loro progettazione ed esecuzione sono delegate in parte o tutto agli esperti che possono trovarsi in altre parti dell’organizzazione.

La qualità del prodotto finale ed i costi delle attività di assicurazione della qualità dipendono dalla scelta delle tecniche per realizzare ogni attività. La cosa più importante è costruire un piano coerente che possa essere monitorato. Oltre al programma di monitoraggio del piano, si registrano anche le anomalie riscontrate durante ogni attività, usandole come indicatore di potenziali punti critici. Per esempio, se il numero di anomalie riscontrate in un componente durante i test è alto, ciò vuol dire che dovrà essere dedicato ulteriore tempo per il test dinamico di tale componente.