Sber a montré comment RAG et LLM dans l’IDE transforment des scénarios manuels en tests automatisés

Sber a démontré comment réduire l'une des tâches les plus routinières en QA : convertir des scénarios de test manuel en tests automatisés directement dans l'IDE. Au cœur se trouve une combinaison de LLM et RAG, qui non seulement écrit du code, mais recherche d'abord des exemples pertinents au sein du projet lui-même pour préserver son style, ses conventions et son architecture.

Pourquoi le Prompt Direct Ne Fonctionne Pas

L'idée de "simplement envoyer un test manuel au modèle et obtenir du code prêt à l'emploi" s'effondre en pratique face aux détails. Un LLM peut certes assembler un test Java fonctionnant, mais ne le fera presque certainement pas comme c'est accepté dans une équipe spécifique : il oubliera Allure, violera le schéma de nommage, placera les URL et les corps de demande au mauvais endroit, ajoutera des vérifications inutiles ou n'utilisera pas les utilitaires internes comme une méthode commune de vérification de statut. Pour l'automatisation des tests, ce n'est pas une question de cosmétique mais une perte réelle de compatibilité avec le projet.

Le problème est plus profond que simplement la qualité du prompt. Les tests automatisés vivent au sein de leur propre framework, liés à l'architecture, CI, Page Object, clés TMS et conventions d'annotations. Si vous essayez de transmettre le projet entier au modèle, vous vous heurtez rapidement aux limitations de la fenêtre de contexte, à l'augmentation de la latence et au coût des requêtes.

Même après cela, les hallucinations, les étapes manquées et les résultats instables persistent, nécessitant un raffinement manuel à l'état souhaité.

Comment Fonctionne RAG

Au lieu de few-shot statique avec des exemples sélectionnés manuellement, l'équipe de Sber a créé un plugin pour JetBrains IDE. Il analyse le projet via la structure PSI, non comme du texte brut, il voit donc les classes, les méthodes, les annotations et les appels. Sur cette base, le système collecte les étapes Allure, les tests automatisés existants, leurs clés TMS, le code et de brèves descriptions textuelles. Ces descriptions sont ensuite converties en embeddings et sauvegardées avec les métadonnées dans une base de connaissances locale ou un stockage vectoriel. Quand un nouveau scénario manuel arrive, le système passe par plusieurs étapes :

• identifie l'action et le résultat attendu pour chaque étape ;
• construit plusieurs variantes de requête sémantique pour trouver des étapes similaires ;
• demande au LLM de décrire brièvement le test entier pour trouver un test automatisé similaire par sens ;
• remplace automatiquement les exemples trouvés dans le prompt au lieu du few-shot manuel ;
• vérifie le résultat par une requête répétée au modèle et via PSI à l'intérieur de l'IDE.

Cette approche permet d'obtenir du code qui semble avoir été écrit par quelqu'un de cette équipe, pas un modèle externe sans contexte. L'article souligne séparément que la recherche sémantique est nécessaire non pour la mode du RAG, mais pour un objectif pratique : apporter à la génération exactement ces étapes, utilitaires et modèles qui ont déjà prouvé leur efficacité au sein du projet.

RAG est du few-shot qui trouve les exemples nécessaires de lui-même.

Résultats du Prototype

Selon l'équipe, le prototype interne a déjà montré un effet mesurable. Environ 68% des tests générés étaient à un niveau acceptable et ne nécessitaient que des modifications mineures, et la satisfaction globale des utilisateurs était d'environ 80%. L'outil a montré les meilleurs résultats sur les scénarios d'API simples et similaires, où il est particulièrement important de reproduire rapidement un modèle de code établi sans copier manuellement depuis les tests adjacents.

Les ingénieurs d'automatisation ont également noté une réduction de la charge cognitive : moins de temps sur le travail routinier, plus de temps sur les scénarios complexes et les décisions architecturales. Mais il n'y a pas d'"autopilote" universel ici. Les tests complexes avec un grand nombre d'étapes ont tendance à être simplifiés par le modèle, et pour les scénarios d'interface utilisateur, il a besoin de plus de contexte, comme des informations sur les objets de la page.

Les hallucinations ne sont pas non plus disparues, donc la vérification finale reste obligatoire. En même temps, les auteurs notent qu'ils n'ont pas vu de limitations sérieuses par les langages : des résultats similaires ont été obtenus non seulement en Java, mais aussi en Python et Gherkin. Selon leurs estimations, un tel outil peut faire économiser à un ingénieur d'automatisation plus de la moitié du temps consacré à l'écriture de nouveaux tests routiniers.

Ce Que Cela Signifie

Pour les outils d'IA dans le développement, une étape plus intéressante commence : la valeur se déplace de "générer n'importe quel code" vers "générer du code qui s'intègre immédiatement dans un projet actif". L'histoire de Sber montre que en QA, les équipes gagnantes seront non celles qui connectent simplement LLM à IDE, mais celles qui enveloppent le modèle autour de leur propre base de connaissances, vérifications et règles d'ingénierie.