Il ciclo di feedback (feedback loop) determinante nell’impostazione di un progetto di sviluppo software non è quello tra lo sviluppatore e la suite di test. È quello tra la persona che scrive una funzionalità (analista, sviluppatore, tester) e la persona che la utilizzerà. Tutto il resto — unit test, test di integrazione, revisione del codice, pipeline CI — esiste per approssimare e tradurre all’interno di questo ciclo, quando il contatto diretto non è possibile o non è abbastanza veloce o — come accade sempre nel caso dei sistemi enterprise — quando la distanza semantica tra il Bisogno del futuro utente e il codice/dati/output è così grande e il contesto così vasto/specifico che nessuno potrebbe farcela da solo. Uno dei momenti più insidiosi dell’odierna „rivoluzione dell’IA“, che preferisco inquadrare come una rapida evoluzione di un ecosistema basato su LLM, è che essa promette di fare un salto persino in questo divario, dove gli argomenti sono quasi esclusivamente banali o specifici — in tal caso la semantica gioca solo un debole ruolo di vincolo. Vorrei solo attirare la vostra attenzione sui problemi nascosti dietro queste supposizioni. A mio modesto parere, il gioco resta lo stesso, cambiano alcune regole, ma nel cuore del business della „traduzione dei bisogni in software“ rimane il fatto che „non esiste una comprensione basata solo sul feeling (vibe)“. Sarei in disaccordo con Curt su molti temi particolari, ma credo che abbia espresso bene il messaggio più importante:

L’invariante delle due domande

Quando un ingegnere del test chiede „come dovrei testare questa funzionalità“, la domanda è strutturalmente identica a „qual è la funzionalità principale (o il requisito non/funzionale, termine terribile ma comunemente usato) e perché è importante per il cliente, ovvero per la missione?“. Queste non sono due domande — sono la stessa domanda espressa da due posizioni diverse nel processo. Un test che non può essere derivato da una risposta chiara alla seconda domanda non è un test utile. Attenzione al modello a V! Una descrizione di una funzionalità che non può essere trasformata in un test non è una specifica utilizzabile.

Questa non è un’osservazione sul testing. È un’osservazione sulla comunicazione. La funzione della revisione del design del test — in qualsiasi metodologia — è quella di esporre i disallineamenti nel modello mentale condiviso del sistema prima che tali disallineamenti vengano codificati in codice o dati di test. Nel linguaggio del Testing distinguiamo chiaramente tra obiettivi di validazione e verifica, anche nella pratica; specialmente parlando con chi ama l’approccio :KISS: (Keep it Simple, Stupid), spesso non cogliamo questa sfumatura. Quando un ingegnere del test non riesce a formulare un test per un requisito, quel fallimento di formulazione è un segnale: il requisito contiene un presupposto nascosto, un’ambiguità o una contraddizione. Il processo di progettazione del test è un protocollo strutturato per estrarre queste proprietà nascoste dalle descrizioni in linguaggio naturale.

Gli errori sono facili da correggere. I problemi concettuali no.

Un errore (error) è una deviazione localizzata: un calcolo errato, un controllo null mancante, un errore off-by-one. L’analisi statica, i test automatizzati e i linter rilevano gli errori in modo affidabile. Il loro costo di rilevamento è in calo da decenni e continua a scendere. La generazione di codice assistita da LLM sarà un ulteriore fattore di accelerazione — la qualità sintattica del codice generato è, in generale, alta e i modelli di errore comuni sono ben rappresentati nei dati di addestramento.

Un problema concettuale è una deviazione nel modello del sistema: una funzionalità che implementa correttamente un’interpretazione errata di un requisito; una struttura dati che rappresenta accuratamente un concetto di dominio che si rivela essere il concetto sbagliato; un modello di integrazione che connette coerentemente due servizi secondo un contratto che non è mai stato effettivamente concordato. L’analisi statica non può rilevarli. I test automatizzati non possono rilevarli a meno che i test non siano stati scritti sulla base di una specifica corretta — e se la specifica era sbagliata, anche i test sono sbagliati e passeranno comunque.

Questa asimmetria — gli errori sono individuabili, i problemi concettuali no — è la sfida strutturale persistente della qualità del software. Non diminuisce con il miglioramento degli strumenti. Si intensifica. Cicli di consegna più rapidi riducono il tempo disponibile per la comunicazione che farebbe emergere i problemi concettuali prima che vengano codificati. Gli strumenti di codifica assistiti dall’IA aumentano la capacità produttiva di generazione del codice senza aumentare la precisione nella comprensione dei requisiti. Il rapporto tra rischio di problemi concettuali e rischio di errori aumenta.

L’IA come amplificatore — non come validatore di specifiche

Gli strumenti di codifica e documentazione basati su LLM sono, al loro attuale livello di capacità, amplificatori di alta qualità di ciò che è già presente nel contesto del prompt. Sono eccellenti nel generare codice sintatticamente corretto e stilisticamente appropriato che corrisponde all’intento espresso nel prompt. Sono scarsi validatori del fatto che l’intento espresso nel prompt corrisponda all’intento presente nella testa del cliente.

Questa non è una critica — è una descrizione del raggio d’azione dello strumento, che rappresenta ciò che essi sono, per principio. Un po‘ di comprensione della matematica dietro i Transformer e il processo di addestramento correggerebbe le false aspettative così tanto proiettate su tali strumenti. Ma questo è un argomento per un altro post. Un amplificatore di segnale amplifica allo stesso modo il segnale e il rumore. Se l’input di uno strumento di codifica LLM contiene una specifica concettualmente errata, l’output sarà una versione più grande, più raffinata e meglio formattata della specifica concettualmente errata. Il tasso di rilevamento per gli errori di implementazione sarà alto. Il tasso di rilevamento per gli errori concettuali sarà basso o nullo. Il ruolo dell’ingegnere del test in questo ambiente non è quello di competere con lo strumento sul rilevamento degli errori. È quello di mantenere la disciplina di chiedere: „questa specifica riflette correttamente ciò di cui il cliente ha bisogno?“ — la domanda a cui lo strumento non può rispondere.

Cicli di feedback brevi come infrastruttura di qualità

L’implicazione pratica per la comunicazione del team: il ciclo di feedback tra „cosa stiamo costruendo e perché“ e „come lo verificheremo“ deve essere mantenuto più breve del ciclo tra „scrivere il codice“ e „distribuirlo“. In un team che lavora per sprint utilizzando strumenti di codifica IA, ciò significa che la riunione di analisi dei test (o lo scambio equivalente) avviene alla definizione della story, non dopo il completamento del codice. Lo sviluppatore, l’ingegnere del test e il product owner sono nella stessa stanza (fisica o virtuale) quando viene scritto il criterio di accettazione, perché quello è il momento in cui il modello concettuale può ancora essere corretto al costo minimo.

L’argomento non è filosofico. È economico. Il costo della correzione di un problema concettuale scoperto durante i test di accettazione è di un ordine di grandezza superiore al costo della correzione durante la definizione della story. In un team che genera grandi volumi di codice tramite strumenti LLM, il volume di codice prodotto per unità di investimento in comunicazione aumenta — il che significa che il costo per difetto dei problemi concettuali aumenta proporzionalmente. L’investimento nella comunicazione non scala con il volume del codice. L’investimento nel testing deve farlo. È un avvertimento già ben noto a chi si „sporca le mani“ con tutti i deliverable di progetto, ma non necessariamente del tutto comprensibile per il senior management. Sono orgoglioso di restare con una gamba nelle acque sporche e fangose della consegna reale e restare in contatto con le visioni con l’altra. Ma senza radicare le decisioni nel mondo reale, le cose diventano caotiche con qualsiasi tecnologia si decida di adottare.