Riepilogo Tecnico: Agente QA Autonomo

Definizione del Problema

Il documento affronta il collo di bottiglia critico nello sviluppo software moderno in cui l'Assicurazione della Qualità (QA) non tiene il passo con i rapidi cicli Agile e DevOps. Una sfida primaria è il "divario semantico" tra i requisiti leggibili dall'uomo (linguaggio naturale, mockup) e il codice di test eseguibile dalla macchina (script Selenium). Sebbene i Modelli Linguistici su Larga Scala (LLM) possano generare codice, soffrono di un problema di "programmatore cieco": privi di conoscenza della specifica Applicazione in Test (AUT), spesso allucinano elementi UI inesistenti (ad esempio, ipotizzando un ID come #submit quando l'ID reale è #btn-confirm). Ciò porta a tassi di fallimento elevati nell'esecuzione degli script. Gli approcci esistenti, come il Testing Basato su Modelli (MBT), sono troppo complessi da mantenere, mentre la generazione standard tramite LLM manca della necessaria contestualizzazione nelle applicazioni specifiche.

Metodologia

Gli autori propongono l'Agente QA Autonomo, un framework di Generazione Aumentata con Recupero (RAG) progettato per ancorare la generazione degli script di test sia ai requisiti funzionali che alla realtà strutturale effettiva dell'applicazione.

Architettura del Sistema

Il sistema è un'architettura modulare basata su microservizi composta da cinque livelli:

1. Frontend: Un'interfaccia Streamlit per il caricamento di documenti e la generazione di test.
2. API: Un livello FastAPI che gestisce l'orchestrazione e gli endpoint RESTful.
3. Servizio: Incapsula la logica di business, inclusa l'analisi dei documenti e la pipeline RAG.
4. Livello Dati: Utilizza ChromaDB come database vettoriale per l'archiviazione di embedding ad alta dimensionalità.
5. Livello Modello: Integra Llama 3.1-8b-instant tramite l'API di Groq per inferenza a bassa latenza.

Pipeline RAG e Ingestione

L'innovazione centrale è una pipeline di ingestione multi-modale che elabora:

• Requisiti Testuali: PRD e specifiche in Markdown, PDF e JSON.
• Contesto Strutturale: File HTML grezzi che rappresentano il DOM dell'AUT.

La strategia di pre-elaborazione prevede un Recursive Character Text Splitter (pezzi da 1000 caratteri, sovrapposizione di 200 caratteri) per il testo. Per l'HTML, script e stili vengono rimossi, mantenendo solo i tag strutturali (div, input, button) e gli attributi (id, class, name) essenziali per i selettori Selenium.

Processo di Generazione

La pipeline segue una rigorosa formulazione matematica:

1. Embedding: I pezzi di testo e HTML vengono mappati in uno spazio vettoriale a 384 dimensioni utilizzando all-MiniLM-L6-v2.
2. Recupero: Per una query utente (ad esempio, "Testa il flusso di checkout"), il sistema recupera i pezzi top-$k$ (tipicamente $k=3$) con la massima similarità coseno. Crucialmente, filtra e unisce sia i pezzi di documentazione che quelli HTML.
3. Fusione del Contesto e Prompting: Il sistema costruisce un prompt che separa esplicitamente la documentazione recuperata ([DOCUMENTAZIONE]) dalla struttura HTML ([STRUTTURA HTML]).
4. Vincoli: Il prompt impone vincoli come "Usa SOLO gli ID forniti nell'HTML" e "Aggiungi WebDriverWait per gli elementi dinamici".
5. Generazione: L'LLM genera uno script Python Selenium basato su questo contesto ancorato.

Contributi Chiave

1. Nuova Architettura RAG per QA: Un sistema specializzato che recupera due tipi distinti di contesto: requisiti funzionali testuali e contesto strutturale HTML/DOM, a differenza dei sistemi RAG generici che si concentrano solo su codice o testo.
2. Pipeline di Ingestione Multi-Modale: Una pipeline robusta capace di elaborare formati diversi (Markdown, PDF, JSON, HTML) per costruire una base di conoscenza completa.
3. Generazione di Script Consapevole del Contesto: Un metodo dimostrato per generare script Selenium ancorati alle strutture HTML reali, riducendo significativamente gli errori di localizzazione degli elementi.
4. Valutazione Riproducibile: Una configurazione sperimentale dettagliata con analisi statistica su 20 scenari di test, fornendo un benchmark per i test guidati dall'IA.

Risultati Sperimentali

Il sistema è stato valutato su un'applicazione di e-commerce personalizzata con 127 elementi DOM distribuiti su quattro pagine. La valutazione ha confrontato l'Agente QA Autonomo (RAG) con una Baseline LLM Standard (Llama 3.1-8b senza contesto).

Metriche Chiave (Media su 3 esecuzioni):

• Validità Sintattica: RAG ha raggiunto il 100% (vs 95% per la Baseline).
• Risoluzione Elementi: RAG ha raggiunto il 95% (vs 40% per la Baseline). Questa metrica misura l'accuratezza dei selettori nel localizzare gli elementi DOM target.
• Successo Esecuzione: RAG ha raggiunto il 90% (vs 30% per la Baseline). Questo misura gli script eseguiti dall'inizio alla fine senza eccezioni.

Significatività Statistica:
Test t a due campioni hanno confermato che i miglioramenti sono statisticamente significativi ($p < 0.001$) con grandi dimensioni dell'effetto (Cohen's $d = 3.2$ per la risoluzione, $d = 3.8$ per l'esecuzione).

Studio di Ablazione:

• RAG Solo Testo: 60% di risoluzione.
• RAG Solo HTML: 85% di risoluzione.
• RAG Completo (Testo + HTML): 95% di risoluzione.
  Ciò conferma che la comprensione strutturale del DOM è obbligatoria per l'automazione UI, poiché i requisiti semantici da soli sono insufficienti.

Analisi dei Fallimenti:
Il tasso di fallimento del 10% nell'agente RAG è stato attribuito a:

1. Tempistica degli Elementi Dinamici: Elementi che appaiono solo dopo animazioni JavaScript non catturate negli snapshot HTML statici.
2. Contesto Ambiguo: Contesto insufficiente per disambiguare quando esistevano elementi multipli simili.

Significato e Affermazioni

Il documento afferma che il problema delle allucinazioni nella generazione di codice basata su LLM può essere efficacemente mitigato attraverso un'architettura RAG specifica per il dominio. Trattando l'AUT come una fonte di conoscenza da ingerire piuttosto che come una scatola nera, il sistema permette agli LLM di agire come ingegneri QA competenti.

Gli autori stimano una riduzione del 60–70% nel tempo di scrittura degli script da parte degli ingegneri QA automatizzando l'identificazione dei selettori e la generazione di boilerplate. Sostengono che, sebbene l'LLM Standard sia più veloce (4s vs 13.2s di latenza end-to-end), l'approccio RAG è più conveniente se si tiene conto del tempo di debug manuale richiesto dal tasso di fallimento del 70% della baseline.

Il lavoro si posiziona come fondamento per suite di test "auto-scrittenti e auto-riparanti", sebbene gli autori riconoscano modestamente le limitazioni riguardanti l'ingestione di HTML statico (sfidante per le Single Page Applications) e la necessità di ulteriori validazioni in domini diversi oltre all'e-commerce.