Molto spesso mi capita di leggere o di ascoltare mille motivazioni sulla necessità di un collaudo di sistemi ICT in modo tale da preservare da errori o malfunzionamenti.

Definire una metodologia di collaudo appare interessante ma credo che una delle tecniche tra le tante presenti in letteratura possa andare bene.

La cosa che invece mi ha colpito, in questa ricerca bibliografica, un approccio un pò filosofico alla questione dei collaudi ICT e che nel seguito ripropongo traendo ampi spunti da “Principi di Ingegneria del Software – terza edizione – di Pressman”.

Deutsch affermava che “lo sviluppo di sistemi software comporta una serie di attività produttive nelle quali le occasioni di inserire errori umani abbondano. Gli errori possono verificarsi fin dal principio del processo, quando gli obiettivi possono essere specificati in modo errato o imperfetto, fino alle ultime fasi di progettazione e sviluppo. A causa dell'incapacità umana di operare e comunicare in modo perfetto, lo sviluppo di software è affiancato da una attività di garanzia di qualità.”.

Ma chi ha progettato e realizzato il software, senza peccare di presunzione, ha la presunzione di avere fatto bene il proprio lavoro. E allora perchè deve fare il collaudo? È quindi necessario che lo sviluppatore si liberi da nozioni preconcette sulla correttezza del software appena costruito e superi il conflitto di interesse che sorge nel momento in cui si scopre un errore. La questione è stata affrontata molto bene da Beizer che nel 1990 affermava: “secondo una credenza diffusa, se fossimo davvero buoni programmatori, non vi sarebbero errori da scoprire. Se solo lavorassimo concentrati, se solo si utilizzasse la programmazione strutturata, la progettazione top-down, le tabelle di decisione, se I programmi fossero scritti in SQUISH, allora non esisterebbero errori. Secondo questa credenza, gli errori esistono perchè non siamo abbastanza capaci; e se non siamo abbastanza capaci, dovremmo sentirci colpevoli. Pertanto, il collaudo e la preparazione dei casi di prova sono il segno di un fallimento, il che infonde una bella dose di colpevolezza. E il fastidio dei collaudi non è che la giusta punizione delle nostre colpe. Punizione per cosa? Per il nostro essere umani? Colpevoli di che cosa? Di non raggiungere una perfezione disumana? Di non distinguere tra quello che un altro programmatore pensa e quello che dice? Di non avere doti telepatiche? Di non sapere risolvere problemi di comunicazione che ci assimilano da quaranta secoli?”

Sui collaudi software uno dei testi fondamentali è sicuramente quello di Myers che indica gli obiettivi di un collaudo sono quelli di eseguire I programmi per scoprire errori e addirittura, se il collaudo non ha scoperto errori, bisogna interrogarsi sulla bontà del collaudo stesso.

Un collaudo riuscito scopre errori software. Come beneficio secondario, il collaudo può dimostrare che la funzionalità del software sembra rispettare le specifiche e che I requisiti operativi sembrano essere rispettati. Inoltre, I dati raccolti durante il collaudo forniscono un indice della affidabilità del software e della qualità complessiva.

C'è però una cosa che un collaudo non può fare: non può dimostrare l'assenza di difetti; può solo dimostrare l'esistenza di errori.