Resumo Técnico: Agente de QA Autônomo

Definição do Problema

O artigo aborda o gargalo crítico no desenvolvimento de software moderno onde a Garantia de Qualidade (QA) fica aquém dos ciclos ágeis e DevOps rápidos. Um desafio primário é a "lacuna semântica" entre requisitos legíveis por humanos (linguagem natural, mockups) e código de teste executável por máquinas (scripts Selenium). Embora os Modelos de Linguagem de Grande Porte (LLMs) possam gerar código, eles sofrem de um problema de "codificador cego": sem conhecimento da Aplicação Sob Teste (AUT) específica, eles frequentemente alucinam elementos de interface do usuário (UI) inexistentes (por exemplo, adivinhando um ID como #submit quando o ID real é #btn-confirm). Isso leva a altas taxas de falha na execução de scripts. Abordagens existentes, como Teste Baseado em Modelos (MBT), são complexas demais para manter, enquanto a geração padrão de LLM carece da fundamentação necessária em contextos de aplicação específicos.

Metodologia

Os autores propõem o Agente de QA Autônomo, um framework de Geração Aumentada por Recuperação (RAG) projetado para fundamentar a geração de scripts de teste tanto nos requisitos funcionais quanto na realidade estrutural real da aplicação.

Arquitetura do Sistema

O sistema é uma arquitetura modular baseada em microsserviços composta por cinco camadas:

1. Frontend: Uma interface Streamlit para upload de documentos e geração de testes.
2. API: Uma camada FastAPI que lida com orquestração e endpoints RESTful.
3. Serviço: Encapsula a lógica de negócios, incluindo análise de documentos e o pipeline RAG.
4. Camada de Dados: Utiliza o ChromaDB como banco de dados vetorial para armazenar embeddings de alta dimensão.
5. Camada de Modelo: Integra o Llama 3.1-8b-instant via API da Groq para inferência de baixa latência.

Pipeline RAG e Ingestão

A inovação central é um pipeline de ingestão multimodal que processa:

• Requisitos Textuais: PRDs e especificações em Markdown, PDF e JSON.
• Contexto Estrutural: Arquivos HTML brutos representando o DOM da AUT.

A estratégia de pré-processamento envolve um Divisor de Texto Recursivo por Caracteres (pedaços de 1000 caracteres, sobreposição de 200 caracteres) para texto. Para HTML, scripts e estilos são removidos, retendo apenas tags estruturais (div, input, button) e atributos (id, class, name) essenciais para seletores Selenium.

Processo de Geração

O pipeline segue uma formulação matemática estrita:

1. Embedding: Pedacos de texto e HTML são mapeados para um espaço vetorial de 384 dimensões usando all-MiniLM-L6-v2.
2. Recuperação: Para uma consulta do usuário (por exemplo, "Testar fluxo de checkout"), o sistema recupera os $k$-superiores (tipicamente $k=3$) pedaços com a maior similaridade cosseno. Crucialmente, ele filtra e mescla tanto pedaços de documentação quanto de HTML.
3. Fusão de Contexto e Prompting: O sistema constrói um prompt que separa explicitamente a documentação recuperada ([DOCUMENTAÇÃO]) da estrutura HTML ([ESTRUTURA HTML]).
4. Restrições: O prompt impõe restrições como "Use APENAS IDs do HTML fornecido" e "Adicione WebDriverWait para elementos dinâmicos".
5. Geração: O LLM gera um script Python Selenium baseado neste contexto fundamentado.

Contribuições Principais

1. Arquitetura RAG Nova para QA: Um sistema especializado que recupera dois tipos distintos de contexto: requisitos funcionais textuais e contexto estrutural HTML/DOM, ao contrário de sistemas RAG genéricos que focam apenas em código ou texto.
2. Pipeline de Ingestão Multimodal: Um pipeline robusto capaz de processar formatos diversos (Markdown, PDF, JSON, HTML) para construir uma base de conhecimento abrangente.
3. Geração de Scripts Consciente de Contexto: Um método demonstrado para gerar scripts Selenium fundamentados em estruturas HTML reais, reduzindo significativamente erros de localização de elementos.
4. Avaliação Reprodutível: Uma configuração experimental detalhada com análise estatística em 20 cenários de teste, fornecendo um benchmark para testes orientados por IA.

Resultados Experimentais

O sistema foi avaliado em uma aplicação de comércio eletrônico personalizada com 127 elementos DOM em quatro páginas. A avaliação comparou o Agente de QA Autônomo (RAG) contra uma Linha de Base LLM Padrão (Llama 3.1-8b sem contexto).

Métricas Principais (Média em 3 execuções):

• Validade de Sintaxe: RAG alcançou 100% (vs. 95% para a Linha de Base).
• Resolução de Elementos: RAG alcançou 95% (vs. 40% para a Linha de Base). Esta métrica mede a precisão dos seletores em localizar elementos DOM alvo.
• Sucesso de Execução: RAG alcançou 90% (vs. 30% para a Linha de Base). Isso mede scripts executando do início ao fim sem exceções.

Significância Estatística:
Testes t de duas amostras confirmaram que as melhorias são estatisticamente significativas ($p < 0.001$) com tamanhos de efeito grandes (Cohen's $d = 3.2$ para resolução, $d = 3.8$ para execução).

Estudo de Ablação:

• RAG Apenas Texto: 60% de resolução.
• RAG Apenas HTML: 85% de resolução.
• RAG Completo (Texto + HTML): 95% de resolução.
  Isso confirma que a compreensão estrutural do DOM é obrigatória para automação de UI, pois requisitos semânticos sozinhos são insuficientes.

Análise de Falhas:
A taxa de falha de 10% no agente RAG foi atribuída a:

1. Temporização de Elementos Dinâmicos: Elementos aparecendo apenas após animações JavaScript não capturadas em instantâneos HTML estáticos.
2. Contexto Ambíguo: Contexto de desambiguação insuficiente quando múltiplos elementos semelhantes existiam.

Significância e Alegações

O artigo alega que o problema de alucinação na geração de código baseada em LLM pode ser efetivamente mitigado através de uma arquitetura RAG específica de domínio. Ao tratar a AUT como uma fonte de conhecimento a ser ingerida em vez de uma caixa preta, o sistema permite que LLMs atuem como engenheiros de QA competentes.

Os autores estimam uma redução de 60–70% no tempo de escrita de scripts por engenheiros de QA ao automatizar a identificação de seletores e a geração de boilerplate. Eles argumentam que, embora o LLM Padrão seja mais rápido (4s vs. 13.2s de latência ponta a ponta), a abordagem RAG é mais custo-efetiva ao contabilizar o tempo de depuração manual necessário para a taxa de falha de 70% da linha de base.

O trabalho se posiciona como uma fundação para suites de teste "auto-escritas, auto-curáveis", embora os autores reconheçam modestamente limitações relacionadas à ingestão de HTML estático (desafiador para Aplicações de Página Única) e a necessidade de validação adicional em diversos domínios além do comércio eletrônico.