Tests agentiques : du rapport de bogue au rapport de test en 10 minutes

Et si le cycle allant d'un rapport de bogue à un rapport de test complet avec des cas de test prenait 10 minutes plutôt que plusieurs heures? Nous avons essayé cette approche sur Aidbox et ça a fonctionné.

Dans un billet précédent, nous avons décrit le codage agentique et la façon dont les LLM aident à créer des applications sur FHIR. Or, le codage ne représente qu'une partie du cycle de vie d'un produit. Nous sommes allés plus loin et avons commencé à intégrer des agents LLM dans les processus de test et de soutien d'Aidbox.

Notre première étape a été BugBot. Il examine les demandes de tirage et détecte les problèmes potentiels dans le code. Il évalue le code de manière satisfaisante et nous en sommes contents. Cependant, BugBot examine une demande de tirage ou un commit de façon isolée, à travers les yeux d'un programmeur. Il ne voit pas la situation dans son ensemble. Il peut manquer le contexte d'une tâche, la conformité aux spécifications et le comportement de bout en bout.

Cela a soulevé une question plus large : les LLM peuvent-ils aider non seulement à l'écriture de code, mais aussi au soutien et à l'évolution du produit dans son ensemble?

Pourquoi tester un produit complexe est si pénible

Aidbox est un produit de grande envergure, doté d'une base de code étendue et d'un domaine FHIR complexe qui comprend des API de recherche, le traitement de la validation et de la Terminology, la sécurité et les considérations de performance. Parfois, reproduire un bogue ou répondre à une demande d'un client demande un temps considérable. Par exemple :

• Valider par rapport à un ensemble précis de profils et d'IG
• Exécuter une recherche FHIR sur des données particulières
• Tester l'intégration avec un service externe

Tous les bogues ou toutes les demandes n'exigent pas une reproduction aussi détaillée, mais beaucoup trop de tâches prennent un temps déraisonnable.

Après la mise en œuvre d'une fonctionnalité ou la correction d'un bogue, les tests doivent vérifier non seulement l'exactitude du code, mais aussi la conformité à la spécification FHIR, la précision de la documentation, le comportement dans les cas limites et la sécurité (XSS, injection SQL, etc.). Les tests unitaires aident à prévenir les régressions, mais ils ne remplacent pas une validation complète. Les tests de bout en bout restent nécessaires et chronophages.

Notre approche : les tests agentiques

Nous avons développé un robot GitHub qui se charge de l'évaluation des tâches et des tests. Nous l'appelons [Agentic](/blog/agents-are-not-humans) Testing.

Le robot a deux responsabilités principales :

• Évaluer les demandes entrantes : reproduire et confirmer les bogues ou les demandes des clients, élaborer un plan de test, analyser le code et recommander des correctifs.
• Vérifier les tâches : analyser les demandes de tirage et les commits en contexte, générer des tests de cas limites, les exécuter et vérifier l'exactitude de la documentation.

Si une tâche arrive dans la Inbox sans commits associés, le robot tente de reproduire le problème par lui-même. S'agit-il vraiment d'un bogue ou d'un comportement attendu? Il croise la documentation d'Aidbox et la spécification FHIR.

Si la tâche a déjà une demande de tirage associée et se trouve en état QA, le robot analyse les modifications de code, génère des tests de cas limites et les exécute.

Dans les deux cas, les tests sont effectués sous forme de tests d'API en boîte noire :

• Le robot démarre une instance Aidbox en fonction de la tâche ou des modifications de code.
• Il exécute les requêtes de façon séquentielle et compare les résultats aux résultats attendus.
• Si la tâche spécifie différentes versions de FHIR ou des ensembles configurables de configurations et de profils, le robot démarre plusieurs instances Aidbox et exécute les tests sur chacune d'elles.
• Il génère un rapport de test.

Pendant la reproduction d'une tâche, le robot analyse également le code et suggère où et pourquoi le problème pourrait survenir. Pour le développeur, cela signifie qu'au moment où il commence à corriger le problème, il dispose déjà des étapes de reproduction et d'une indication approximative de la cause profonde.

La compétence représente environ 500 lignes de markdown. Elle ne contient aucune logique applicative, seulement des instructions. Ce sont les mêmes instructions que vous rédigeriez dans un wiki interne pour un nouveau membre de l'équipe, notamment comment configurer l'environnement, localiser le code, exécuter les tests et formater le rapport. Claude Code s'occupe du reste : raisonner sur les cas limites, composer les requêtes et interpréter les réponses.

Comment le robot détermine ce qui constitue un bogue

En travaillant avec le robot, nous avons été confrontés à une question fondamentale : qu'est-ce qui constitue un bogue?

Exemple : une demande est arrivée indiquant que la recherche FHIR dans Aidbox ne fonctionnait pas correctement. Le robot a reproduit et confirmé le problème. Cependant, une analyse plus approfondie a montré qu'Aidbox fonctionnait en réalité correctement, en pleine conformité avec la spécification FHIR.

Le robot utilise la base de code d'Aidbox, sa documentation et la spécification FHIR comme contexte. Au moment de prendre une décision, il vérifie d'abord par rapport à la documentation et à la spécification. Nous avons établi une règle : un bogue est un comportement d'Aidbox qui dévie de la spécification FHIR et qui n'est pas reflété dans la documentation d'Aidbox.

Nous avons également ajouté les lignes directrices de l'OWASP au contexte du robot afin qu'il puisse identifier les vulnérabilités potentielles et les problèmes de sécurité.

Limites des LLM et hallucinations

Les LLM ne doivent pas être acceptés à la lettre. Les hallucinations surviennent. Le robot peut mal comprendre une tâche et commencer à tester quelque chose de complètement différent de ce que l'auteur avait prévu. Surtout si la tâche est mal formulée ou contient des erreurs.

Pour y remédier, nous avons ajouté la possibilité de relancer les tests avec des précisions. Il suffit d'« appeler » le robot dans un commentaire de tâche à l'aide de la commande \qa et de préciser ce qui doit être vérifié. Parfois, la demande entrante manque de détails : la version de FHIR n'est pas précisée, la version d'Aidbox est absente, ou le comportement doit être vérifié dans plusieurs configurations. Tout cela peut être précisé, et le robot démarrera les installations appropriées, créera les ressources nécessaires, chargera les versions requises des IG, exécutera les tests et produira un rapport consolidé.

Pas mieux, mais davantage et plus rapidement

Le robot ne fait rien d'extraordinaire par rapport à un ingénieur QA. Il ne le fait pas mieux, il le fait davantage et plus rapidement.

Un exemple récent illustre bien cela. Dans la version de janvier d'Aidbox, nous avons trouvé un bogue lié à la cardinalité minimale du profil FHIR. Un champ obligatoire était déterminé par la condition element.min == 1, alors que les profils peuvent spécifier un min égal à 2, 3 et ainsi de suite. La correction consistait littéralement en un changement d'un seul caractère : remplacer min == 0 par min >= 1.

Un développeur peut jeter un œil au diff et conclure que la correction est exacte. Mais nous souhaitons tout de même procéder à une vérification approfondie. Les tests unitaires couvrent les cas principaux, mais nous voulons valider de bout en bout avec diverses combinaisons de valeurs minimales et maximales.

Le faire manuellement n'est pas difficile, simplement lent : créer plusieurs profils et préparer différents ensembles de données de test. Cela prend beaucoup de temps et des erreurs humaines sont toujours possibles.

Nous avons demandé au robot. Il a compris la tâche, généré des cas avec toutes les combinaisons possibles et tout testé en 5 minutes.

Voici une partie du rapport du robot.

Cas de test

Groupe 1 : Création de profil et vérification du FHIRSchema

Groupe 2 : Validation avec le profil min:2

Groupe 3 : Régression, profil min:1

Groupe 4 : Profil avec min:3, max:5

PASS — La correction fonctionne correctement.

• element.min: 2 rend correctement le champ obligatoire et vérifie la cardinalité minimale

• element.min: 1 continue de fonctionner comme avant (aucune régression détectée)

• element.min: 3, max: 5 vérifie correctement la cardinalité minimale et maximale

• Les messages d'erreur de validation sont informatifs et contiennent les valeurs min/max correctes

La possibilité de tester ainsi une fonctionnalité avant la mise en production simplifie considérablement l'ensemble du processus de développement. Nous ne faisons pas encore confiance au robot aveuglément et vérifions toujours manuellement. Cependant, nous le faisons de manière bien plus efficace, en couvrant également des cas limites supplémentaires ainsi que des vérifications de performance et de sécurité.

Validation de la documentation

Le robot croise constamment la documentation d'Aidbox. Lorsqu'il rencontre des ambiguïtés ou des erreurs évidentes dans la documentation, il crée automatiquement une tâche indiquant ce qui doit être corrigé et à quel endroit. Cela aide grandement à maintenir la précision de la documentation lors des modifications, ainsi que lors du développement de nouvelles fonctionnalités. Par exemple, lors de la mise en œuvre de la fonctionnalité External Secrets, le robot a à plusieurs reprises trouvé des écarts entre la documentation et la mise en œuvre et nous a aidés à rédiger une bonne documentation.

Comment nous avons vidé notre carnet de commandes grâce au robot

Un avantage inattendu est apparu : avec l'aide du robot, nous avons vidé notre immense carnet de commandes. Nous avons soumis environ 30 tâches pour évaluation et reproduction. Environ la moitié d'entre elles — des tâches qui étaient restées inactives depuis longtemps — s'avéraient déjà avoir été corrigées en même temps que d'autres modifications. Les tâches restantes ont confirmé leur pertinence. Certaines ont été priorisées pour des correctifs rapides, et nous les avons mises en œuvre. Le robot est utile non seulement pour les tests quotidiens, mais aussi pour la priorisation et le toilettage du carnet de commandes.

Au cours des dernières semaines, le robot a testé plus d'une centaine de tâches lors d'environ 250 exécutions. Un cycle de test complet prend de 5 à 10 minutes, et jusqu'à 20 minutes pour les tâches complexes. Tout cela fonctionne sur une machine virtuelle qui coûte 8 $ par mois. Nous sommes impressionnés par les résultats. Des tâches qui prenaient auparavant une ou deux heures à un ingénieur QA sont maintenant accomplies en quelques minutes.

Le robot ne remplace pas un ingénieur QA. Il arrive qu'il comprenne mal une tâche et qu'une vérification humaine soit nécessaire. Mais il prend en charge la routine : reproduction, génération de cas de test, exécution de combinaisons, vérifications de la documentation. Cela libère du temps à l'équipe pour ce qui nécessite véritablement une attention humaine.

Avez-vous déjà intégré des LLM dans vos flux de travail de développement ou de maintenance? Nous serions ravis d'entendre parler de votre expérience. Rejoignez notre clavardage Zulip pour poursuivre la discussion.

Marat Surmashev, VP of Engineering