Lasciar controllare un programma a chi lo ha creato è come lasciare il lupo di guardia alle pecore.

Questa frase introduce il concetto di verifica e validazione tramite ispezioni continue del prodotto da parte di team di controllo.

Se la specifica formale di ogni componente è possibile, ma costosissima e quindi non praticabile, è sicuramente possibile stabilire degli standard di produzione che garantiscano un livello minimo di qualità.

Questi standard possono riguardare il modo di assegnare i nomi alle varie entità come variabili, file, procedure e funzioni di libreria; il modo di interfacciare tra loro i vari blocchi; il modo di creare la documentazione e di tenere la storia degli interventi per ogni parte del pacchetto; o ancora possono essere dei vincoli decisi artificiosamente sullo strumento di sviluppo (p.e. non usare variabili in area COMMON) perchè ritenuti pericolosi per la qualità finale.

L’attività di verifica assicura che siano stati seguiti tutti gli standard di produzione, cioè che si sia costruito il prodotto nel modo giusto.

Alla verifica, il team di controllo farà seguire la validazione, cioè l’assicurazione della rispondenza alle specifiche, che si sia costruito il prodotto giusto.

Le tecniche di verifica e validazione possono essere le più varie, ma vi sono due metodi fondamentali: "walkthroughs" e ispezioni.

Nel primo caso di tratta di "passeggiate" con il prodotto da parte di esperti al fine di rivelare il maggior numero possibile di errori; di sessioni d’uso simulato, al fine di rilevare il maggior numero possibile di condizioni anomale, errori, sviste da parte dello sviluppatore.

Nel secondo caso si tratta di vere e proprie ispezioni di tutto il codice per verificare (punto per punto in base a liste predefinite) se sono stati seguiti tutti gli standard aziendali di produzione.

Indichiamo delle linee guida per le sessioni di "walkthrough", al fine di renderle più efficaci possibile:

Il team di "walkthrough" deve essere costituito da personale più esperto di chi ha sviluppato il software, ma deve essere posta particolare attenzione sugli aspetti psicologici: non si tratta di un esame che contrappone le parti o di un lavoro sadico al fine di ridicolizzare lo sforzo del programmatore, piuttosto di un aiuto da parte di altri ad aggredire parti di programma con ottiche diverse.

Le sessioni devono essere pianificate, sia come tempo che come obiettivo, e non devono essere concentrate nelle fasi finali dello sviluppo, ma equamente distribuite in tutto il ciclo di vita.

Durante ogni sessione bisogna rilevare il maggior numero possibile di errori, non tentare di correggerli e riverificarli.

L’attenzione deve essere focalizzata solo sugli obiettivi primari della sessione: se si è deciso di controllare la funzionalità dell’ I/O, non bisogna controllare anche lo stile di codifica che sarà verificato in un secondo momento.

Ogni sessione non deve durare più di un paio d’ore, proprio per non spostarsi dagli obiettivi primari e per non degenerare in considerazioni che possono esulare dal momento dello sviluppo raggiunto.

Le "passeggiate" di test non devono essere assolutamente utilizzate come strumento di valutazione dei programmatori. Non è affatto vero che una sessione che rivela parecchi errori indica che il lavoro è stato svolto male o in modo approssimato: forse era solo un problema difficile o mal analizzato in precedenza, per cui anche ad un programmatore esperto e preparato può capitare di incappare in sedute disastrose.