AI genera suite di test in un istante, ma i verdi non garantiscono la correttezza

Il 46% dei team ha spedito codice scritto dall’AI poi fallito in produzione, mentre oltre il 92% usa l’AI nei test. Dati SmartBear e Applause, 30 settembre 2026¹.

Gli agenti generano casi, eseguono la suite, mostrano verde. Quel verde non decide cosa sia “corretto”. Se il requisito è ambiguo, l’AI può verificare con rigore l’interpretazione sbagliata. Più test non colmano la mancanza di una definizione di qualità¹.

Serve un oracolo dei test, la fonte che stabilisce il risultato atteso. Prendiamo “Applica il 10% di sconto agli ordini oltre 100 dollari”. Restano decisioni da chiarire: la soglia vale solo per maggiore o anche per uguale? Il calcolo avviene prima di tasse e spedizione? I coupon si combinano con altre promozioni? Come si arrotonda? Cosa fare con articoli esclusi? Senza risposte, un agente può costruire una suite coerente con una scelta, ma lontana dall’intento del product owner¹.

La proposta è fissare le regole in un contratto di accettazione, poi generare i test. Esempio sintetico: valutare la soglia sul subtotale eleggibile prima di tasse e spedizione, applicare il 10% solo se quel subtotale è maggiore di 100,00, arrotondare a due decimali secondo la regola documentata, calcolare la spedizione separatamente. Con il confine esplicito, i test confrontano il codice con qualcosa di indipendente¹.

Sul confine si gioca la correttezza. Il caso a 100,00 distingue tra “maggiore” e “maggiore o uguale”. Un esempio in pytest copre 99,99 senza sconto, 100,00 senza sconto, 100,01 con 10,00 di sconto. Le attese derivano dal contratto, non da ciò che l’AI pensa del proprio codice. Se si cambia la condizione da > a >=, il test su 100,00 deve fallire. Così si prova che il test difende il requisito e non l’implementazione¹.

from decimal import Decimal import pytest

@pytest.mark.parametrize( ("subtotal", "expected_discount"), [ (Decimal("99.99"), Decimal("0.00")), (Decimal("100.00"), Decimal("0.00")), (Decimal("100.01"), Decimal("10.00"))]) def test_save10_discount(subtotal, expected_discount): assert calculate_discount(subtotal) == expected_discount

Per lavorare con l’AI nel QA serve un flusso disciplinato in cinque passaggi:

• Scrivere prima il comportamento atteso. Separare criteri di accettazione da dettagli d’implementazione. Prompt utile: non scrivere test, elenca le ambiguità del requisito e chiedi decisioni a prodotto o QA. Non inventare l’atteso.
• Generare test dal contratto. Coprire esempi felici, confini sotto, a, sopra soglia, input mancanti o invalidi, permessi e ruoli, transizioni e retry, fallimenti rilevanti per l’utente. Chiedere il riferimento al criterio per ogni test.
• Mettere alla prova i test. Fare mutation testing: invertire una condizione, rimuovere una validazione, alterare un confronto. Un test utile fallisce quando il comportamento protetto si rompe.
• Tenere il giudizio umano dove l’esito è soggettivo, come accessibilità, usabilità, qualità di una risposta generata. Un LLM può aiutare solo con una rubrica esplicita, validata su esempi etichettati da umani.
• Misurare l’evidenza, non il volume. Il numero di test o il coverage non provano la qualità¹.

Le survey citate sono indizi, non prove causali. Segnalano che generare ed eseguire test non equivale a stabilire la correttezza di prodotto¹. Una review del 5 novembre 2026 su 113 studi peer-reviewed conferma criticità aperte: correttezza semantica, output non deterministici, manutenibilità, verifica, coerenza di valutazione¹.

Prossimo sprint, azioni verificabili: pretendere per ogni test un link al criterio di accettazione, bloccare la merge se manca il riferimento, inserire almeno una mutazione su ogni soglia critica, usare rubriche e set etichettati quando serve giudizio umano. Portare l’oracolo al centro della pipeline, con evidenza misurabile per ogni decisione¹.