IA e qualità

L'intelligenza artificiale nel codice: cosa sappiamo sui bug e sugli oneri del QA

L’adozione dell’intelligenza artificiale per la programmazione sta avanzando, ma le cifre relative al numero maggiore di bug provengono principalmente da percezioni e non dimostrano la causalità. Cosa mostrano realmente i sondaggi e come misurarlo in un team.

4 novembre 2026 9 min di lettura

L’adozione è elevata, ma i parametri contano

Il sondaggio del 2025 di Stack Overflow ha rilevato che l'84% degli intervistati ha utilizzato o pianificato di utilizzare strumenti di intelligenza artificiale nel proprio processo di sviluppo; Tra gli sviluppatori professionisti, il 51% ha riferito di utilizzarli quotidianamente. La domanda riguarda gli strumenti di intelligenza artificiale in generale: non dimostra che tale percentuale generi codice, né descrive specificamente i team di QA.

Per guardare dall’altra parte del flusso, DeviQA ha pubblicato il proprio sondaggio nel luglio 2026 su 300 professionisti del QA, SDET e leader dei test. Il 52% ha affermato di aver percepito un aumento dei bug da quando lo sviluppo ha iniziato a utilizzare l'intelligenza artificiale e il 58% ha percepito un maggiore carico di test. Si tratta di un segnale rilevante da indagare, non di una stima rappresentativa del settore: si tratta di un campione interno di fornitori, basato su risposte ed esperienze auto-riferite.

Il sondaggio di DeviQA chiede informazioni sui cambiamenti che i partecipanti associano temporaneamente all'adozione dell'intelligenza artificiale; non confronta repository equivalenti con e senza intelligenza artificiale, né controlla la dimensione delle modifiche, l'esperienza, la velocità di consegna o la politica di revisione. Potrebbe anche influenzare il fatto che ora vengano rilevati o segnalati più difetti. Pertanto, non è corretto concludere che l’intelligenza artificiale, di per sé, causi un aumento generale dei bug.

DORA 2025 propone di leggere l’AI come un amplificatore del sistema di lavoro esistente: feedback rapidi, piattaforme interne e priorità chiare aiutano; Vengono amplificati anche i processi deboli e i cambiamenti difficili da rivedere. La ricerca riporta associazioni, non una regola causale universale. Il messaggio pratico è misurare l’intero flusso, non attribuire la variazione a un singolo strumento.

Cosa misurare prima di modificare il processo

Registrare su diverse iterazioni quante modifiche vengono apportate e di quale dimensione; quanti difetti compaiono prima e dopo la pubblicazione; la sua gravità; quante volte viene riaperto un caso; quanto tempo impiega il QA per ricevere e rispondere; e quanto lavoro viene ripetuto. Modifiche separate apportate con l'aiuto dell'intelligenza artificiale solo se il team riesce a identificarle in modo coerente e senza monitorare ciascuna persona.

Confronta attentamente i periodi: utilizza le stesse definizioni, annota le modifiche al prodotto o alle apparecchiature ed esamina sia ciò che rilevano i test sia quali avvisi si rivelano falsi. Se vengono rilasciate più modifiche, il numero totale di difetti potrebbe aumentare anche se ciascuna modifica ne contiene meno. Confrontare i difetti con il numero e l’entità delle modifiche aiuta a capire cosa è successo.

Immagina che prima che il team rilasciasse dieci modifiche a settimana e trovasse quattro difetti; Dopo aver aggiunto un assistente, pubblica venti modifiche e ne trova sei. Il totale è aumentato, ma il tasso è passato da 0,4 a 0,3 difetti per cambio. Senza il denominatore, il titolo “ci sono più bug” mescola il volume di consegna con la qualità per unità. Il rilevamento può anche aumentare perché sono stati aggiunti test, registri migliori o revisioni più approfondite. In tal caso, vedere più guasti può rivelare che il sistema sta andando meglio, non che il prodotto è peggiorato.

È conveniente separare quattro misure: difetti riscontrati prima della pubblicazione; difetti arrivati alla produzione; gravità e impatto; e i costi per indagarli e correggerli. Trovare più problemi minori durante i test non equivale ad avere più incidenti utente. Al contrario, un tasso stabile può nascondere un rischio maggiore se il numero di modifiche aumenta o se i fallimenti si concentrano nei pagamenti, nelle autorizzazioni o nei dati. Decidi cosa dirai prima di confrontare.

Cosa aggiunge la revisione del codice generato, oltre all'esecuzione dei test

Solo perché tutti i test vengono superati non dimostra di per sé che un cambiamento sia facile da mantenere, rispetti le regole del progetto o abbia test sufficienti. In un'indagine del 2026, METR ha chiesto a quattro manutentori di tre progetti di rivedere 296 modifiche preparate dagli agenti e approvate da una valutazione automatizzata. In media i responsabili hanno accettato meno modifiche rispetto al valutatore: la differenza è stata di 24 punti percentuali. Il campione era limitato e gli agenti non potevano correggere le loro proposte dopo aver ricevuto commenti; Il risultato rende chiara una distinzione: “i test superati” e “il team è disposto a integrare il cambiamento” non significano la stessa cosa.

Quindi, oltre a controllare che la funzione faccia quello che ci si aspetta, controlla se la modifica influisce su altre funzioni, come gestisce gli errori, se rispetta la sicurezza e se i nuovi test rilevano davvero il problema. Un test generato può ripetere lo stesso errore presente nel codice. Chiede a ciascun test di riferirsi a un requisito e verifica che fallisca quando la funzione che intendeva proteggere viene rimossa.

Per quattro-sei settimane, registrare una linea di base con definizioni stabili e selezionare cambiamenti comparabili per dimensione, rischio e componente. Se il team utilizza l’intelligenza artificiale, etichetta il cambiamento volontariamente e a livello di lavoro, non a livello di persona. Confronta gruppi o periodi quando possibile, prendi nota dei cambiamenti simultanei (nuova copertura, refactoring, turnover del team) e normalizza in base a cambiamenti, linee modificate o esposizione. Non utilizzare una sola percentuale come obiettivo: potrebbe incoraggiare a nascondere i difetti o a ridurre la copertura.

Un utile dashboard mostra quanti difetti compaiono, quanto sono gravi e in quale fase vengono rilevati; quanti raggiungono la produzione o riaprono; quanto tempo impiega il team per ricevere una risposta; e quanti avvisi automatici conferma una persona. Conserva degli esempi per capire da dove provengono i problemi. Se il team lavora più velocemente, ma nella produzione arrivano difetti più gravi o le rilavorazioni aumentano, il processo non è migliorato. Se ne catturi di più prima della pubblicazione e meno arrivi alla produzione, potresti trovare meglio i problemi ora.

Una ricerca recente segnala un aumento del carico di lavoro per il QA

Un sondaggio separato di DeviQA, pubblicato nel settembre 2026 e a cui hanno risposto 4.000 professionisti del QA, aiuta a descrivere l’altra estremità del flusso. Il 65% ha affermato che le funzioni vengono testate prima; Il 64% ha indicato che arrivano più funzioni contemporaneamente; Il 55% ha osservato una coda di QA più lunga; e il 52% ha riportato più cicli di test-correzione-retest. Questi dati non vanno confusi con la precedente indagine su 300 persone: sono strumenti, campioni e domande diversi. Inoltre, non misurano i difetti per ogni cambiamento né dimostrano che l’intelligenza artificiale sia la causa. Mostrano una tensione concreta che un team può controllare: una distribuzione più rapida non elimina la revisione, la regressione o il coordinamento e può concentrare il lavoro ricevuto dal QA.

La conseguenza pratica è quella di non assegnare più blind test. Vale la pena chiedersi dove si forma la coda: attesa dell'ambiente, requisiti incompleti, revisione tardiva, dati difficili da preparare, errori intermittenti o troppi avvisi non riconosciuti. Ogni causa richiede una risposta diversa. Se il team non sa quando arriverà una consegna o cosa è cambiato, un secondo strumento di intelligenza artificiale può aggiungere rumore; Se conosci la differenza, il rischio e il risultato atteso, puoi stabilire meglio le priorità. Misura il tempo di attesa separato dal tempo effettivo di test: così si distingue un problema di capacità da un problema di flusso.

Un conteggio assoluto risponde a quanti difetti sono stati riscontrati; non indica da solo se ogni cambiamento è peggiore. Supponiamo che un team abbia esaminato dieci modifiche e trovato quattro difetti, quindi ne abbia esaminati venti e ne abbia trovati sei. Il totale è cresciuto, ma il tasso di cambio è sceso. Anche questo tasso può essere fuorviante se le nuove modifiche sono più ampie, toccano componenti diversi o ricevono una maggiore copertura. Utilizza vari denominatori a seconda della decisione: modifiche riviste per carico di triage, dimensioni e rischio per confrontare l'esposizione, esecuzioni per stabilità e utenti o transazioni per stimare l'impatto. Non trasformare le linee di codice in una misura universale di qualità: servono da contesto, non da sostituto del rischio funzionale.

Inoltre separa la gravità, i tempi di rilevamento e i costi. Un difetto bloccante rilevato prima del rilascio può essere un segnale che i test stanno funzionando; un problema minore in produzione può essere meno grave di un errore di autorizzazione, anche se entrambi contano come "un bug". Registrare se il problema riguardava i requisiti, l'implementazione, l'integrazione, i dati o l'ambiente. Questa classificazione serve a correggere il processo e non a incolpare l'autore o lo strumento. Conserva esempi rappresentativi e rivedi cosa è cambiato tra i periodi; una metrica senza una spiegazione del caso può spingere il team a ottimizzare il numero sbagliato.

Come valutare uno strumento con criteri per scartarlo

Prima di aggiungere l'intelligenza artificiale al ciclo, definire una domanda che consenta una risposta negativa: ad esempio: "I test basati su storie riducono le omissioni senza aumentare i tempi di revisione?" Scegli un flusso delimitato, imposta una linea di base e concorda cosa conta come salto, duplicato, avviso valido e rielaborazione. Confronta diverse iterazioni e modifiche di rischio simile. Se possibile, alternare compiti o team; In caso contrario, annotare i cambiamenti nella copertura, nel personale, nella liberatoria e negli strumenti che potrebbero spiegare la differenza. Non attribuire causalità al confronto prima/dopo se si sono verificati altri cambiamenti contemporaneamente.

Anche i test controllati necessitano di una regola di interruzione. Se lo strumento non dispone di un contesto sufficiente, utilizza dati reali senza autorizzazione, modifica un ambiente non isolato o produce risultati che nessuno può riprodurre, dovrebbe essere interrotto e messo in attesa di esecuzione. La revisione umana si concentra sui rischi rilevanti, non accettando tutto ciò che il modello genera. Alla chiusura, presenta i risultati insieme ai limiti del campione, ai falsi positivi, ai difetti sfuggiti e al costo del tempo di revisione. Se i dati non supportano una conclusione, quella è una conclusione valida: il passo successivo è migliorare la misurazione, non dichiarare il successo.

Un avviso automatico è un'osservazione che deve ancora essere classificata. Può indicare un nuovo difetto, una regressione nota, una differenza visiva non impattante, un problema ambientale o un test che non rappresenta più il comportamento previsto. Se la dashboard somma tutto come “bug”, lo strumento sembrerà trovare più problemi anche se la maggior parte di essi sono duplicati o rumore. Mantiene stati distinti per i risultati ricevuti, revisionati, riproducibili, confermati, duplicati e scartati; Registra anche il motivo dello scarto. In questo modo il team può misurare l'accuratezza e i costi del triage senza nascondere un segnale valido al di sotto della media.

L’analisi deve guardare anche al tempo. Un guasto rilevato in pochi minuti non ha lo stesso costo di una segnalazione che appare al termine di una suite notturna; Anche un avviso corretto che nessuno vede fino a dopo il rilascio non migliora la prevenzione. Nota quanto tempo ha impiegato il sistema a segnalare, quando qualcuno lo ha recensito e quando è stato chiuso. Se il numero grezzo di avvisi aumenta ma la percentuale confermata diminuisce e il tempo di revisione aumenta, l'esperimento successivo dovrebbe migliorare la selezione e il contesto, non generare ulteriori casi. Se aumenta il rilevamento precoce dei difetti rilevanti e diminuisce la successiva rilavorazione, il segnale di utilità è più forte.