Test verdi ingannevoli: perché il successo in CI non garantisce funzionalità in produzione

Per due settimane i clienti in Ontario non hanno potuto chiudere un acquisto. La dashboard di CI mostrava verde da sei settimane. Un refactor del form indirizzo aveva spostato la provincia da province a region. Il backend è caduto su un default senza regola fiscale per l’Ontario. Gli unit test passavano. Il checkout no⁵. Automazione e metriche di test coprono poco se mancano osservabilità, un oracolo chiaro e un flusso di riparazione sui dati.

Verdi che non proteggono l’utente

La suite sembrava solida: circa l’80% di line coverage, qualche centinaio di unit test, pipeline sotto i quattro minuti. Il modulo delle tasse aveva 40 test, tutti verdi. Nessun test garantiva che un utente potesse pagare in Ontario. Un cambio di campo ha rotto l’allineamento tra frontend e backend. La validazione ha rifiutato il totale⁵.

Un 200 OK non prova il comportamento atteso. Nelle specifiche OpenAPI pubbliche, molte risposte hanno type: object senza proprietà e senza required. Un generatore invia la richiesta, riceve 200, non ha asserzioni, segna pass. Il contratto resta non verificato².

L’adozione di AI nei test è alta: oltre il 92% dei team la usa. Il 46% ha spedito in produzione codice scritto dall’AI poi fallito. Dati SmartBear e Applause, 30 settembre 2026⁴. Più casi generati non risolvono ambiguità nei requisiti. Senza un oracolo dei test, l’AI verifica con rigore l’interpretazione sbagliata⁴.

Tre carenze che producono falsi verdi

Osservabilità insufficiente lungo i flussi asincroni. Un test di verifica email attraversa sistemi diversi: invio form dal browser, accodamento del messaggio, processamento da un servizio, esposizione via API dell’inbox, apertura del link di verifica. Ogni tratto ha una latenza. L’inbox è un evento ritardato, non una query. Trattarla come una query spinge a retry casuali e debug lenti¹. La domanda utile: qual è stato il primo stato diventato impossibile¹?

Specifiche deboli che non consentono asserzioni. Se una risposta è un oggetto senza proprietà né campi obbligatori, il test non può controllare nulla. Mancano anche le forme di errore per 400, 401 e 404. I test negativi non hanno base per fallire in modo informativo².

Assenza di un oracolo condiviso. L’esempio dello sconto “10% oltre 100 dollari” mostra quante decisioni restano aperte: soglia inclusiva o esclusiva, ordine di calcolo rispetto a tasse e spedizione, combinazione con coupon, regole di arrotondamento, esclusioni. Senza risposte, una suite può essere coerente e insieme lontana dall’intento del product owner⁴.

Pratiche che rendono il verde affidabile

Osservabilità orientata agli stati. Definisci le transizioni attese: form_submitted, account_created, message_requested, message_received, verification_link_opened, account_verified. Registra solo ciò che il test può osservare: il browser vede submit e pagina di verifica, il client inbox la ricezione, i log applicativi la creazione dell’account. Per ogni evento, un record minimo con state e timestamp ISO, più dettagli opzionali. Subito dopo ogni azione, una funzione mark scrive l’evento. In caso di fallimento, stampa la timeline con nome del test e run ID. Così appare il punto preciso di rottura¹.

Contratti OpenAPI che abilitano asserzioni. Definisci schemi di risposta con proprietà concrete e campi required. Se il corpo può essere qualsiasi cosa, niente fallisce. Aggiungi gli schemi per 400, 401 e 404, così i test negativi validano forma e contenuto. Una suite generata riflette la qualità della specifica: testo vago, test vaghi².

Oracolo prima della generazione. Scrivi un contratto di accettazione che chiude le ambiguità, poi genera i test. Per lo sconto, un esempio operativo in forma di checklist:

• Regola: “Applica il 10% di sconto agli ordini oltre 100 dollari”⁴
• Soglia: definire se > 100 o ≥ 100⁴
• Base di calcolo: valutare la soglia sul subtotale eleggibile prima di tasse e spedizione⁴
• Combinazioni: indicare se i coupon si combinano con altre promozioni⁴
• Arrotondamenti: stabilire la regola di arrotondamento⁴
• Esclusioni: elencare eventuali articoli esclusi⁴

Questo documento fornisce l’oracolo per l’AI: il verde significa aderenza all’intento, non solo coerenza interna della suite⁴.

Riparazione mirata guidata dai dati. Dopo un import con Salesforce Data Loader compaiono due CSV: success e error. Il file error contiene una colonna con il motivo del fallimento. L’analisi parte da lì, non dal success. Raggruppare gli errori per il prefisso del messaggio, prima del primo due punti, permette di correggere e ricaricare solo le righe respinte. Nell’esempio i gruppi attesi sono: DUPLICATE_VALUE, REQUIRED_FIELD_MISSING, INSUFFICIENT_ACCESS_ON_CROSS_³. Se il file sorgente aveva colonne chiamate success o error, conviene rinominarle per evitare intestazioni ambigue in output³.

Cosa cambia per team di AI, sviluppo e QA

Ogni test dovrebbe rispondere a una domanda pratica: se questo test passa, che cosa può fare un utente. Un unit test raramente sblocca un’azione diretta. Un test funzionale sì: “con un indirizzo dell’Ontario, l’utente invia il carrello e riceve una conferma ordine con il totale giusto”⁵. La stessa logica guida la progettazione dei test generati: prima l’oracolo, poi i casi⁴.

Indicatori come percentuale di copertura e durata della pipeline restano utili, ma non sostituiscono il controllo del comportamento. Una timeline di stati accorcia la diagnosi sui flussi asincroni¹. Specifiche con schemi concreti rendono i generatori capaci di fallire quando devono². Un contratto di accettazione lega i verdi all’intento di prodotto⁴. Un ciclo di riparazione sui soli record rifiutati riduce rischi e tempi di recupero³.

Per chi introduce AI nei test, la priorità è preparare terreno e obiettivi. Investire nella qualità delle specifiche e nell’oracolo produce suite più utili dei mille casi generati alla cieca. La lezione dell’Ontario e i dati su adozione e fallimenti mostrano il costo dei falsi verdi, in dashboard e in produzione^5,4. Scegliere dove mettere l’attenzione, prima che sul volume dei test, è già un atto di qualità.