Tests logiciels autonomes : quatre niveaux, décrits honnêtement

Les quatre niveaux des tests logiciels autonomes

• 1. Rédaction assistée. Vous dites quoi tester, l'outil écrit le code. Un vrai gain de temps. Vous décidez encore de tout.

• 2. Couverture générée. L'outil propose quoi tester à partir d'une spécification ou de l'application en fonctionnement. Vous relisez le plan. C'est là que se situent réellement la plupart des produits.

• 3. Auto-maintenance. La couverture s'adapte aux évolutions du produit sans que personne ait à la réparer. Suppose de distinguer un changement voulu d'une régression.

Le quatrième est la closed loop: il détecte un échec, transmet les preuves à un agent de codage et vérifie le correctif. Cela existe aujourd'hui sous une forme étroite, pour les défauts comportementaux disposant d'une reproduction claire, et ne s'étend à rien qui exige une décision produit.

Ce que chaque niveau exige de vous

• Niveau un : savoir quoi tester. Tout le jugement vous revient.

• Niveau deux : relire un plan. Plus rapide que l'écrire, ce n'est pas rien pour autant, et le sauter est le meilleur moyen d'obtenir une couverture que personne ne comprend.

• Niveau trois : décider de ce qui compte comme changement voulu. L'outil ne peut pas savoir qu'un parcours a été délibérément repensé.

• Niveau quatre : définir le comportement correct avec assez de précision pour qu'un correctif puisse être vérifié sans vous.

Remarquez que le travail humain ne disparaît pas à mesure que l'on monte. Il se déplace vers le haut, de la frappe vers la décision, ce qui est à la fois plus précieux et plus difficile à déléguer.

Le plafond que personne ne met en avant

Aucun niveau ne supprime la nécessité de décider ce que « correct » veut dire. Un outil peut déduire qu'un endpoint existe et qu'un champ est une chaîne de caractères. Il ne peut pas déduire que deux remises ne doivent pas se cumuler, parce qu'il s'agit d'une règle métier qui tient à une décision prise par quelqu'un.

Tout produit qui laisse entendre le contraire décrit le niveau deux en l'appelant niveau quatre.

Les questions qui situent un produit sur l'échelle

Les éditeurs se présentent toujours au barreau le plus élevé qu'ils peuvent défendre, d'où l'intérêt d'avoir des questions qui les situent précisément.

Qui décide de ce qui est testé. Si la réponse est vous, c'est le niveau un, quelle que soit la façon dont le test est écrit.

Ce qui se passe quand l'interface change mais pas le comportement. Si un humain répare le test, c'est le niveau deux. S'il survit, le trois. S'il survit et échoue malgré tout lorsque le comportement a réellement changé, c'est le trois bien fait, ce qui est plus rare.

Et ce qui se passe après un échec. Si le résultat part vers un tableau de bord destiné à une personne, c'est là que tout s'arrête. Le niveau quatre signifie que le résultat est exploitable par ce qui corrige le problème, et que le correctif est vérifié sans qu'un humain ait à relayer quoi que ce soit. Poser ces trois questions dans l'ordre prend cinq minutes et donne un positionnement bien plus honnête que n'importe quelle liste de fonctionnalités.

Pour commencer

Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout le reste de ce que permet la ligne de commande se trouve dans le dépôt du CLI.

Si le pipeline appartient à une autre équipe, la GitHub App est la voie de moindre résistance : c'est un webhook, elle ne change rien dans votre dépôt et elle se déclenche quand votre build signale la mise en ligne de la nouvelle version. Si vous préférez que la vérification soit visible dans le dépôt, une étape GitHub Actions s'en charge.

Où se situe TestSprite sur l'échelle

Le niveau deux partout, le niveau trois pour les changements de comportement, et le niveau quatre sous sa forme étroite : un échec revient sous une forme sur laquelle un agent de codage peut agir, et le correctif est vérifié par le même contrôle plutôt que par le raisonnement qui l'a produit.

Concrètement, la couverture est générée à partir de votre produit puis affinée en langage courant, les étapes sont des intentions, si bien qu'un changement cosmétique ne les casse pas, et la compétence de vérification s'installe dans l'agent de codage que vous utilisez déjà, pour que la boucle se referme là où le travail se fait.

Ce qui reste de votre côté, c'est le plafond décrit plus haut : décider ce que « correct » signifie pour une règle ambiguë. Tout ce qui se trouve en dessous bouge, et l'avantage est que la couverture cesse d'être limitée par ce que quelqu'un peut écrire.