Mercoledì 4 novembre 2026
L’edizione di oggi
Millebit
AI · Software · QA
Il segnale, non il rumore.

Gli articoli di Millebit sono scritti con l’intelligenza artificiale a partire da fonti citate in ogni pezzo. Come lavoriamo

Approfondimento

Quando l'automazione accelera, la qualità dipende da requisiti, dati e integrazione

Testo scritto con l’intelligenza artificiale a partire da 5 fonti citate, senza revisione umana prima della pubblicazione.

Con automazione e agenti AI il collo di bottiglia per la qualità si sposta dal «saper scrivere test» al progettare requisiti, dati di test e flussi end-to-end che rendano le verifiche significative e ricostruibili.

Illustrazione generata con l’intelligenza artificiale

Un order ID creato dall’API e un numero diverso sulla pagina di conferma. Due test verdi, ma nessuna certezza che l’utente veda l’ordine giusto. Con automazione e agenti AI il collo di bottiglia non è scrivere test, è progettare requisiti, dati di test e flussi end to end che rendano le verifiche significative e ricostruibili3,5.

1) La tesi: perché il nodo non è più la scrittura dei test

Agenti come Claude Code e Cursor portano lavoro che prima richiedeva settimane in code review in un giorno. Lo sforzo si sposta fuori dallo sviluppo, su requisiti e test5. La velocità amplifica le ambiguità. Un input confuso produce risultati completi ma sbagliati. Requisiti cristallini contano più di prima, perché incomprensioni che prima emergevano in corsa ora arrivano già impacchettate5.

Un’intera feature può nascere da uno o due prompt. Il rischio è non provarla end to end fino a tardi. I test diventano il punto di scoperta di bug e scarti tra specifica e prodotto5. Conta quali verifiche rendono tracciabile il comportamento del sistema.

2) Cosa cambia per chi entra nel QA: manuale, codice e automazione

Saarathi Academy, a Old Baneshwor, propone un percorso netto. Poche settimane di manual testing. Studio del codice dalla seconda settimana. Poi automazione con Playwright e Selenium, e un primo test Cypress entro la settimana 71. Prima casi chiari e bug report leggibili, poi strumenti. Scrivere test automatici senza saper progettare test case porta a verificare in fretta le cose sbagliate1.

Il mercato spinge su tool e linguaggi. Guide in Nepal citano Selenium, Cypress, Playwright, spesso con Java, Python o JavaScript. Il manuale “resta uno standard”, ma c’è “una spinta significativa” verso l’automazione1. Un profilo con soli test manuali punta a ruoli manuali. Chi porta anche pochi test automatici funzionanti allarga il raggio1. La scelta riguarda abitudini di base solide e capacità di collegare i livelli del sistema.

3) I limiti pratici: dati che non attraversano strumenti e migrazioni che rompono tutto

Due strumenti separati, uno per API e uno per UI, possono nascondere un’incoerenza di fondo. L’articolo su Ministry of Testing segue un ID lungo l’intero flusso. Primo passo: il test API crea l’ordine e riceve un ID, per esempio 84721. Secondo passo: il test UI apre la conferma e cerca lo stesso 84721. Se legge 93058, i due “pass” non parlano dello stesso oggetto. Due verdi non valgono un end to end coerente3. Serve integrare i passaggi nella stessa esecuzione, con dati condivisi3.

Anche le migrazioni di tool mettono alla prova la qualità dei test. Il passaggio da Karma a Vitest ha bloccato la suite prima della prima asserzione: oltre mille errori TypeScript, zero test eseguiti. Sotto Karma gli stessi test passavano in Chrome. Con Angular 21, i nuovi progetti usano Vitest per default e, se non richiesto, girano in jsdom4. La correzione chiave è prosaica: in tsconfig.spec.json sostituire i tipi di Jasmine con “vitest/globals”. Questo ha eliminato la maggior parte degli errori e sbloccato la compilazione. I file con errori nei mock sono stati esclusi. Anche gli spec con fakeAsync sono rimasti rossi. La guida indica una patch di zone.js e suggerisce la riscrittura verso i fake timers di Vitest. L’esclusione degli spec rotti è entrata anche in tsconfig.spec.json, non solo in angular.json, per evitare che il type check li ricompilasse4. Il piano di test include la salute della toolchain, non solo le asserzioni.

In entrambi i casi serve osservabilità. Un ID deve attraversare i livelli e l’ambiente deve compilare la suite, altrimenti i risultati non sono affidabili. L’automazione senza tracciabilità crea fiducia apparente.

4) Il ruolo dell’AI nei team di test: scelta tecnica e culturale

Louise Woodhams ha deciso che il suo team non userà l’AI nel testing. Spiega la perdita quando uno sviluppatore preferisce parlare con un modello invece che con un tester: si assottiglia la conversazione, saltano domande laterali e chiarimenti al volo. Cade una parte del lavoro che tiene alta la qualità2. Woodhams guida automazione e test in ZapMap e fa da leader TWiQ nel MoTaverse. Con Rosie Sherry tocca anche burnout e sostegno reciproco2.

Restano usi mirati. Ogni release riceve un “sigillo di approvazione” generato con Gemini. Nei dati di test per Cypress compaiono citazioni di Wicker Man. Nel pannello admin interno spunta un’icona a forma di salvadanaio. In una spiral qualcuno nota un corgi e il gruppo sorride. Dettagli piccoli, ripetuti, che tengono il filo nelle settimane tese2. La scelta sull’AI dipende dal contesto mostrato nel racconto di Woodhams.

5) Da dove partire: priorità pratiche per rendere efficaci automazione e agenti

Il filo che unisce questi casi è operativo.

  • Rendere espliciti i dati critici nei casi di test. Se un ID nasce a livello API, lo stesso ID deve arrivare in UI. La verifica deve seguire l’oggetto lungo il flusso, non limitarsi a due passaggi separati3.
  • Integrare strumenti e step. Mettere API e UI nella stessa esecuzione quando la coerenza dei dati è essenziale. Meglio ridurre i punti ciechi che moltiplicare tool3.
  • Curare la toolchain come parte della qualità. Verificare tipi e ambienti prima della migrazione. In Angular 21 e Vitest, sostituire i tipi Jasmine con “vitest/globals” ha sbloccato la suite. Escludere temporaneamente gli spec rotti evita che il type check fermi tutti4.
  • Scrivere requisiti che un agente non possa fraintendere. La velocità degli agenti porta patch in giornata. Se l’input è ambiguo, l’output lo moltiplica. Il testing diventa il primo argine, ma parte dall’analisi5.
  • Formare i profili junior su basi solide. Poche settimane di manuale, casi chiari, bug report leggibili. Studio del codice presto. Poi automazione con Playwright, Selenium e Cypress entro la settimana 7. Così i test automatici nascono da test case sensati1.
  • Decidere se e dove l’AI aiuta davvero. Alcuni team la escludono dal testing per preservare conversazioni e chiarimenti. Nel racconto di Woodhams compaiono usi leggeri, come un sigillo generato con Gemini2.

Spingere ancora sulla sola generazione del codice dà rendimenti decrescenti. I guadagni passano da requisiti chiari, dati condivisi e tracciabilità dei test end to end. Scelte che aiutano un agente a produrre output valutabili e un team a fidarsi dei verdi che conta vedere5.

Fonti

  1. A Kathmandu: corso QA suggerisce poche settimane di manuale poi automazione millebit.com
  2. Louise Woodhams: lei e il suo team scelgono di non usare l'AI nei test millebit.com
  3. Un ID ordine. Due strumenti di test. Chi collega i punti? millebit.com
  4. La migrazione dei test Angular a Vitest si blocca prima della prima asserzione millebit.com
  5. Con IA lo snodo non è più il codice ma requisiti e test millebit.com
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici

Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:

  • Rilettura. Un passaggio toglie i tic della prosa generata da un modello, come i contrasti costruiti e le frasi che annunciano invece di informare, senza toccare fatti e fonti.
  • Fedeltà alle fonti. Un passaggio dedicato toglie ogni affermazione che le fonti non sostengono. Valutazione su questo pezzo: 9/10.
  • Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale: superato.
  • Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica. Questo articolo ha preso 8,0/10.

I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.

Come funziona Millebit, nel dettaglio →

Hai trovato un errore? Segnalacelo
Tipo di segnalazione

Leggiamo ogni segnalazione. Le correzioni fatte sono elencate in Correzioni. L’email, se la lasci, serve solo a risponderti.