Le développement avec des agents IA (ADLC) : où se place GUI Test Studio

Ce qu'est le cycle de vie du développement agentique (ADLC)

Pendant des décennies, les logiciels ont été construits selon le cycle de vie du développement logiciel, le SDLC : une équipe planifie, un développeur code, un testeur teste, quelqu'un corrige, quelqu'un livre, et le cycle recommence.Les agents de codage IA n'ont pas remplacé ce cycle.Ils en ont pris en main la boucle interne.

Dans un cycle de vie du développement agentique, l'ADLC, un agent comme Claude Code, Codex, Claude Desktop ou Copilot en mode agent lit la tâche, planifie le changement, écrit le code, exécute les tests qu'il peut, corrige ce qui échoue et ouvre une pull request, souvent plusieurs fois par heure.Les humains fixent l'objectif, relisent ce qui en sort et décident de ce qui est livré.La boucle tourne bien plus vite qu'avant, et la qualité de ce qui est livré dépend de la qualité de ce que l'agent peut vérifier par lui-même.

Les agents sont bons pour les vérifications qui vivent dans le code : tests unitaires, vérifications de types, linters.Ils sont aveugles à la seule chose qu'un utilisateur voit : l'application en marche, sur un vrai écran, à travers sa vraie interface.C'est là que se placent les tests de bout en bout, et là que la plupart des boucles d'agents ont encore un trou.

Où se placent les tests de bout en bout

Un test de bout en bout pilote l'application comme le fait un utilisateur : il l'ouvre, clique et tape tout au long d'un parcours complet, et vérifie ce que l'écran affiche.Pour un agent, c'est la vérité de terrain que le code ne peut pas donner : le bouton a-t-il survécu au nouveau style, le formulaire s'envoie-t-il toujours, le total est-il toujours juste.

Trois choses ont tenu les tests de bout en bout à l'écart des boucles d'agents.Ils étaient lents à écrire, personne n'en écrivait donc pour un changement fait en dix minutes.Ils étaient eux-mêmes du code, ils cassaient donc à chaque élément renommé.Et leurs résultats étaient un mur de journaux dont un agent devait deviner le sens.

GUI Test Studio supprime les trois.Un test est enregistré ou décrit, jamais codé.Il trouve les éléments grâce au GTS Engine + AI, par ce que l'application en dit, ses informations d'accessibilité, et à vue quand elle ne dit rien, si bien qu'un nom de classe modifié ne casse rien.Et chaque exécution se termine par un rapport de confiance écrit en mots simples, qu'un agent lit aussi facilement qu'une personne.La suite de cet article suit la boucle, étape par étape.

Créer : un test de bout en bout depuis une consigne

Installez GUI Test Studio et connectez votre assistant une fois : dans GUI Test Runner-Recorder, Créer un test depuis une consigne affiche Claude Desktop, Claude Code et VS Code, chacun avec un bouton Connecter.Tout autre assistant qui parle le protocole du connecteur est à une commande de distance.

Décrivez ensuite le test.L'agent l'enregistre comme le ferait un testeur : il ouvre l'application ou la page web, clique sur les vrais boutons, tape dans les vrais champs et vérifie ce qu'il voit au fur et à mesure, par le connecteur.Chaque vérification est évaluée sur-le-champ, sur le vrai écran, et refusée quand elle ne passerait pas à l'instant même, si bien que l'agent ne sauvegarde jamais une vérification fausse dès le premier jour.

Ce qui en sort est un test GUI Test Studio ordinaire, avec le même enregistrement, les mêmes étapes et les mêmes vérifications qu'une personne aurait faites, sauvegardé là où vous le choisissez.En chemin, l'agent peut marquer une pause pour réfléchir, annuler une étape qui a mal tourné, grouper des étapes en scénarios, ajouter une attente ou une note, et exécuter le test à la fin pour prouver qu'il réussit.

With GUI Test Studio, create an end-to-end test of the shop at http://localhost:8080:
sign in as [email protected], add the "Desk lamp" to the cart, open the cart,
and verify that the total reads "$49.00" and that the "Checkout" button is shown.

L'agent teste ce que vous lui désignez : l'écran entier, une application, une zone de celle-ci, une page web dans le navigateur de votre choix, ou un téléphone branché.Il n'explore rien sans qu'on le lui demande.Comment connecter chaque assistant et quoi demander est expliqué dans Créer un test depuis une consigne.

Modifier : changer un test par consigne, ou comme une vidéo

Les tests vieillissent avec l'application.Quand l'agent renomme un bouton ou ajoute un champ, il doit aussi mettre à jour le test, pas en enregistrer un nouveau.

Par le connecteur, l'agent liste les étapes d'un test par numéro et les modifie sur place : renommer une étape, changer le texte qu'une vérification attend, donner plus de temps à une vérification, supprimer une étape ou l'ignorer, ajouter une attente, dire ce qui se passe si une vérification échoue.Rien n'est écrit avant que l'agent ait montré les changements et que vous les ayez confirmés, et le test garde tout le reste exactement comme il était.

Une personne fait de même dans GUI Test Studio, sur une chronologie : les étapes sont des blocs que vous déplacez, raccourcissez, renommez et regroupez, avec l'annulation pour tout, et l'image de l'enregistrement sous chacun.Le test de l'agent et le test du testeur sont le même fichier, comme le montre Mettre à jour un test.

Exécuter : en mode headless, en parallèle, dans n'importe quel pipeline CI/CD

gtr-cli exécute n'importe quel test GUI Test Studio sans fenêtre, depuis un script ou un pipeline, et répond comme un pipeline l'attend : un code de sortie, un fichier JUnit pour l'outil de CI, un fichier JSON pour un script, un résumé Markdown pour la pull request.

gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
  --json results\run.json --summary results\summary.md --artifacts results\artifacts ^
  --jira on-failure

Un test web enregistré une fois peut être généré pour d'autres navigateurs et appareils : Chrome, Edge et Firefox, téléphones, tablettes et tailles d'écran, une autre langue, un réseau lent, un niveau de zoom.Les navigateurs et appareils qui n'ont pas besoin de fenêtre s'exécutent côte à côte, chacun dans un processus à lui, et un test de bureau s'exécute dans sa fenêtre après eux.Voir Navigateurs et appareils.

Le journal parle le langage propre à chaque outil : --format teamcity, azure, github ou texte brut.La même commande fonctionne dans TeamCity, Jenkins, GitHub Actions, GitLab, Azure DevOps ou un script à vous, comme le montre pas à pas Exécutez vos tests de bout en bout à chaque build.

Lire : un verdict qu'un agent et une personne comprennent tous deux

Chaque exécution se termine par un rapport de confiance.Pour chaque vérification, il dit, en mots simples, si l'élément a été trouvé, si ce qui a été trouvé correspond à l'enregistrement, et quelle marge il restait : une vérification réussie de justesse est un avertissement avant de devenir un échec.

L'analyse intelligente par IA, le volet IA du GTS Engine + AI, examine une vérification qui a échoué sur les pixels et distingue une vraie régression du bruit : un mot changé, un badge manquant ou une autre couleur sont une régression ; une nuance ou un décalage d'un pixel n'en sont pas.Sa réponse est le verdict final, et elle vient avec une phrase sur laquelle un agent peut agir : ce qui a changé, où, et de combien.

Un agent lit le fichier JSON et le résumé Markdown que l'exécution écrit ; une personne ouvre le rapport, avec les images côte à côte, la vidéo de l'exécution et l'historique du test.Les deux disent la même chose.Le rapport est décrit dans Lire le rapport de confiance.

Corriger : un bug Jira que l'agent peut prendre en charge

Avec --jira on-failure, un test échoué devient de lui-même un ticket Jira : un titre, les étapes numérotées pour reproduire, l'image que le test attendait, l'image qu'il a obtenue et cette image à nouveau avec chaque changement entouré, plus un PDF et les preuves.La même anomalie revue, sur un autre build, navigateur ou appareil, ajoute un commentaire à son ticket ouvert, jamais un doublon.

Ce ticket est écrit pour un développeur, et il se trouve que c'est exactement ce dont un agent de codage a besoin : un chemin reproductible, une attente précise et une image de la différence.Désignez le ticket à l'agent et il a tout pour proposer un correctif.Comment Jira est connecté, depuis le rapport de confiance ou depuis un pipeline, est expliqué dans chaque test de bout en bout en échec devient un bug Jira.

La boucle, bouclée : une boutique de démonstration

Nous avons construit une petite démo pour regarder toute la boucle tourner : une boutique en ligne, son test de bout en bout, un serveur TeamCity, un projet Jira, et un agent de codage IA.Jean est le développeur, Pierre a écrit le test, James s'occupe du backlog, John gère TeamCity.

1. 1

   Un changement casse le paiement

   Jean pousse un nouveau style pour les boutons de paiement.TeamCity exécute le test de bout en bout de la boutique avec gtr-cli, en mode headless, sur chaque navigateur et appareil pour lesquels le test a été généré.

2. 2

   L'exécution dit ce qui a cassé, et où

   Le rapport de confiance trouve le bouton de paiement, mais pas tel qu'il a été enregistré.L'analyse intelligente par IA confirme une vraie régression : le bouton a perdu son libellé. gtr-cli crée un ticket Jira avec les étapes, les images attendue et obtenue et le changement entouré, et le journal de build de TeamCity nomme le ticket.

3. 3

   L'agent le corrige

   L'agent prend en charge le ticket, lit les étapes et les images, trouve la règle de style qui a masqué le libellé, et propose un correctif sur sa propre branche.

4. 4

   Le test prouve le correctif

   TeamCity exécute le même test sur la branche.Il réussit.L'exécution réussie est ajoutée au ticket Jira, et James le ferme une fois qu'une personne a relu et fusionné le changement.Personne n'a écrit à la main un test, un rapport d'anomalie ou une reproduction.

Le côté humain

Un ADLC, ce n'est pas seulement des agents.Les personnes qui le pilotent doivent pouvoir faire confiance à ce que les agents vérifient, et le vérifier elles-mêmes quand cela compte.GUI Test Studio a été construit pour cela : le même test sert à l'agent et à la personne.

Sur site ou dans le cloud, c'est votre choix, vérification par vérification.Un agent qui crée des tests, un testeur qui les lit et un pipeline qui les exécute regardent le même fichier, dans les mêmes mots.

Par où commencer