Comment exécuter des agents d’assurance qualité sur chaque demande d’intégration avec QA.tech (sans écrire un seul script de test)
Si votre équipe a adopté des outils de codage basés sur l'IA, vous connaissez déjà les calculs quelque peu inconfortables. Les équipes d'ingénierie qui livraient quelques demandes de tirage par semaine en livrent désormais cinquante, cent, parfois davantage – une grande partie étant rédigée par des agents de codage, examinée par des agents de revue de code et fusionnée à un rythme pour lequel aucun processus d'assurance qualité manuel n'a été conçu. Une équipe avec laquelle nous avons récemment échangé venait d'achever ses cinquante premières demandes de tirage entièrement rédigées par des agents et nous a posé la question évidente : qu'est-ce qui vérifie tout cela ?
La réponse traditionnelle – écrire davantage de scripts de test – ne résiste pas à un tel volume de demandes de tirage. Les scripts prennent plus de temps à créer et à maintenir que le code généré par les agents n'en prend à être produit ; la suite de tests prend donc du retard dès le premier jour et ne le rattrape jamais.
Ce guide présente l'alternative que nous avons mise au point chez QA.tech : connecter nos agents d'assurance qualité à votre dépôt afin que chaque demande de tirage déclenche des tests fondés sur des objectifs, qui se déduisent eux-mêmes des modifications apportées. Aucun code de test, aucun sélecteur, aucune file de maintenance. Voici comment la configurer et à quoi vous attendre à chaque étape.
Étape 1 : laissez d'abord l'agent découvrir votre application
Avant que l'intégration aux demandes de tirage puisse faire quoi que ce soit d'utile, l'agent doit connaître votre produit. Lorsque vous connectez QA.tech à votre environnement de préproduction ou de bac à sable, il effectue une exploration initiale : il parcourt l'application comme le ferait une nouvelle recrue méticuleuse, en suivant chaque parcours et chaque action qu'il peut trouver, puis rassemble ces informations dans un graphe de connaissances décrivant la structure de votre produit.
Deux remarques pratiques issues de centaines d'intégrations. Premièrement, si votre application est protégée par une connexion, configurez le parcours de connexion comme cas de test préalable – l'agent l'exécute d'abord, puis explore tout ce qui se trouve derrière. Deuxièmement, vous contrôlez la profondeur de l'exploration. Une exploration superficielle (un ou deux niveaux dans chaque parcours utilisateur) est rapide et généralement suffisante pour commencer ; vous pouvez l'approfondir pour les parcours les plus importants plutôt que de tout cartographier de manière exhaustive dès le départ.
Cette étape est la raison même pour laquelle l'intégration aux demandes de tirage fonctionne. Comme l'agent connaît les moindres recoins de l'application, il peut raisonner sur les éléments qu'une modification donnée pourrait affecter – c'est exactement le jugement qu'exerce un bon ingénieur QA lorsqu'il décide des vérifications à effectuer avant une mise en production.
Étape 2 : connectez le dépôt
L'intégration GitHub ne prend que quelques minutes : autorisez l'application, sélectionnez les dépôts et choisissez le moment où les tests doivent être déclenchés – généralement à la création ou à la mise à jour d'une demande de tirage. Les demandes de fusion GitLab suivent le même principe. À partir de ce moment, les tests font partie de votre pipeline au lieu d'être une étape qui intervient après celui-ci.
ne prend que quelques minutes : autorisez l'application, sélectionnez les dépôts et choisissez le moment où les tests doivent être déclenchés – généralement à la création ou à la mise à jour d'une demande de tirage. Les demandes de fusion GitLab suivent le même principe. À partir de ce moment, les tests font partie de votre pipeline au lieu d'être une étape qui intervient après celui-ci.Étape 3 : ouvrez une demande de tirage et observez ce qui se passe
Lorsqu'une demande de tirage est ouverte, l'agent lit ce qui a été ajouté et modifié, compare ces éléments à son graphe de connaissances et génère les cas de test justifiés par la modification – généralement quatre ou cinq pour une demande de tirage courante, davantage pour les modifications qui touchent des parcours partagés. Il les exécute ensuite immédiatement dans un navigateur réel, en interagissant visuellement avec la version mise à jour, exactement comme le ferait un utilisateur.
C'est la partie qui surprend les équipes habituées aux suites de scripts déclenchées par l'intégration continue : personne n'a rédigé ces cas de test. Ils ont été déduits de la modification elle-même, dans le contexte de tout ce que l'agent sait déjà de votre produit. Vous ajoutez un nouveau filtre à votre tableau de bord ? L'agent teste le filtre ainsi que les parcours du tableau de bord dans lesquels il s'insère. Personne n'a eu besoin de penser à ajouter cette couverture.
Étape 4 : consultez les résultats là où vos ingénieurs travaillent déjà
La réussite ou l'échec apparaît directement dans la demande de tirage. Pour chaque exécution, l'agent produit un rapport d'évaluation : l'objectif, le résultat attendu, ce qui s'est réellement passé, une vidéo de l'exécution, des captures d'écran étape par étape, ainsi que les journaux de la console et du réseau. Un échec ne se résume pas à une croix rouge à décortiquer – il s'accompagne d'une explication écrite de ce que l'agent s'attendait à voir et de ce qu'il a vu à la place.
Comme l'agent teste via l'interface, il signale les échecs au niveau du produit – il vous indiquera que le code de réduction ne s'applique plus lors du paiement, preuves à l'appui. Ce contexte au niveau du produit est exactement ce dont vos ingénieurs – ou vos agents de codage – ont besoin pour localiser et corriger la cause. Les équipes qui exécutent des boucles de développement agentiques renvoient directement nos rapports d'évaluation à leurs agents de codage comme contexte de l'échec à corriger – et grâce à l'intégration MCP, ces agents de codage peuvent eux-mêmes déclencher des exécutions de tests pendant qu'ils travaillent.
Étape 5 : superposez la régression aux tests de PR
Les tests déclenchés par une PR vérifient la modification. Les plans de régression vérifient tout le reste. Dans QA.tech, vous regroupez les cas de test en plans — une suite de tests de fumée pour chaque déploiement, une régression complète avant les versions majeures — et vous les exécutez selon la cadence qui convient à votre processus de mise en production.
Comme les tests s’exécutent en parallèle, le temps réel nécessaire ne représente qu’une fraction de ce que la même couverture coûterait manuellement. Un récent plan de régression complète que nous avons exécuté couvrait un volume de tests qui aurait occupé un testeur manuel pendant un ou deux jours ; il s’est terminé en environ vingt minutes. C’est cette différence qui transforme « exécuter la régression complète à chaque version » en une véritable politique plutôt qu’en une simple aspiration.
Étape 6 : demandez à l’agent où votre couverture est insuffisante
Comme le graphe de connaissances cartographie chaque parcours découvert lors de l’exploration, la plateforme connaît la différence entre ce que contient votre produit et ce que vos tests couvrent. Vous pouvez poser directement la question dans le chat : « Quels sont les parcours à plus forte valeur que nous ne couvrons pas actuellement ? » L’agent répond à partir de sa carte de votre produit et peut générer immédiatement les tests manquants.
Cela inverse la dynamique habituelle de la couverture. Au lieu que la couverture corresponde à tout ce qui s’est accumulé au fil des années de rédaction de tests dictée par les tickets, elle devient une question que vous pouvez poser et traiter le même après-midi.
À quoi cela ressemble au bout d’un mois
Le schéma que nous observons dans les équipes est constant. La première semaine implique quelques échanges — l’agent pose des questions, a parfois besoin de contexte sur les particularités de votre produit, et vous corrigez sa compréhension. À partir de la deuxième semaine, les questions se font rares. À la troisième semaine, elles ont presque cessé, car le graphe de connaissances a assimilé le fonctionnement de votre produit. À partir de là, les tests s’exécutent au rythme de vos demandes de fusion, et les personnes impliquées examinent les résultats au lieu de maintenir des scripts. Si vous souhaitez connaître la séquence complète du déploiement — de la preuve de concept au retrait de vos suites historiques — nous l’avons publiée sous forme de guide pratique, Adopter les tests agentiques : le plan directeur.
Pour les équipes qui sont passées au code écrit par des agents, cela boucle le processus qui était incomplet : la génération du code, la revue du code et la vérification s’exécutent toutes à la vitesse des machines, tandis que vos ingénieurs dirigent le système au lieu de l’alimenter.
FAQ
Combien de cas de test QA.tech génère-t-il par demande de fusion ?
Une PR standard produit généralement quatre à cinq cas de test, dérivés des modifications effectuées. Les modifications plus importantes qui touchent des parcours partagés en génèrent davantage.
Les tests de PR nécessitent-ils des cas de test existants ?
Non. L’agent génère les cas de test à partir de la modification et de sa connaissance de votre application. Les équipes qui partent de zéro en matière de couverture de tests peuvent commencer au niveau des PR et élaborer progressivement des plans de régression.
Que se passe-t-il lorsque l’interface utilisateur change dans une demande de fusion ?
L’agent s’appuie sur les objectifs et la compréhension visuelle plutôt que sur des sélecteurs. Il exécute donc le test sur la nouvelle interface et ne signale un échec que lorsque le comportement lui-même est incorrect.
Quelles configurations CI/CD l’intégration des PR de QA.tech prend-elle en charge ?
Les demandes de fusion GitHub et GitLab constituent les principaux points d’intégration, les résultats étant renvoyés dans la PR sous forme de vérification.
Découvrez ce que les agents QA génèrent pour votre prochaine demande de fusion — connectez un dépôt à QA.tech et exécutez le premier test en quelques minutes.
