Agentic Testing
L'uso di AI agent per scrivere, mantenere e diagnosticare test software end-to-end. Evoluzione del test automation che solleva problemi nuovi e non ovvi: quando un agent scrive male il codice, i test lo intercettano; quando scrive male i test, niente lo intercetta. 1
Cosa gli agent fanno bene
- Scrittura test: con una sola frase di istruzione, Momentic ha generato in pochi minuti una suite end-to-end che girava e passava; decidere quanta coverage basta resta compito umano 1
- Niente selettori: rinominando il bottone di login, 6 test su 7 sono passati senza nemmeno attivare il recovery, perché il test descrive il bottone come farebbe un tester umano → 20 anni di CSS/XPath/test-id non servono più; il settimo test, su un bottone con stesso label ma scollegato, è fallito correttamente 1
- Explorer: senza specifiche, mappa l'app da solo (20 journey), confronta i journey con i test esistenti per trovare i gap di coverage, e percorrendoli in un browser reale ha segnalato 6 comportamenti anomali 1
- Esempi: un filtro per namespace che cambia titolo e URL ma mostra proprio le risorse che doveva escludere; un risultato di ricerca che apre una pagina "non esiste"; un form che crea un utente, si svuota, segnala successo e non crea nessuno 1
- Tutti e sei erano reali, ma quasi tutti dovuti al backend mock pieno di buchi, cosa che l'agent non poteva sapere: non capisce cosa il software dovrebbe fare, ma trova cosa non dovrebbe fare. Nessuna suite di test può dirti da sola cosa le manca 1
- Manutenzione: la maggior parte delle suite muore non per test sbagliati ma per stanchezza da falsi allarmi (qualcuno salta un test e nessuno lo rimette). Il recovery automatico dei test falliti era già attivo, impostato dal setup wizard 1
- Test migliori dei handwritten: asseriscono sul comportamento ("il filtro viene offerto") non su valori specifici ("parte al 50%") → più resilienti 1
Cosa gli agent fanno male
- Test sbagliati passano: un test male scritto non fallisce, passa → sei sicuro di qualcosa che non è vero 1
- Decisioni invisibili: l'agent sceglie come risolvere un fallimento (fix codice? riscrivere test? ignorare?) e la PR è già verde prima che tu guardi; nel caso dell'autore ha scelto bene, ma il momento del giudizio si è spostato dove l'umano non c'è 1
Diagnosi dei test rossi
I test flaky sono i peggiori: un rosso inaffidabile insegna a non fidarsi più dei rossi. Se fallisce un test che ieri passava lo si guarda, se ne falliscono 20 o sempre gli stessi tre si smette di guardare, ed è sbagliato. La regola dell'autore: niente va in merge finché tutto non è verde, così ogni rosso viene dall'ultima modifica e non c'è niente da smistare. Sconsiglia i tool il cui business è amministrare i finding che si è già deciso di non correggere ("run from those like the plague"). 1
Il problema della fonte di verità
Un test AI generato può derivare l'idea di "corretto" dal codice stesso → il check può solo concordare. Un check derivato da ciò che l'app fa e uno derivato da ciò che dovrebbe fare sono identici sulla pagina. Rivedendo la registrazione, l'autore ha scoperto che prima di scrivere i test l'agent aveva letto i requisiti lasciati nel repo, scritti da lui a partire dalla documentazione: non sa dire quanta dell'intenzione nei test sia sua e quanta dell'agent. 1
Il consiglio pratico: non puntare l'agent sul codice chiedendo test, perché il codice può dire solo cosa fa già. Serve puntarlo su requisiti, spec, ticket, design doc, product brief — qualcosa che una persona ha scritto perché voleva qualcosa. 1
Se non hai requisiti: fai leggere all'agent il codice e scrivere la specifica che ne emerge, poi leggitela tu e correggi ogni punto in cui descrive qualcosa che non volevi. Quella correzione è l'unico momento in cui l'intenzione entra nel sistema; approvarla senza leggerla significa "aver riciclato il codice due volte". Decidere a cosa serve il software è un dovere senza titolare, e quando nessuno lo fa non se ne accorge nessuno: "everything just stays green". 1
Vedi anche: Checking vs Testing, Agentic Harness, AI Agent in DevOps