Dopo anni nel campo del testing di sistemi — prevalentemente software e sistemi enterprise — sono giunto alla conclusione che, avendo un background in fisica, vedo il testing in modo piuttosto diverso rispetto alla maggior parte dei colleghi che lo hanno approcciato attraverso gli studi di informatica. La fisica è una disciplina in cui (se funziona come dovrebbe) ipotesi, interpretazione ed esperimento si motivano e si richiedono a vicenda. La misurazione è il nucleo centrale; il modo in cui un esperimento viene costruito rispecchia simultaneamente il livello di comprensione del problema, così come il metodo di acquisizione e valutazione dei dati — la conversione in quella che popolarmente viene chiamata „grandezza fisica“. Il valore di una grandezza fisica ha senso solo se collegato a una procedura di misurazione e a un’unità di misura. Questo stesso principio si applica senza modifiche alla qualità del software.

Tuttavia, ciò non significa che questo concetto sia adeguatamente rappresentato nei progetti software. Come professionista esperto, posso dire di aver incontrato molto raramente un Test Architect o un Test Analyst propriamente presente già nella fase di „inception“ (concepimento) dell’intera „avventura“. Ciò porta regolarmente tali progetti a diventare davvero delle avventure, ma nel senso di uno sport estremo basato sull’adrenalina.

La misurazione come atto fondamentale

Il detto di Kelvin è inequivocabile: „Quando puoi misurare ciò di cui stai parlando ed esprimerlo in numeri, sai qualcosa su di esso; ma quando non puoi misurarlo… la tua conoscenza è di tipo povero e insoddisfacente“. La qualità che non può essere misurata è un’opinione. La qualità misurata secondo criteri definiti è un risultato ingegneristico. Il testing nelle discipline ingegneristiche rappresenta — sebbene identico in linea di principio — qualcosa di leggermente diverso rispetto al lavoro scientifico (almeno se parliamo di un lavoro di prima classe e non di mera ripetizione, ma questo è un argomento per un’altra volta). Un Test Architect „vede“ tutto ciò al meglio durante la fase di test design, dove sono richiesti una visione olistica e una valutazione dei rischi più ampia. Dedicheremo sicuramente altre osservazioni a questo tema in post futuri; è un argomento fondamentale che non è trattato particolarmente bene nemmeno nella comune letteratura software.

Da questa prospettiva, l’analisi del test è l’atto di derivare Test Target (obiettivi di test) misurabili dalla Test Basis (base di test) — specifiche dei requisiti, contratti architettonici, definizioni di interfaccia, ecc. Un Test Target è la controparte ingegneristica di ciò che nella fisica moderna viene chiamata „osservabile“ (specialmente con riferimento all’uso nella meccanica quantistica): una proprietà del sistema specificata con precisione, per la quale è possibile definire coerentemente una metrica e formulare successivamente un criterio di successo/fallimento (pass/fail). Senza questa fase di derivazione, il testing diventa un’esplorazione casuale e i risultati non possono essere riprodotti.

La copertura come problema di campionamento

La teoria della copertura (coverage) nel testing rispecchia la teoria del campionamento nella scienza sperimentale. Lo spazio dei possibili input per qualsiasi sistema software non banale è astronomicamente vasto. Lo spazio degli stati di un sistema — quando si usa un approccio bottom-up „dal codice“ — cresce esponenzialmente. Il coinvolgimento di terze parti sotto forma dei popolari sistemi di machine learning odierni, come la cosiddetta „I.A.“ basata su LLM agentici, non migliora la situazione per quanto riguarda le possibili modalità di guasto; al contrario, aggiunge gradi di libertà che non abbiamo sotto controllo. Un testing esaustivo nel senso di una copertura totale — sia degli input che degli stati del sistema corrispondenti a funzionalità empiricamente rilevanti, inclusi tutti i possibili stati limite, sub-limite e oltre il limite — è un suicidio combinatorio.

Sebbene l’automazione renda i test di regressione ripetitivi più economici e faciliti relativamente il testing quando abbiamo uno script di test ben scritto per una funzionalità (parametrizzazione dei dati), essa richiede manutenzione e controllo sulle transizioni tra ambienti e set di dati. Ancora una volta, gli strumenti generativi abbassano radicalmente il costo di produzione degli script e talvolta dei dati di mock, ma non garantiscono necessariamente la correttezza della copertura a livello funzionale (la semantica è una canaglia) e producono lavoro extra sul fronte della manutenzione delle suite di test e dei dati. Il compito del Test Analyst (in collaborazione con gli altri attori del progetto) è quindi quello di selezionare un campione finito e rappresentativo che fornisca una copertura statisticamente affidabile dello spazio degli input e dello spazio degli stati del sistema, i quali sono strettamente correlati tra loro.

L’invariante del testing

Il testing — in quanto misurazione — è invariante rispetto alle metodologie, proprio come le leggi della fisica non dipendono dalla metodologia scelta per la misurazione (anche se il modo in cui vengono formulate potrebbe esserlo, ma questo è per un altro post). Una funzione si comporta secondo la specifica, oppure no. Il confine di uno sprint non cambia questo fatto. Un pattern architettonico non cambia questo fatto. Ciò che cambia tra le metodologie è la cadenza con cui viene eseguita la misurazione e l’ambito della Test Basis disponibile in ogni punto di misurazione. Questo è probabilmente ovvio per chiunque abbia esperienza in grandi progetti software.

La conseguenza ingegneristico-manageriale che vorremmo sottolineare è questa: il costo della correzione dei difetti aumenta vertiginosamente con la distanza tra il punto di introduzione e il punto di rilevamento. Questo non è un principio manageriale — è una conseguenza della struttura degli artefatti software. L’incentivo economico per il coinvolgimento precoce di un Test Architect e, successivamente, di un Test Analyst nel team è quindi del tutto chiaro. Si può anche tentare di misurarlo in senso finanziario, cosa che nella mia esperienza accade raramente, poiché la tolleranza verso i bug è aumentata negli ultimi due decenni, mentre la tolleranza verso la velocità di consegna e i costi è peggiorata. Ciononostante, l’incentivo per un’analisi del test precoce deriva direttamente dalla struttura qui delineata.