Tests agentiques : le rôle des agents dans la pile de tests E2E

• L’équipe Engineering de Slack a mené plus de 200 workflows agentiques pour vérifier si les tests E2E (End-to-End) fondés sur des agents pouvaient remplacer les tests déterministes traditionnels
• Là où les tests E2E classiques imposent un parcours UI prédéfini, les agents vérifient l’atteinte d’un objectif (goal) et peuvent parvenir au même résultat par des chemins différents
• Une exécution agentique coûte 15 à 30 $ par run et prend plus de 10 minutes, mais présente des cas d’usage clairs en matière de fiabilité
• L’approche Playwright MCP a enregistré un taux d’échec plus faible et une consommation de tokens moindre que les approches CLI ou génération de code, ce qui montre que la stabilité de l’environnement d’exécution est déterminante
• Les tests agentiques ne remplacent pas les tests existants : ils s’ajoutent au sommet de la pyramide de tests comme couche d’exploration, de débogage et de validation de comportements complexes

---

Du parcours à l’objectif (From Journeys to Goals)

• Les tests E2E traditionnels valident un parcours (journey) précis dans l’UI → clic → clic → saisie → assertion (assert)
• Les tests fondés sur des agents valident la capacité à atteindre un objectif exprimé par une instruction telle que « envoyer un message dans un thread » → objectif → adaptation de l’agent → validation du résultat
  • Différence clé : « le test impose un parcours, l’agent valide un objectif »
• Le workflow global (connexion → recherche → résultat → réinitialisation) restait identique, mais l’ordre réel des actions variait à chaque exécution
  • différentes méthodes de saisie (cliquer sur une suggestion de recherche vs appuyer sur Entrée)
  • différents schémas de navigation (relancer la recherche vs réutiliser l’état existant)
  • étapes ajoutées ou omises (clics supplémentaires, snapshots, actions intermédiaires)
• Cette flexibilité s’accompagne de compromis en termes de fiabilité, coût et temps d’exécution

• Problématique

  • La question centrale était de savoir si une approche coûtant 15 à 30 $ et plus de 10 minutes par run pouvait s’intégrer dans un workflow de test moderne
  • Après plus de 200 exécutions, Slack a confirmé qu’il s’agit d’une approche fondamentalement différente des tests traditionnels, avec une forte fiabilité et des usages bien identifiés
  • Les progrès des grands modèles de langage (LLM), capables d’écrire du code, de déboguer des échecs et de manipuler directement l’UI, ont rendu possible ce nouveau modèle d’exécution

Montage expérimental (Our Experiment)

• Plus de 200 exécutions automatisées ont été réalisées dans plusieurs configurations afin de mesurer la fiabilité, la vitesse d’exécution et le coût

• Modèles d’exécution (trois approches)

  • Agent + Playwright MCP : l’agent interagit avec le navigateur via des actions prédéfinies (cliquer un élément, saisir du texte, lire l’état du DOM, etc.) et conserve un contexte persistant (snapshots DOM, logs)
  • Agent + Playwright CLI : l’agent exécute des commandes Playwright CLI dans le shell, traite une étape à la fois, puis décide de l’action suivante à partir de l’état UI mis à jour
  • Generated Playwright Tests : un agent IA génère du code Playwright déterministe à partir d’une description en langage naturel, l’exécute comme test E2E standard, puis l’améliore de façon itérative jusqu’à réussite

• Environnement expérimental

  • Modèles des agents MCP et CLI : Claude Sonnet 4.5
  • Modèle pour les tests Playwright générés : Claude Opus 4.6
  • Exécution : Claude Code non interactif (claude -p)
  • Outils navigateur : Playwright MCP, Playwright CLI
  • Environnement : Slack Dev API MCP, avec l’ensemble des expériences menées dans un workspace de test utilisant des données non production

• Flows de test (deux niveaux de complexité)

  • Thread Reply (simple) : workflow d’environ 15 à 20 étapes incluant création d’un canal, envoi d’un message, réponse dans un thread et validation de l’état du thread
  • Search Discovery (complexité intermédiaire) : workflow d’environ 25 à 30 étapes incluant saisie d’une requête, exploration des résultats, navigation entre vues (recherche, canal, thread) et validation du résultat attendu

• Formats d’entrée

  • Langage naturel (NL) : instructions lisibles par un humain décrivant le workflow et le résultat attendu sous forme de liste d’étapes
  • YAML structuré : même workflow exprimé dans un format structuré avec étapes, actions, cibles et résultats attendus
    • La différence ne tient pas au niveau de détail mais au mode de représentation : en langage naturel, l’agent doit interpréter et faire le mapping, tandis que YAML définit ce mapping de manière plus explicite

• Matrice expérimentale

  • Chaque configuration a été exécutée 20 fois, soit 5 expériences au total (MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, génération de tests-NL), appliquées aux deux flows Thread Reply et Search Discovery

Observations (What We Observed)

• Résumé des résultats

  • Agent (Playwright MCP) : taux d’échec de 0 % (thread reply) / environ 12 % (search discovery), moyenne de 5 à 8 minutes
  • Agent (Playwright CLI) : taux d’échec d’environ 12 % / environ 20 %, moyenne de 9 à 11 minutes
  • Generated Playwright Tests : taux d’échec d’environ 8 % / environ 48 %, moyenne de 3 minutes

• Fiabilité (Reliability)

  • C’est lorsque la complexité du flow augmente que les différences de fiabilité deviennent les plus visibles
  • Playwright MCP est le plus stable : quasi 0 % d’échec sur les scénarios simples, et 0 à 12 % même sur des flows complexes
  • Playwright CLI échoue davantage (environ 12 à 20 %), avec des problèmes venant surtout de l’exécution elle-même — gestion de l’authentification, timing de navigation, instabilité de session — plutôt que du raisonnement du modèle
  • Les tests générés donnaient de bons résultats sur les flows simples (environ 8 %), mais se dégradaient fortement sur les workflows complexes (environ 48 %)
    • Ils n’étaient pas totalement erronés : ils progressaient généralement jusqu’à 70 à 80 % du flow avant d’échouer sur la dernière interaction ou assertion
    • Les causes principales étaient la variabilité de l’état UI et un mauvais alignement des abstractions : génération depuis un flow en langage naturel peu spécifié et réutilisation d’abstractions de page object existantes, ce qui nuisait au ciblage précis des éléments
  • Plus la complexité augmente, plus l’écart de fiabilité se creuse : un modèle d’exécution nativement agentique comme MCP est plus robuste
    • MCP conserve une vue stable et temps réel de l’application, alors que CLI reconstruit l’état à partir de snapshots à chaque étape, ce qui accumule les incohérences sur les flows longs
    • MCP semble aussi réutiliser les interactions réussies des étapes précédentes au sein d’une même session, tandis que CLI donne l’impression de repartir de zéro à chaque étape (sans mesure explicite)

• Vitesse (Speed)

  • Les tests générés sont systématiquement les plus rapides (environ 3 minutes), contre environ 5 à 8 minutes pour MCP et 9 à 11 minutes pour CLI
  • Ce chiffre inclut la génération puis l’exécution du test, chaque test étant généré une fois puis exécuté 5 fois pour établir la moyenne
    • En exécution pure, c’est bien plus rapide : environ 32 secondes pour thread reply, environ 45 secondes pour search discovery
    • Dans un environnement CI avec exécutions répétées, le coût ponctuel de génération devient négligeable, ce qui permet aux tests déterministes de passer efficacement à l’échelle
  • Les workflows agentiques, eux, paient ce coût à chaque exécution : observation de l’état UI, raisonnement sur l’action suivante, exécution de l’action et validation du résultat

• Adaptabilité (Adaptability)

  • Seulement environ 20 % des exécutions ont suivi exactement le même ordre d’actions ; la plupart ont trouvé des chemins UI différents mais valides vers le même objectif
    • ouvrir des menus dans un ordre différent
    • sélectionner des éléments UI légèrement différents
    • emprunter des flux de navigation alternatifs
  • Pour mesurer cela, Slack a comparé les action signatures entre exécutions, c’est-à-dire la liste ordonnée des appels d’outils et actions UI réalisés par l’agent
    • Avant comparaison, normalisation des paramètres, des actions d’attente/snapshot et des variantes d’outils équivalentes (fill vs type) afin de ne conserver que les différences significatives
  • Même quand le résultat final était correct, l’ordre des actions différait le plus souvent : le test E2E traditionnel impose un parcours déterministe unique, tandis que l’agent explore l’interface pour vérifier l’atteinte d’un état cible

• Coût et origine du coût (Cost and Where It Comes From)

  • Une exécution agentique coûte généralement 15 à 30 $ par run, bien davantage qu’un test traditionnel
  • Analyse de la consommation de tokens sur le même flow search discovery
    • MCP (Opus 4.6) : environ 3,8 M, MCP (Sonnet 4.5) : environ 3,5 M, MCP (Haiku 4.5) : environ 5,7 M
    • CLI (Opus 4.6) : environ 6 M, Code Gen (Opus 4.6) : environ 7 M
  • La manière d’exécuter compte plus que le modèle utilisé : Haiku consommait plus de tokens, mais toutes les approches MCP en utilisaient moins que CLI ou Code Gen
  • Analyse du mode d’exécution de session dans Claude Code : l’API sous-jacente est sans état (stateless), donc l’intégralité du prompt système et de l’historique de conversation est renvoyée à chaque tour
    • Le coût dépend moins de la sortie du modèle que de la vitesse d’accumulation du contexte et du nombre de tours
  • Nombre de tours : MCP (Opus/Sonnet) environ 40, MCP (Haiku) environ 60, CLI (Opus) environ 85, Code Gen (Opus) environ 70
    • En CLI, chaque interaction navigateur est découpée en plusieurs commandes — action, attente, snapshot, lecture, recherche d’élément, etc. — pour une moyenne d’environ 85 tours
    • MCP combine interaction et retour d’état dans un seul aller-retour
    • Chaque tour supplémentaire réintroduit le coût du prompt système complet et la charge de retransmission du contexte précédent
  • Ce qui remplit le contexte
    • MCP et CLI : les snapshots navigateur sont la charge utile principale — les snapshots d’arbre d’accessibilité (accessibility tree) renvoyés par Playwright MCP s’accumulent sur tous les tours suivants
    • Code Gen : à chaque retry, la sortie du runner de test accumule l’intégralité des traces d’erreur, des échecs d’assertion et de l’état du DOM
  • L’essentiel du coût vient de la retransmission de contenu déjà vu, alors que les nouvelles informations par tour sont minimes
  • L’usage de tokens n’a pas encore été optimisé ; les pistes évoquées sont le prompt caching, la compaction du contexte et la réduction de la fréquence des snapshots
  • À cause du coût, cette approche est aujourd’hui plus adaptée au débogage ciblé et aux tests exploratoires qu’aux exécutions CI à haute fréquence, même si cela pourra évoluer avec les modèles et les outils

• Importance de l’infrastructure (MCP vs CLI)

  • La fiabilité dépend fortement non seulement du modèle, mais aussi de l’environnement d’exécution : MCP affiche 0 à 12 % d’échec, CLI 12 à 20 %
  • La plupart des échecs CLI viennent de problèmes d’authentification ou de navigation (erreurs de login, timeouts, instabilité de session), donc de la couche d’exécution plutôt que du raisonnement de l’agent
  • Playwright MCP fournit des primitives navigateur structurées et une intégration étroite avec le workflow d’appel d’outils de l’agent, alors que CLI ajoute une couche supplémentaire entre l’agent et le navigateur
  • Différence aussi côté parallélisation : MCP se prête facilement à l’exécution concurrente, alors que CLI s’y prête mal et reste majoritairement séquentiel
  • Fiabilité, vitesse et coût dépendent donc autant de la stabilité et de la conception de l’environnement d’exécution que du modèle

• Limites des capacités d’exécution (Execution Capability Boundaries)

  • Cette expérimentation s’est concentrée sur des workflows UI en session unique
  • Les flows inter-workspaces ou ceux qui ouvrent plusieurs fenêtres de navigateur posent d’autres difficultés où le choix du modèle d’exécution devient aussi important que l’agent lui-même
    • MCP peut rencontrer des problèmes de coût avec des boucles d’observation plus longues dans les flows étendus
    • CLI peut voir sa complexité de coordination et sa consommation de tokens augmenter avec la gestion de multiples sessions navigateur
  • Les deux approches peuvent théoriquement les prendre en charge, mais avec des compromis différents ; cela n’a pas été exploré ici et reste un point important pour les équipes d’évaluation

Où placer les tests agentiques dans la pyramide de tests

• Les tests agentiques ne remplacent pas les approches existantes ; ils y ajoutent une nouvelle capacité

• Tests E2E déterministes

  • Ils restent les mieux adaptés aux vérifications de régression rapides et répétables en CI
    • écrits par des humains ou générés par IA
    • rapides et répétables, adaptés à la CI
    • faible coût opérationnel
    • imposent un parcours UI précis

• Tests agentiques

  • Ils partent d’un objectif, et non de l’exécution d’un script figé : observer l’UI, raisonner sur l’état actuel, décider comment atteindre le résultat souhaité
    • explorer des comportements UI complexes
    • déboguer des workflows instables (flaky)
    • reproduire des bugs de production

• Une pyramide de tests incluant une couche agentique

  • D’un point de vue système, les tests agentiques valident, comme l’E2E, de vrais workflows utilisateur via l’UI ; la différence porte sur la manière d’exécuter le workflow
  • La stratégie de test la plus efficace à l’avenir combinera probablement les deux : les tests déterministes comme base stable de la CI, et les tests agentiques au sommet de la pyramide pour l’exploration, le débogage et la validation de comportements complexes