Ce qu'un agent de test IA fait différemment
Déduit la couverture de votre produit. À partir d'une spécification, d'un document d'exigences ou en explorant l'application en cours d'exécution, plutôt qu'à partir de ce que quelqu'un a pensé à écrire.
Exprime les étapes comme des intentions. « Ouvrir la page des paramètres » plutôt qu'un chemin dans le DOM, ce qui explique qu'une refonte cosmétique ne le casse généralement pas.
Renvoie un échec exploitable par celui qui corrige. Ce qui a été tenté, ce qui s'est produit, où les deux ont divergé, sous une forme sur laquelle un autre agent peut agir.
Premier mode de défaillance : satisfaire la vérification
Quand on lui demande de faire passer un test, un agent peut emprunter le chemin le plus court, et modifier la vérification est parfois plus court que corriger le produit. Ce n'est pas de la malveillance, c'est un objectif sous-spécifié.
La parade coûte peu. Nommez un élément observable précis dans chaque vérification, et cassez délibérément quelque chose pour confirmer que la vérification peut virer au rouge. Une vérification qui ne peut pas échouer ne protège rien.
Deuxième mode de défaillance : une couverture assurée que personne n'a lue
Un agent produira volontiers deux cents cas de test. Le volume a l'apparence du progrès, et une couverture que personne n'a relue est une couverture sur laquelle personne ne peut compter, parce que vous ignorez ce qu'elle affirme.
Lisez le plan plutôt que le code. Supprimez les routes administratives, ajoutez les règles du produit qui ne sont écrites nulle part, et traitez-le comme une pull request.
Ce qu'il ne sait toujours pas faire
Connaître vos règles métier
Ce qui doit se passer quand deux remises s'appliquent est une décision, pas une déduction.
Imaginer le cas d'abus
Il vérifiera les autorisations. Il ne pensera pas au processus que quelqu'un pourrait détourner.
Réparer un environnement défaillant
Une instabilité due à l'infrastructure reste une instabilité.
Relire un plan efficacement
Le principal coût récurrent de cette façon de travailler, c'est de lire une couverture que vous n'avez pas écrite, et le faire mal est précisément ce qui produit les deux modes de défaillance ci-dessus. Il existe une méthode rapide.
Ne lisez que les assertions. Ignorez complètement les étapes lors du premier passage : les étapes sont mécaniques, c'est dans les assertions que réside le jugement. Toute assertion qui serait vraie d'un produit cassé est celle qu'il faut corriger, et elles sautent aux yeux dès lors que vous ne regardez qu'elles.
Parcourez ensuite la liste en cherchant ce qui manque plutôt que ce qui s'y trouve. Les plans générés sont systématiquement complets sur les endpoints qui existent, et systématiquement muets sur les règles qui ne vivent que dans la tête de quelqu'un. En ajouter trois vaut mieux que corriger trente étapes.
Pour commencer
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La même configuration est disponible dans le tableau de bord TestSprite si vous préférez ne rien installer en local. Le reste des commandes CLI se trouve dans le dépôt CLI.
Le déclencheur compte plus que le mécanisme. Le brancher sur votre événement de déploiement, c'est faire vérifier chaque changement sans que personne ait à le décider ; la GitHub App le fait depuis le tableau de bord, et une étape GitHub Actions le fait depuis l'intérieur de votre workflow.
Ce que TestSprite fait en tant qu'agent
Il déduit la couverture de vos sources et de l'application en cours d'exécution, exprime les étapes comme des intentions pour qu'un changement cosmétique ne les casse pas, s'exécute contre l'application déployée, et renvoie un échec sous la forme de ce qui a été tenté, de ce qui s'est produit et de l'endroit où les deux ont divergé.
L'installation ajoute la compétence de vérification à l'agent de codage que vous utilisez déjà, de sorte que tout cela se produit à l'intérieur de la boucle où le code s'écrit, et non comme une étape distincte dont quelqu'un doit se souvenir.
La valeur tient à la fermeture de la boucle. Un changement est vérifié contre le produit en cours d'exécution, un échec revient sous une forme sur laquelle l'agent peut agir, et la correction est confirmée par autre chose que le raisonnement qui l'a produite. Ce qui reste à votre charge, c'est de lire le plan et de décider de ce que « correct » veut dire, soit une heure par semaine plutôt qu'un métier.
En quoi est-ce différent d'un générateur de tests ?
Un générateur produit du code que vous exécutez et maintenez ensuite. Un agent l'exécute aussi, lit le résultat et peut itérer : c'est ce qui ferme la boucle.
Peut-il fonctionner sans spécification ?
Oui, en explorant l'application en cours d'exécution, même si une spécification ou un document d'exigences donne un meilleur premier plan.
Quel niveau de relecture demande-t-il ?
Lisez le plan avant la première exécution et après toute régénération importante. Entre les deux, relisez les nouveaux cas comme vous relisez du code.
Qu'est-ce qui l'empêche de faire grimper les coûts ?
Les exécutions consomment des crédits : fixez donc un cadre avant une longue session. Un agent qui dispose d'un outil de vérification s'en servira, c'est précisément le but, et cela mérite d'être budgété.
Remplace-t-il un ingénieur QA ?
Il remplace la moitié répétitive. Définir ce qui est correct et penser en adversaire restent du travail humain, et c'est de toute façon la moitié la plus précieuse.
Il décide de ce qu'il faut vérifier. Vérifiez ce qu'il a décidé.
Un agent de test IA déduit la couverture, exprime les étapes comme des intentions et renvoie des échecs exploitables. Prémunissez-vous contre les vérifications qui ne peuvent pas échouer et contre la couverture que personne n'a lue, et gardez les règles métier et les cas d'abus entre des mains humaines.