Tests E2E agentiques : méthode, limites et place de TesterArmy

Un test E2E agentique reçoit un objectif en langage naturel et choisit comment parcourir l’interface. Deux exécutions peuvent donc emprunter des chemins différents. Un script Playwright convient mieux quand l’équipe exige une assertion exacte, un résultat reproductible ou un diagnostic au niveau du sélecteur et du réseau.

Ce guide évalue TesterArmy à partir de son site, de sa documentation et de ses tarifs relus le 29 octobre 2026.

Ce qu’un test agentique change vraiment

TesterArmy demande de décrire un parcours comme on l’expliquerait à un collègue. Son agent l’exécute dans un navigateur réel pour le Web ou sur un build pour iOS et Android.[1] Le service prend donc en charge la navigation et l’interprétation de l’interface, là où un script Playwright décrit explicitement les actions et les assertions.

Cette abstraction est utile pour un scénario tel que : « Connecte-toi avec le compte de test, crée un projet, puis vérifie qu’il apparaît dans la liste. » Elle l’est moins pour prouver qu’un bouton possède un attribut précis, qu’une requête contient un en-tête donné ou qu’un calcul renvoie exactement 19,90. Dans ces cas, le script exprime directement le contrat à protéger.

Commencer par un parcours observable

Un bon scénario E2E décrit un risque utilisateur, pas toute l’application. Écrivez d’abord les conditions de départ, les actions, puis le résultat observable :

1. un compte de test existe et ne possède aucun projet ;
2. l’utilisateur se connecte sur l’environnement de préproduction ;
3. il crée un projet nommé avec un identifiant unique ;
4. le projet apparaît dans la liste et sa page s’ouvre ;
5. le scénario supprime les données créées ou les marque pour nettoyage.

Séparez les assertions importantes des indices visuels. La présence du nom dans une liste peut être une assertion. La couleur du bandeau ne prouve pas la création du projet. Si le comportement attendu dépend d’une règle métier, écrivez cette règle dans le scénario au lieu de laisser l’agent la deviner.

Évitez aussi les consignes comme « vérifie que tout fonctionne ». Elles produisent des résultats difficiles à relire et impossibles à comparer. Un scénario court qui échoue à une étape nommée est plus utile qu’un long parcours dont on ne sait pas quelle partie a réellement été contrôlée.

Authentification : prévoir un compte, pas un secret dans le prompt

Le site de TesterArmy présente des comptes de test capables de gérer un identifiant et un mot de passe, Google ou GitHub OAuth, une méthode personnalisée, un lien magique, un code reçu par e-mail ou un OTP par SMS.[1] La documentation de démarrage indique aussi que le service prend en charge l’authentification et la détection de robots à partir de l’URL fournie.[3]

Cela ne dispense pas de concevoir le compte de test. Utilisez un utilisateur dédié, avec les droits minimaux et des données sans valeur réelle. Séparez les comptes de préproduction et de production. Ne copiez jamais un mot de passe, une clé API, un cookie de session ou un code de récupération dans le texte du scénario, dans une capture ou dans un journal de CI.

Pour un script classique, injectez les secrets par le coffre de la CI et préparez l’état authentifié avec un mécanisme contrôlé. Pour un service externe, vérifiez qui peut lire les identifiants, où ils sont stockés, comment ils sont renouvelés et supprimés. TesterArmy affirme chiffrer les identifiants au repos avec AES-256-GCM.[1] Cette déclaration fournisseur ne remplace pas la revue de sécurité de votre organisation.

Environnements et données de test

Un test agentique ne devient pas reproductible parce qu’il tourne dans un navigateur réel. Il lui faut un environnement connu, une version identifiable et des données préparées. TesterArmy affiche des exécutions par environnement, notamment Production, Staging et PR Preview, et peut lancer les mêmes tests manuellement, sur une pull request, depuis la CI, selon un calendrier ou via webhook.[1]

Pour chaque exécution, conservez au minimum :

• l’URL et l’environnement visés ;
• le commit ou le build mobile testé ;
• l’identité logique du compte de test, sans son secret ;
• les données créées et leur stratégie de nettoyage ;
• le déclencheur et l’heure ;
• la version du scénario.

Utilisez des données uniques. Un suffixe dérivé du run évite qu’une donnée résiduelle fasse passer le test suivant. Signalez aussi les échecs de nettoyage.

La production demande encore plus de retenue. Préférez des actions réversibles, des comptes sans facturation et des ressources identifiables. Un test qui envoie un e-mail à un client, crée une vraie commande ou modifie une permission réelle n’est pas un contrôle anodin.

Assertions, faux positifs et captures

Un faux positif survient lorsque le test passe sans avoir prouvé le comportement. Exemple : l’agent crée un projet, revient sur une liste et voit un ancien projet portant le même nom. Le parcours paraît réussi, mais la création du run courant n’a jamais été confirmée.

Réduisez ce risque avec des données uniques et des assertions portant sur plusieurs indices cohérents : nom créé, URL ou identifiant attendu, état affiché et absence d’erreur. Pour une opération critique, ajoutez une vérification par API ou base de test si votre architecture le permet. Un script Playwright peut combiner l’interface avec l’inspection précise d’une réponse réseau ; c’est souvent plus sûr qu’une appréciation visuelle.

Les captures d’écran servent de preuve de contexte, pas d’oracle unique. Prenez-en une au point d’échec, une après une assertion importante et, si nécessaire, avant une action destructive. Masquez les e-mails personnels, jetons, numéros de téléphone et données métier. Une capture « verte » ne prouve pas que le bon utilisateur était connecté ni que la donnée a été persistée.

TesterArmy ou Playwright : qui fait quoi le mieux ?

Besoin	TesterArmy agentique	Script classique, par exemple Playwright
Écrire vite un parcours lisible par le produit	Bien adapté au langage naturel	Demande du code et une revue technique
Explorer une interface qui change souvent	Plus tolérant en principe, à vérifier sur vos écrans	Les sélecteurs doivent être maintenus
Assertion exacte sur texte, attribut, URL ou réseau	Interprétation plus souple	Contrôle explicite et versionné
Reproduire le même chemin à chaque run	Le chemin peut varier	Séquence déterministe si l’environnement l’est
Diagnostiquer une régression fine	Rapport et captures utiles	Trace, logs, sélecteurs et assertions donnent plus de précision
Tester Web, iOS et Android sans écrire trois suites	TesterArmy annonce ces trois plateformes[1]	Playwright vise le Web ; le mobile natif demande un autre outil
Garder tout le test dans le dépôt	Le service indique qu’aucun code de test n’est requis dans le dépôt[1]	Le scénario, les helpers et les assertions restent avec le code

Le partage le plus raisonnable consiste à garder des scripts pour le paiement, les permissions, les calculs, les contrats réseau et les régressions déjà comprises. Utilisez l’agentique pour les parcours transverses, les contrôles sur plusieurs plateformes, la prévalidation d’une PR et l’exploration d’écrans que l’équipe scriptait peu faute de temps.

Ce tableau est une grille de décision, pas le compte rendu d’un duel exécuté.

Intégrer les runs à la CI sans bloquer à l’aveugle

TesterArmy annonce des déclenchements manuels, sur pull request, depuis un job CI, sur calendrier et par webhook. Les résultats peuvent être regroupés avec le statut, la plateforme, l’environnement et le déclencheur.[1] Commencez par un contrôle non bloquant sur quelques PR. Comparez les alertes aux défauts confirmés par l’équipe avant d’en faire une condition de fusion.

Un échec doit montrer l’étape, la capture, l’environnement et la version visée. Tant que l’équipe ne distingue pas un défaut produit d’un problème de données ou de compte, ce test ne doit pas bloquer une livraison.

Gardez une validation humaine pour les nouveaux scénarios et les échecs inhabituels. Une personne doit confirmer que l’assertion correspond à la règle métier, que la capture ne divulgue rien et que le correctif proposé traite la cause. L’agent exécute ; il ne décide pas seul que le produit est acceptable.

Tarifs et capacité de TesterArmy

La page tarifaire relue le 29 octobre 2026 affiche les limites suivantes.[2]

Formule	Prix mensuel affiché	Exécutions incluses	Simultanées	Projets
Free	0 $	5	1	2
Hobby	99 $	250	3	2
Startup	299 $	1 000	10	5

Une exécution compte pour un run, qu’elle parte du chat, de la CLI, d’un déploiement GitHub ou d’une planification, avec une durée maximale de 20 minutes.[2] Le plan gratuit suffit pour vérifier la prise en main, pas pour conclure sur la stabilité d’une suite complète. Avant un abonnement, estimez le nombre de scénarios multiplié par les PR, les plateformes et les relances. Une matrice Web, iOS et Android consomme rapidement plusieurs exécutions pour un seul changement.

Si vous souhaitez examiner le programme partenaire ou les autres outils suivis par le site, consultez la page Offres. Ce lien ne remplace pas l’évaluation technique : commencez par un petit jeu de scénarios et gardez les résultats bruts.

Protocole d’évaluation en cinq étapes

1. Choisissez trois parcours : un nominal, un avec authentification et un échec attendu.
2. Préparez des comptes isolés, des données uniques et un environnement stable.
3. Exécutez chaque scénario plusieurs fois sans modifier le produit. Notez les écarts de chemin, de verdict et de durée.
4. Introduisez volontairement une régression réversible. Vérifiez que le test échoue pour la bonne raison, puis remettez le comportement normal.
5. Faites relire les rapports par une personne qui connaît la règle métier. Classez les alertes en défaut confirmé, faux positif, problème d’environnement ou résultat indéterminé.

Ce protocole évite de confondre une démo réussie avec une capacité de régression. Il aide aussi à décider quels scénarios resteront agentiques et lesquels doivent devenir des scripts explicites.

Conclusion

TesterArmy permet de décrire des parcours en langage naturel et de les exécuter sur le Web, iOS ou Android avec plusieurs modes de déclenchement.[1] La fiabilité obtenue dépend toutefois de la qualité des comptes, des données, des assertions et de la revue humaine autour du service.

Les scripts classiques couvrent mieux les contrats précis, les contrôles réseau, les calculs et les régressions qui doivent suivre exactement le même chemin. Une stratégie solide combine les deux couches, mesure leurs erreurs et refuse de prendre une capture ou un verdict d’agent pour une preuve suffisante.

Sources

[1] TesterArmy : site officiel [2] TesterArmy : tarifs [3] TesterArmy : documentation de démarrage