Sber mostró cómo RAG y LLM en el IDE convierten escenarios manuales en pruebas automatizadas

Sber demostró cómo reducir una de las tareas más rutinarias en QA: convertir escenarios de prueba manual en pruebas automatizadas directamente en el IDE. En el núcleo está una combinación de LLM y RAG, que no solo escribe código, sino que primero busca ejemplos relevantes dentro del propio proyecto para preservar su estilo, convenciones y arquitectura.

Por Qué el Prompt Directo No Funciona

La idea de "simplemente enviar una prueba manual al modelo y obtener código listo" se desmorona en la práctica ante los detalles. Un LLM realmente puede armar una prueba Java funcional, pero casi con certeza no lo hará de la manera aceptada en un equipo específico: olvidará Allure, violará el esquema de nomenclatura, colocará URLs y cuerpos de solicitud en el lugar equivocado, agregará verificaciones innecesarias o no utilizará utilidades internas como un método común de verificación de estado. Para la automatización de pruebas, esto no es cosmética sino una pérdida real de compatibilidad con el proyecto.

El problema es más profundo que la simple calidad del prompt. Las pruebas automatizadas viven dentro de su propio framework, ligadas a la arquitectura, CI, Page Object, claves TMS y convenciones de anotaciones. Si intentas pasar el proyecto completo al modelo, rápidamente chocas contra limitaciones de ventana de contexto, aumento de latencia y costo de solicitudes.

Incluso después de eso, alucinaciones, pasos perdidos y resultados inestables persisten, requiriendo refinamiento manual al estado deseado.

Cómo Funciona RAG

En lugar de few-shot estático con ejemplos seleccionados manualmente, el equipo de Sber creó un plugin para JetBrains IDE. Escanea el proyecto a través de la estructura PSI, no como texto sin procesar, por lo que ve clases, métodos, anotaciones y llamadas. Sobre esta base, el sistema recopila pasos Allure, pruebas automatizadas existentes, sus claves TMS, código y breves descripciones textuales. Luego, estas descripciones se convierten en embeddings y se guardan junto con metadatos en una base de conocimiento local o almacenamiento vectorial. Cuando llega un nuevo escenario manual al trabajo, el sistema pasa por varias etapas:

• identifica la acción y resultado esperado para cada paso;
• construye varias variantes semánticas de consulta para encontrar pasos similares;
• pide al LLM que describa brevemente la prueba completa para encontrar una prueba automatizada similar por significado;
• sustituye automáticamente ejemplos encontrados en el prompt en lugar de few-shot manual;
• verifica el resultado a través de una solicitud repetida al modelo y a través de PSI dentro del IDE.

Este enfoque permite obtener código que parece haber sido escrito por alguien de este equipo, no un modelo externo sin contexto. El artículo enfatiza por separado que la búsqueda semántica es necesaria no por el RAG de moda, sino por un propósito práctico: traer a la generación exactamente aquellos pasos, utilidades y patrones que ya han demostrado su efectividad dentro del proyecto.

RAG es few-shot que encuentra los ejemplos necesarios por sí solo.

Resultados del Prototipo

Según el equipo, el prototipo interno ya ha mostrado un efecto medible. Alrededor del 68% de las pruebas generadas estaban en un nivel aceptable y requerían solo ediciones mínimas, y la satisfacción general del usuario fue aproximadamente del 80%. La herramienta mostró los mejores resultados en escenarios de API simples y similares, donde es especialmente importante reproducir rápidamente una plantilla de código establecida sin copiar manualmente de pruebas adyacentes.

Los ingenieros de automatización también notaron una reducción en la carga cognitiva: menos tiempo en trabajo rutinario, más tiempo en escenarios complejos y decisiones arquitectónicas. Pero no hay "piloto automático" universal aquí. Las pruebas complejas con un gran número de pasos aún tienden a ser simplificadas por el modelo, y para escenarios de UI necesita más contexto, como información sobre objetos de página.

Las alucinaciones tampoco han desaparecido, por lo que la verificación final sigue siendo obligatoria. Al mismo tiempo, los autores señalan que no vieron limitaciones serias por idiomas: resultados similares se obtuvieron no solo en Java, sino también en Python y Gherkin. Según sus estimaciones, tal herramienta puede ahorrar a un ingeniero de automatización más de la mitad del tiempo escribiendo nuevas pruebas rutinarias.

Qué Significa Esto

Para las herramientas de IA en desarrollo, está comenzando una etapa más interesante: el valor se está trasladando de "generar cualquier código" a "generar código que se integre inmediatamente en un proyecto activo". La historia de Sber muestra que en QA, ganarán no los equipos que simplemente conecten LLM a IDE, sino aquellos que envuelvan el modelo alrededor de su propia base de conocimiento, verificaciones y reglas de ingeniería.