Ce qu'il faut confier à un agent de test logiciel automatisé
La création de cas de test à partir d'une modification. Il dispose du contexte au moment où le code est écrit, c'est-à-dire quand les détails sont les plus frais.
L'exécution et la réexécution. Mécanique : un humain dans cette boucle n'ajoute que de la latence.
Le tri des échecs évidents. Environnement hors service, dépendance manquante, cible injoignable. Rien de tout cela ne demande de jugement.
L'écriture du cas de reproduction d'un bug qu'il a rencontré. Le cas est écrit pendant que le bug est encore sous la main, plutôt que dans un ticket trois jours plus tard.
Ce qu'il faut garder
Ce que signifie « correct »
Une exigence ambiguë est une décision produit. Un agent retiendra une interprétation plausible et la figera pour de bon.
Ce qui bloque une mise en production
Savoir quels échecs comptent aujourd'hui demande un contexte qui ne figure dans aucun document.
Si la vérification est honnête
Lisez le plan. Un agent à qui l'on demande du vert peut livrer du vert par le chemin le plus court.
La frontière en une phrase
Laissez-le décider comment vérifier, gardez la décision de ce qui doit être vrai. La séparation est nette, elle correspond à ce que chaque partie fait réellement le mieux, et elle résiste au contact d'une vraie équipe.
Le garde-fou qui en vaut la peine
Chaque vérification doit nommer un élément observable précis, et vous devez l'avoir vue échouer au moins une fois. Une vérification vague invite l'agent à la satisfaire plutôt qu'à corriger le produit, et ce mode de défaillance est silencieux par nature.
Ce qui déraille au deuxième mois
Les premières semaines de ce fonctionnement se passent bien, et il y a ensuite un creux prévisible qu'il vaut mieux anticiper.
L'agent a créé une centaine de cas. La plupart sont raisonnables, personne ne les a tous lus, et deux ou trois affirment quelque chose de subtilement faux. Ces deux ou trois-là échouent désormais dès que le produit change correctement, et l'équipe se met à considérer le rouge comme ambigu. À partir de là, c'est la glissade habituelle : on relance, puis on saute, puis on ignore.
L'intervention coûte peu si vous la programmez au lieu de la déclencher en réaction à une crise. Une fois par mois, relisez les assertions de chaque cas ajouté depuis le dernier passage. Pas les étapes, seulement les assertions. À ce volume, cela prend moins d'une heure et cela attrape exactement les cas qui, sinon, éroderaient la confiance dans toute la suite.
La mise en place
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La même mise en place est disponible dans le tableau de bord TestSprite si vous préférez ne rien installer en local. Le reste des commandes du CLI se trouve dans le dépôt CLI.
Connectez le dépôt depuis le tableau de bord et les exécutions démarrent à partir du déploiement que vous produisez déjà, ou ajoutez plutôt une étape à votre propre workflow.
Ce dont TestSprite se charge et ce qui reste de votre ressort
Il se charge du comment : créer des cas à partir d'une modification, les exécuter contre l'application déployée, les relancer et trier les échecs mécaniques. L'installation ajoute la compétence de vérification à votre agent de code, pour que tout cela se passe là où le travail a lieu.
Vous gardez le quoi. Lire le plan, corriger les assertions qui seraient vraies même d'un produit cassé, et décider quels échecs bloquent une mise en production. À volume normal, cela représente une heure par semaine, et c'est par là que votre connaissance du produit entre dans la suite.
L'intérêt de ce partage, c'est que les cas de reproduction sont écrits pendant que le bug est encore sous la main plutôt que trois jours plus tard dans un ticket, et que la couverture de régression se construit à partir de ce qui a réellement dysfonctionné plutôt que d'un exercice de planification.
L'agent peut-il fonctionner sans supervision ?
Pour l'exécution et le tri mécanique, oui. Pour décider de ce qui doit être vrai et de ce qui bloque une mise en production, la supervision n'est pas un coût supplémentaire : c'est tout l'intérêt.
Comment éviter la prolifération des tests ?
Relisez les cas créés comme du code et supprimez les doublons. Le volume sans jugement est le principal mode de défaillance.
Et s'il écrit une vérification qui ne peut pas échouer ?
C'est assez courant pour qu'on le prévoie. Cassez délibérément ce qui est testé et confirmez que la vérification passe au rouge avant de vous y fier.
A-t-il besoin d'un accès au dépôt ?
Il vérifie l'application déployée via son interface. Votre agent de code, lui, a déjà le code.
Comment mesurer si cela fonctionne ?
Les défauts qui passent en production et le délai entre l'échec et le correctif. Le nombre de tests augmente immédiatement et ne veut pas dire grand-chose.
Il décide du comment. Vous décidez du quoi.
Un agent de test logiciel automatisé doit prendre en charge la création, l'exécution et le tri. Gardez la définition de « correct », ce qui bloque une mise en production et l'honnêteté de la vérification. Nommez un élément observable précis dans chaque vérification et confirmez qu'elle peut échouer.