
Con i coding agent siamo in grado di scrivere più codice di prima, e lo scriviamo più in fretta. Il lavoro di chi deve garantire che quel codice funzioni non si è ridotto: secondo il report DORA 2025 di Google, il 90% dei professionisti tech usa l’AI al lavoro e l’adozione è legata a un aumento delle consegne, ma anche a una minore stabilità dei rilasci. In sostanza, più modifiche arrivano in produzione, maggiori sono i controlli necessari e capaci di reggere quel ritmo.
La Quality Assurance con AI nasce da qui. Con l’uso di modelli linguistici e agenti per analizzare requisiti, generare test, scegliere quali eseguire e leggere i fallimenti, consente ai professionisti di concentrarsi sulla qualità delle decisioni da prendere. In questa guida ti spieghiamo dove l’AI entra nel processo di test, cosa può fare un agente QA, quali strumenti esistono e come cambia il lavoro del QA engineer, con le cautele che servono per non riempire il progetto di test inutili.
Cos’è la Quality Assurance con AI
La Quality Assurance è l’insieme di attività che verificano che un software faccia ciò che deve, in modo affidabile e sicuro. Con AI quality assurance si fa riferimento all’uso di modelli di intelligenza artificiale in queste attività: leggere una user story e trovarne le ambiguità, proporre casi di test, scrivere script automatici, riparare un test rotto da una modifica all’interfaccia, raggruppare i bug simili.
Si tratta di un fenomeno giù piuttosto ampio. Il World Quality Report 2025 di Capgemini e OpenText, basato su oltre 2.000 dirigenti in 22 Paesi, indica che l’89% delle organizzazioni sta sperimentando o usando la Generative AI nei processi di quality engineering, con un guadagno medio di produttività del 19%. Solo il 15% l’ha portata su scala aziendale, e tra gli ostacoli principali compaiono privacy dei dati (67%), complessità di integrazione (64%) e allucinazioni (60%).
QA tradizionale, AI-assisted QA e agentic QA: le differenze
Nel QA tradizionale le persone progettano i casi di test, scrivono gli script con i framework di automazione e li mantengono a mano. L’automazione esegue, il ragionamento resta tutto umano.
L’AI-assisted QA aggiunge un assistente che lavora su richiesta: generi i casi di test a partire da una user story, chiedi all’LLM di spiegare un errore nei log o di proporre dati di test, poi decidi tu cosa tenere.
Con l’agentic QA l’AI riceve un obiettivo e organizza da sola i passaggi: esplora l’applicazione, scrive il piano, genera i test, li esegue e prova a correggere quelli che falliscono, usando browser, terminale e repository. È il livello più potente e quello che richiede più regole, perché un agente può ripetere lo stesso errore molte volte, e in fretta.
Perché il QA resta una responsabilità umana
Un modello può generare cento test in pochi minuti, ma non sa quali rischi contano per la tua azienda: una penale contrattuale, un dato sanitario esposto, un errore di calcolo in fattura. Decidere cosa testare, quanto rischio accettare e quando un prodotto è pronto per il rilascio resta una scelta che qualcuno deve poter firmare.
L’AI entra nel QA come strumento in mano a persone competenti, capaci di leggere e contestare i suoi risultati.
Dove l’AI entra nel processo QA
Il modo più semplice per capire l’impatto dell’AI in software testing è seguire una funzionalità dal requisito al bug risolto. A ogni passaggio c’è un compito che l’AI può accelerare e un controllo che resta alle persone.

Requisiti, test case e dati di test
Molti difetti nascono prima del codice, in una user story scritta di fretta. Un LLM può leggere i criteri di accettazione e segnalare ciò che manca: cosa succede se l’utente annulla il pagamento a metà, quale messaggio compare se il codice sconto è scaduto, quali ruoli possono vedere un certo dato. Scoprire un’ambiguità durante il refinement allunga la conversazione con l’AI e i tempi di elaborazione, scoprirla in produzione può costare un intero rilascio.
Dalla stessa user story, l’AI test case generation propone casi di test positivi, negativi e limite, per esempio un campo importo con zero, valori negativi, decimali con la virgola o la cifra massima consentita. L’AI può creare anche dati di test sintetici realistici, come anagrafiche e ordini, evitando di copiare dati reali dei clienti negli ambienti di prova. Ogni caso generato va letto da chi conosce il dominio, perché il modello tende a produrre test plausibili ma ridondanti, o ad assumere regole di business che nel tuo sistema non esistono.
Prioritizzazione dei test in base al rischio
Con suite che contano migliaia di test, eseguirli tutti a ogni modifica rallenta il lavoro. Il risk-based testing assistito dall’AI incrocia la modifica di codice con lo storico dei fallimenti e con le aree dell’applicazione toccate, poi ordina i test per probabilità di trovare un problema. Lo stesso approccio aiuta a individuare i moduli più fragili, cioè quelli modificati spesso, con molte dipendenze e poca copertura, dove concentrare revisione del codice e test esplorativi.
Un’organizzazione tipica esegue sulle pull request solo il sottoinsieme di test più pertinente alla modifica e lascia la suite completa alla build notturna. Così lo sviluppatore riceve un riscontro in pochi minuti e nessuna parte dell’applicazione resta a lungo senza controlli.
Triage dei bug e analisi delle cause
Dopo un rilascio, il team riceve spesso decine di segnalazioni che descrivono lo stesso problema con parole diverse, e in CI cinquanta test rossi possono dipendere da un unico servizio non disponibile. L’AI può raggruppare segnalazioni e fallimenti per causa probabile, unire i duplicati, stimare la gravità e assegnarli al team competente.
Con accesso a log, stack trace e codice, un modello può anche ricostruire la catena di eventi che ha portato all’errore e proporre una correzione. Strumenti come Claude Code o Codex di OpenAI lo fanno già lavorando sul repository. Prima del merge servono una revisione umana e un test che riproduca il bug, così la correzione risolve la causa e non il solo sintomo.
Agentic QA: come lavorano gli agenti AI nel testing
Un AI QA agent è un sistema basato su un LLM che riceve un obiettivo di test e lavora in autonomia per raggiungerlo, usando strumenti esterni come un browser automatizzato, un terminale o le API dell’applicazione. Se vuoi approfondire il funzionamento degli agenti in generale, trovi una guida su cosa sono gli agenti AI nel nostro blog.
L’agente segue un ciclo: osserva lo stato dell’applicazione, decide l’azione successiva, la esegue, controlla il risultato e ripete. Progettare bene questo ciclo, con verifiche e condizioni di uscita, è il tema del loop engineering. Il testing è un terreno adatto agli agenti perché l’esito di un test è verificabile: passa o fallisce.
Obiettivi, strumenti e limiti di autonomia
Un agente lavora bene quando l’obiettivo è preciso. «Testa il checkout» è troppo vago; «verifica che un utente ospite possa completare un acquisto con carta e riceva l’email di conferma» definisce un risultato controllabile.
Negli strumenti agentici per il testing il lavoro è spesso diviso in tre ruoli: un agente esplora l’applicazione e scrive un piano di test in linguaggio naturale, un secondo lo trasforma in test eseguibili verificando selettori e asserzioni, un terzo riproduce i test che falliscono e prova a correggerli. Assistenti di codice come Claude Code o Codex possono svolgere questi compiti direttamente nel repository. Gli strumenti a disposizione dell’agente stabiliscono cosa può verificare: senza accesso al database, per esempio, non potrà controllare che un ordine sia stato salvato.
I limiti vanno decisi prima di partire. Un agente può segnalare bug inesistenti o, peggio, «riparare» un test modificando l’asserzione fino a farlo passare; un agente ben configurato, quando ritiene che la funzionalità sia davvero rotta, segnala il problema e lascia il test fallito. Le regole minime riguardano permessi su ambienti e dati, limiti di tempo e di costo, e approvazioni: nessun test modificato dall’agente entra nella suite principale senza revisione.

Il ciclo di un agente AI nel testing: obiettivo, osservazione, decisione, azione e verifica
Casi d’uso concreti di QA con AI
Per applicazioni web e mobile, l’AI genera e mantiene test end-to-end scritti anche in linguaggio naturale, come «accedi con un utente premium e scarica la fattura di marzo». Per le API legge la specifica degli endpoint e propone test su codici di risposta, campi obbligatori e casi di errore, come un token scaduto. In un team che rilascia ogni settimana, delegare la prima stesura di questi test libera tempo per l’esplorazione manuale delle funzionalità nuove.
L’AI regression testing affronta un problema che ogni team conosce: le suite crescono a ogni sprint e diventano lente. Selezionare i test in base alla modifica e isolare quelli instabili (flaky) riduce i tempi di attesa sulle pull request, con un’esecuzione completa periodica che copre anche le aree considerate a basso rischio.
Per l’accessibilità, l’AI affianca gli strumenti automatici nel controllo di contrasto, testi alternativi ed etichette dei form, e aiuta a scrivere correzioni chiare per gli sviluppatori. È un tema concreto per chi vende online, perché dal 28 giugno 2025 lo European Accessibility Act si applica a molti servizi digitali, tra cui l’e-commerce.
Un caso a parte è la quality assurance di sistemi basati su LLM, come chatbot e agenti, dove la stessa domanda può produrre risposte diverse. Qui si usano le valutazioni (eval): insiemi di domande con criteri di correttezza, controlli automatici e spesso un secondo modello che giudica le risposte.
AI QA vs QA tradizionale: vantaggi e metodologie efficaci
L’AI non sostituisce le tecniche di test consolidate, come le classi di equivalenza, i valori limite o i test esplorativi: le rende più veloci da applicare e più facili da mantenere.
| Attività | QA tradizionale | QA con AI |
|---|---|---|
| Scrittura dei casi di test | Manuale, a partire dai requisiti | Prima stesura generata, revisione umana |
| Manutenzione degli script | Correzione manuale dei locator rotti | Self-healing con verifica delle modifiche |
| Selezione dei test | Suite fissa o scelta per esperienza | Ordinamento per rischio e modifica di codice |
| Analisi dei fallimenti | Lettura dei log uno per uno | Raggruppamento per causa e commit sospetto |
| Dati di test | Copie anonimizzate o creati a mano | Dati sintetici generati su richiesta |
La metodologia che funziona meglio è incrementale: si parte da un’attività con un risultato misurabile, come il tempo di manutenzione degli script o la durata della pipeline, si confronta il prima e il dopo e si estende l’uso solo quando i numeri lo giustificano. Il 19% di produttività medio del World Quality Report, con circa un terzo delle aziende che riporta guadagni minimi, mostra quanto i risultati dipendano da come l’AI viene introdotta.
Strumenti AI per il QA e integrazione nelle pipeline CI/CD
Il mercato degli AI QA tools cambia ogni mese, e per orientarsi aiuta ragionare per categorie. Le piattaforme AI-native coprono creazione, esecuzione e manutenzione dei test con agenti specializzati e funzioni di auto-healing, che aggiornano i test quando l’interfaccia cambia. Gli strumenti di visual testing confrontano le schermate tra una versione e l’altra e distinguono le differenze rilevanti da quelle dovute, per esempio, a un diverso rendering del browser. Chi gestisce i test in Jira trova funzioni AI anche nei plugin di test management, che generano casi di test a partire da requisiti e issue e li sottopongono al tester prima della creazione. Gli assistenti di codice come Claude Code, Codex o Cursor, infine, scrivono e correggono test direttamente insieme al codice.
Uno strumento dà valore quando entra nei sistemi che il team usa già. Nella pipeline CI/CD l’AI può eseguire smoke test a ogni commit, una regressione selezionata sulle pull request e la suite completa sulla release candidate, aggiungere quality gate prima del merge, come la segnalazione di modifiche non coperte da test, e spiegare in pochi secondi se un fallimento dipende da un bug, da un test instabile o dall’ambiente. Il protocollo MCP sta semplificando queste integrazioni, perché permette a un assistente AI di collegarsi a strumenti esterni con un’interfaccia standard: nel catalogo trovi un corso dedicato al Model Context Protocol.
Per una PMI con un solo QA contano facilità d’uso e costo per esecuzione, e spesso basta partire da un assistente di codice che genera i test nel framework già in uso. Per un’azienda strutturata pesano dove vengono elaborati i dati, la gestione degli accessi, l’audit trail delle azioni dell’AI e la possibilità di esportare i test se si cambia fornitore. In entrambi i casi, una prova di qualche settimana su un modulo reale vale più di qualsiasi demo commerciale.
Governance e buone pratiche
Introdurre l’AI nel QA richiede regole chiare. La AI testing governance stabilisce cosa può fare l’AI, su quali dati, con quali controlli e chi risponde dei risultati.
Validare i test generati dall’AI
Test, dati e report prodotti dall’AI vanno revisionati come il codice scritto da un collega. Per capire come validare i test generati dall’AI basta una domanda: il test fallirebbe se la funzionalità fosse rotta? Una tecnica efficace è introdurre volutamente un errore nel codice e controllare che il test lo intercetti, verificando anche che le asserzioni seguano il requisito e non semplicemente ciò che il codice fa oggi.
Il rischio più comune è la crescita incontrollata della suite: duplicati con piccole varianti, asserzioni banali come «la pagina si carica», test su dettagli irrilevanti. Ogni test ha un costo di esecuzione e di manutenzione, quindi va collegato a un requisito o a un rischio preciso ed eliminare periodicamente quelli che coprono parti già testate altrove.
Dati sensibili, responsabilità e supervisione umana
Inviare log, database di test o codice a un modello esterno può esporre dati personali o segreti aziendali, ed è la prima preoccupazione delle aziende nel World Quality Report. Prima di adottare uno strumento verifica dove vengono elaborati i dati, se vengono usati per l’addestramento e quali garanzie offre il fornitore; nei test usa dati sintetici o anonimizzati. GDPR e, per alcuni sistemi, l’AI Act vanno considerati già nella scelta degli strumenti.
Ogni azione dell’AI dovrebbe restare tracciabile: quale test ha generato o modificato, su quale richiesta, chi l’ha approvato. Il principio human-in-the-loop prevede poi che una persona intervenga nei punti decisivi, come l’approvazione del rilascio o l’accettazione di un rischio noto. Il livello di supervisione dipende dal rischio: un test su una pagina informativa può essere gestito quasi in autonomia, uno su pagamenti, dati sanitari o calcoli fiscali richiede sempre una revisione umana.
Come cambia il ruolo del QA engineer
Il ruolo del QA engineer si sposta dalla scrittura e manutenzione degli script alla progettazione della strategia di qualità. Meno tempo sui locator rotti, più tempo su analisi del rischio, test esplorativi, revisione di ciò che l’AI produce e definizione delle regole entro cui gli agenti lavorano.
Per lavorare bene in questo scenario, il QA engineer deve saper descrivere a un agente un obiettivo che si possa verificare, perché da un’istruzione vaga escono test vaghi. Quando il prodotto da testare integra un modello linguistico, serve anche la capacità di valutarne le risposte, che possono cambiare da un’esecuzione all’altra, e di riconoscere i rischi di sicurezza tipici dell’AI. A tenere insieme il lavoro c’è la lettura di dati e metriche, che permette di capire se l’AI sta migliorando la qualità del software o sta solo aumentando il numero di test.
Per chi si occupa di persone e formazione, il cambiamento richiede un piano di upskilling e reskilling: mappare le competenze attuali del team QA, individuare chi può crescere verso il quality engineering con l’AI e costruire percorsi formativi su casi reali.
FAQ: domande comuni sulla Quality Assurance con AI
L’AI sostituirà i QA engineer?
Sostituirà una parte del lavoro ripetitivo, come la scrittura di test standard e la manutenzione degli script. Il giudizio sul rischio, la strategia di test e la responsabilità sul rilascio restano attività umane, e con l’aumento del codice generato dall’AI diventano anzi più richieste.
I test generati dall’AI sono affidabili?
Sono un buon punto di partenza. Possono contenere asserzioni deboli, duplicati o regole di business inventate, e diventano affidabili dopo una revisione umana e una prova pratica, per esempio controllando che falliscano quando si introduce un errore nel codice.
Quali sono i migliori strumenti AI per il QA?
Dipende dal contesto. Chi ha già una suite automatizzata può partire da un assistente di codice come Claude Code o Codex, chi lavora in Jira può valutare le funzioni AI dei plugin di test management, chi cerca una soluzione completa può provare una piattaforma AI-native. Il criterio più affidabile resta una prova su un modulo reale, con metriche misurate prima e dopo.
Come introdurre l’AI nel QA: i consigli di Data Masters
Il nostro consiglio è di trattare l’AI nel QA come un nuovo membro del team, inserito su compiti precisi e controllato all’inizio. Un primo progetto può durare un mese e riguardare un solo modulo, seguendo questi passaggi:
- misura il punto di partenza: durata della pipeline, tempo di manutenzione dei test, bug trovati in produzione;
- scegli un caso d’uso circoscritto, per esempio la generazione di test da user story o il triage dei fallimenti in CI;
- fissa le regole sui dati e su cosa può essere inviato a un modello esterno;
- definisci chi revisiona i test generati e con quali criteri;
- confronta i risultati con il punto di partenza ed estendi l’uso solo se i numeri migliorano.
Le competenze contano quanto gli strumenti. Chi sviluppa e testa applicazioni con agenti AI deve conoscere modelli, tool calling, valutazioni e sicurezza: sono i temi del Percorso AI Engineer. Se devi preparare un intero team, con profili tecnici e non tecnici, la nostra AI Education Academy costruisce percorsi su misura a partire da una mappatura delle competenze, con project work sui processi reali della tua azienda.












