Un agent de test ne vaut que par ses échecs
Une ligne rouge assortie d'une capture d'écran suppose qu'un humain viendra l'interpréter. Un échec exploitable indique ce qui a été tenté, ce que l'application a fait et où les deux ont divergé, sous une forme sur laquelle qui doit corriger peut agir sans reconstituer le déroulé.
Cela compte doublement quand la correction revient à un agent de codage, incapable de regarder une capture d'écran pour en déduire l'intention. Demandez à voir un échec réel, pas une exécution réussie.
Deux : la capacité de la vérification à échouer
Cassez volontairement quelque chose pendant l'évaluation. Un enregistrement qui ne persiste plus, un filtre qui renvoie silencieusement tout. Si la vérification reste au vert, c'est qu'elle n'a jamais été reliée à votre produit.
Deux façons d'en arriver là. Une vérification trop vague pour avoir un résultat, et une exécution qui expire avant d'atteindre ses assertions et se conclut par un succès. La seconde est pire, car elle a l'apparence d'une couverture.
Trois : l'exécution sans qu'on le lui demande
Uniquement à la demande. Utile pendant une session, invisible ensuite.
À chaque changement. Déclenché par une pull request ou un déploiement. C'est celui qui vous protège.
À intervalles réguliers. Détecte les dérives d'environnement et les évolutions des dépendances externes.
Un agent de test qui n'agit que lorsqu'on le sollicite est un meilleur testeur manuel : cela a de la valeur, mais ce n'est pas ce que vous veniez acheter.
Ce qu'il faut surveiller la première semaine
Au-delà de ces trois propriétés, deux comportements observables dès la première semaine indiquent si l'ensemble va fonctionner.
La couverture qu'il produit reflète-t-elle votre produit ou la forme de votre spécification. Un agent qui part d'un document d'API couvrira fidèlement chaque endpoint, y compris ceux que personne n'utilise, et passera à côté de la seule règle qui vit dans un commentaire. Lire le premier plan vous dit dans quel cas vous êtes, et corriger tôt coûte bien moins cher que corriger à deux cents cas.
Et quelqu'un lit-il les échecs. Un agent de test produit plus de signal qu'un processus manuel, et un signal que personne ne consomme n'est qu'un coût. Si, au bout d'une semaine, les échecs sont constatés plutôt qu'analysés, le problème vient en général du format des échecs plutôt que de l'équipe, et mieux vaut le soulever avant que l'habitude ne s'installe.
L'évaluation en une demi-journée
Décrivez trois parcours. Cassez une chose. Faites un merge. S'il détecte la casse, la signale utilement et remarque le merge sans qu'on le lui demande, il fait son travail. Si l'un de ces trois points échoue, aucune liste de fonctionnalités ne compensera.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout ce que la ligne de commande sait faire par ailleurs 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.
Comment TestSprite répond aux trois
Un échec revient sous la forme de ce qui a été tenté, de ce que l'application a fait et de l'endroit où les deux ont divergé, dans un format sur lequel un agent de codage peut agir sans qu'une personne l'interprète au préalable. Les vérifications portent sur quelque chose de précis, et une exécution qui n'a jamais atteint ses assertions n'est pas rapportée comme un succès. Et il s'exécute au changement : connectez un dépôt et les exécutions démarrent à partir du déploiement que votre pipeline produit déjà.
La couverture est générée à partir de votre produit puis affinée en langage courant, et l'installation ajoute la compétence de vérification à l'agent de codage que vous utilisez déjà : créer et lancer une vérification se fait ainsi au sein du travail plutôt qu'à côté.
Ce que vous obtenez, c'est l'évaluation d'une demi-journée réussie : il détecte la casse, la signale utilement et remarque le merge sans qu'on le lui demande.
Quelle différence avec un framework de test ?
Un framework exécute ce que vous avez spécifié. Un agent décide de ce qu'il faut vérifier et peut itérer sur le résultat : c'est là que se trouve l'effet de levier, et c'est là qu'apparaît la charge de relecture.
A-t-il besoin d'accéder à notre code ?
Il vérifie l'application déployée via son interface. Votre agent de codage dispose déjà du code.
Quel niveau de relecture les vérifications générées demandent-elles ?
Lisez le plan avant la première exécution et traitez les nouvelles vérifications comme du code. Le volume sans relecture est le principal mode d'échec.
Peut-il corriger les bugs qu'il trouve ?
Il peut transmettre un échec exploitable à un agent de codage, qui propose alors un correctif vérifié de la même manière. La boucle se ferme ; le jugement reste de votre côté.
Combien coûte une exécution ?
Les exécutions consomment des crédits : fixez les attentes avant une longue session. Un agent qui dispose d'un outil de vérification s'en servira.
Format des échecs, falsifiabilité, déclencheur.
Un agent de test vaut la peine quand un échec est exploitable par qui le corrige, quand ses vérifications peuvent être mises en échec et quand il s'exécute sans qu'on le lui demande. Testez ces trois points en une demi-journée plutôt que de comparer des listes de fonctionnalités.