I workflow di quality assurance in produzione richiedono più dell’esecuzione del singolo test: servono suite di regressione che girano in batch e che si integrano nelle pipeline CI/CD, in modo che i risultati facciano da gate ai deployment in automatico. Dopo aver introdotto QA Studio, la soluzione di riferimento per la QA agentica costruita con Amazon Nova Act, questa seconda parte estende quella base con test suite parallelizzate e una CLI pensata per i pipeline.
Test suite per una regressione organizzata
Con QA Studio si raggruppano singoli use case, ciascuno che valida uno specifico user journey, in collezioni chiamate test suite che girano insieme. L’esecuzione è in batch con elaborazione parallela: quando una suite parte, ogni use case gira in modo indipendente sul proprio task worker su Amazon ECS con AWS Fargate. Così una suite di 20 test viene eseguita in concorrenza invece che in sequenza, riducendo la durata complessiva. Le suite si organizzano per area funzionale, stadio di rilascio o scopo: smoke test sui percorsi critici a ogni deployment, suite di regressione su tutta l’applicazione, test di integrazione tra funzionalità. Ogni suite mantiene la propria cronologia, offrendo una vista longitudinale sulla stabilità.
Integrazione CI/CD con la CLI
L’interfaccia web va bene per creazione interattiva ed esecuzione on-demand, ma i pipeline richiedono altro: esecuzione da riga di comando, output strutturato, autenticazione non interattiva ed exit code. La CLI qa-studio risponde a questo. Si collega allo stesso backend API dell’app web, ma invece di dispacciare i test ai worker Fargate li esegue con Nova Act sulla macchina dove gira la CLI, ad esempio un runner CI/CD, riportando poi i risultati al deployment di QA Studio. Per gli ambienti automatizzati supporta l’autenticazione OAuth 2.0 client credentials, con token richiesti e messi in cache automaticamente senza login via browser.
Il comando qa-studio run esegue singoli use case o intere suite. Diversi meccanismi di override permettono di puntare gli stessi test ad ambienti diversi senza duplicare le definizioni: --base-url sostituisce il dominio dell’URL di partenza mantenendo path e query, --var sovrascrive le variabili di template, mentre --region e --model-id controllano la Region del browser e la versione del modello Nova Act. I secret sono conservati in AWS Secrets Manager, cifrati a riposo, e non vengono scritti nei log di esecuzione.
Exit code e gating
La CLI usa exit code mappati direttamente sugli stati del pipeline: 0 quando tutti i test passano (il pipeline continua), 1 quando uno o più test falliscono (fallimento di test), 2 per errori della CLI come autenticazione o configurazione (errore infrastrutturale). Questo modello a tre stati permette di distinguere i fallimenti dei test dai problemi di infrastruttura e di configurare strategie di notifica o retry diverse. Il post include esempi pronti per GitHub Actions, GitLab CI e Jenkins, e la soluzione di riferimento è disponibile su GitHub.
- Le test suite organizzano la regressione in collezioni con esecuzione parallela su Fargate.
- La CLI porta i test agentici nei pipeline con override d’ambiente e gestione sicura dei secret.
- Gli exit code a tre stati separano i fallimenti dei test dagli errori infrastrutturali.
Fonte: Accelerating software delivery with agentic QA automation using Amazon Nova Act – Part 2 — https://aws.amazon.com/blogs/machine-learning/accelerating-software-delivery-with-agentic-qa-automation-using-amazon-nova-act-part-2/
Hai qualcosa da aggiungere? Unisciti alla discussione.