Resumen Técnico: Agente de QA Autónomo

Definición del Problema

El artículo aborda el cuello de botella crítico en el desarrollo de software moderno donde la Garantía de Calidad (QA) se queda atrás respecto a los ciclos ágiles y DevOps rápidos. Un desafío principal es la "brecha semántica" entre los requisitos legibles por humanos (lenguaje natural, maquetas) y el código de prueba ejecutable por máquinas (scripts de Selenium). Aunque los Modelos de Lenguaje Grandes (LLM) pueden generar código, sufren de un problema de "programador ciego": al carecer de conocimiento sobre la Aplicación bajo Prueba (AUT) específica, a menudo alucinan elementos de interfaz de usuario inexistentes (por ejemplo, adivinar un ID como #submit cuando el ID real es #btn-confirm). Esto conduce a altas tasas de fracaso en la ejecución de scripts. Los enfoques existentes, como la Prueba Basada en Modelos (MBT), son demasiado complejos de mantener, mientras que la generación estándar de LLM carece de la fundamentación necesaria en contextos de aplicación específicos.

Metodología

Los autores proponen el Agente de QA Autónomo, un marco de Generación Aumentada por Recuperación (RAG) diseñado para fundamentar la generación de scripts de prueba tanto en los requisitos funcionales como en la realidad estructural actual de la aplicación.

Arquitectura del Sistema

El sistema es una arquitectura modular basada en microservicios que comprende cinco capas:

1. Frontend: Una interfaz Streamlit para subir documentos y generar pruebas.
2. API: Una capa FastAPI que maneja la orquestación y los puntos de conexión RESTful.
3. Servicio: Encapsula la lógica de negocio, incluido el análisis de documentos y el pipeline RAG.
4. Capa de Datos: Utiliza ChromaDB como base de datos vectorial para almacenar incrustaciones de alta dimensión.
5. Capa de Modelo: Integra Llama 3.1-8b-instant a través de la API de Groq para inferencia de baja latencia.

Pipeline RAG e Ingesta

La innovación central es un pipeline de ingestión multimodal que procesa:

• Requisitos Textuales: PRD y especificaciones en Markdown, PDF y JSON.
• Contexto Estructural: Archivos HTML crudos que representan el DOM de la AUT.

La estrategia de preprocesamiento implica un Divisor de Texto de Caracteres Recursivo (fragmentos de 1000 caracteres, superposición de 200 caracteres) para el texto. Para el HTML, se eliminan los scripts y estilos, reteniendo solo las etiquetas estructurales (div, input, button) y los atributos (id, class, name) esenciales para los selectores de Selenium.

Proceso de Generación

El pipeline sigue una formulación matemática estricta:

1. Incrustación (Embedding): Los fragmentos de texto y HTML se mapean a un espacio vectorial de 384 dimensiones utilizando all-MiniLM-L6-v2.
2. Recuperación: Para una consulta de usuario (por ejemplo, "Probar flujo de pago"), el sistema recupera los fragmentos superiores-$k$ (típicamente $k=3$) con la mayor similitud del coseno. Crucialmente, filtra y fusiona tanto los fragmentos de documentación como los de HTML.
3. Fusión de Contexto y Prompting: El sistema construye un prompt que separa explícitamente la documentación recuperada ([DOCUMENTACIÓN]) de la estructura HTML ([ESTRUCTURA HTML]).
4. Restricciones: El prompt impone restricciones como "Usar SOLO IDs del HTML proporcionado" y "Añadir WebDriverWait para elementos dinámicos".
5. Generación: El LLM genera un script de Python Selenium basado en este contexto fundamentado.

Contribuciones Clave

1. Arquitectura RAG Novel para QA: Un sistema especializado que recupera dos tipos de contexto distintos: requisitos funcionales textuales y contexto estructural HTML/DOM, a diferencia de los sistemas RAG genéricos que se centran solo en código o texto.
2. Pipeline de Ingestión Multimodal: Un pipeline robusto capaz de procesar formatos diversos (Markdown, PDF, JSON, HTML) para construir una base de conocimientos integral.
3. Generación de Scripts Consciente del Contexto: Un método demostrado para generar scripts de Selenium fundamentados en estructuras HTML reales, reduciendo significativamente los errores de ubicación de elementos.
4. Evaluación Reproducible: Una configuración experimental detallada con análisis estadístico en 20 escenarios de prueba, proporcionando un punto de referencia para las pruebas impulsadas por IA.

Resultados Experimentales

El sistema se evaluó en una aplicación de comercio electrónico personalizada con 127 elementos DOM en cuatro páginas. La evaluación comparó al Agente de QA Autónomo (RAG) frente a una Línea Base LLM Estándar (Llama 3.1-8b sin contexto).

Métricas Clave (Media sobre 3 ejecuciones):

• Validez de Sintaxis: RAG logró 100% (vs. 95% para la Línea Base).
• Resolución de Elementos: RAG logró 95% (vs. 40% para la Línea Base). Esta métrica mide la precisión de los selectores para localizar elementos DOM objetivo.
• Éxito de Ejecución: RAG logró 90% (vs. 30% para la Línea Base). Esto mide scripts que se ejecutan de principio a fin sin excepciones.

Significancia Estadística:
Las pruebas t de dos muestras confirmaron que las mejoras son estadísticamente significativas ($p < 0.001$) con tamaños de efecto grandes (Cohen's $d = 3.2$ para resolución, $d = 3.8$ para ejecución).

Estudio de Ablación:

• RAG Solo Texto: 60% de resolución.
• RAG Solo HTML: 85% de resolución.
• RAG Completo (Texto + HTML): 95% de resolución.
  Esto confirma que la comprensión estructural del DOM es obligatoria para la automatización de UI, ya que los requisitos semánticos por sí solos son insuficientes.

Análisis de Fallos:
La tasa de fallo del 10% en el agente RAG se atribuyó a:

1. Temporización de Elementos Dinámicos: Elementos que aparecen solo después de animaciones de JavaScript no capturadas en instantáneas de HTML estático.
2. Contexto Ambiguo: Contexto de desambiguación insuficiente cuando existían múltiples elementos similares.

Significancia y Afirmaciones

El artículo afirma que el problema de la alucinación en la generación de código basada en LLM puede mitigarse eficazmente mediante una arquitectura RAG específica del dominio. Al tratar la AUT como una fuente de conocimiento que debe ingerirse en lugar de una caja negra, el sistema permite que los LLM actúen como ingenieros de QA competentes.

Los autores estiman una reducción del 60–70% en el tiempo de escritura de scripts por parte de ingenieros de QA al automatizar la identificación de selectores y la generación de plantillas. Argumentan que, aunque el LLM Estándar es más rápido (4s vs. 13.2s de latencia de extremo a extremo), el enfoque RAG es más rentable al tener en cuenta el tiempo de depuración manual requerido para la tasa de fallo del 70% de la línea base.

El trabajo se posiciona como una base para suites de pruebas "autoescritas y auto-reparables", aunque los autores reconocen modestamente las limitaciones relacionadas con la ingestión de HTML estático (desafiante para Aplicaciones de Página Única) y la necesidad de una validación adicional en diversos dominios más allá del comercio electrónico.