Le meilleur outil de test IA dépend de la lacune que vous devez combler

Le meilleur outil de test IA pour trois lacunes différentes

• Volume. « Nous n'avons presque aucun test. » Il vous faut de la génération. Attention : les tests générés héritent des présupposés du code.

• Maintenance. « La moitié de notre suite est rouge pour des raisons qui n'ont rien à voir avec le produit. » Il vous faut une exécution adaptative. Vérifiez qu'elle échoue bien quand le comportement change, et pas seulement qu'elle survit aux changements cosmétiques.

• Confiance. « Les tests sont verts, les mises en production cassent quand même, et l'essentiel du code vient d'un agent. » Il vous faut une vérification contre le produit en fonctionnement.

La question qui départage les candidats

Quelle que soit votre lacune, demandez ce qui se passe en cas d'échec. Une ligne rouge, c'est une démo. Un outil exploitable indique ce qui a été tenté, ce que l'application a fait et où les deux ont divergé, sous une forme directement exploitable par qui doit corriger, sans avoir à reconstituer l'histoire.

Cela compte doublement quand c'est un agent de codage qui corrige : il ne peut pas scruter une capture d'écran pour en déduire l'intention.

La deuxième question

La première session se termine-t-elle par une vérification branchée sur votre pipeline, ou par un rapport à l'écran. Chacune de ces catégories ne vaut plus rien si les tests ne s'exécutent que lorsque quelqu'un y pense.

Le piège commun à toutes les catégories

Des tests écrits par le même auteur que le code sont d'accord avec le code, y compris là où tous deux ont tort. Un taux de réussite élevé pour une suite générée sur du code généré n'apporte presque aucune information. Ce que vous achetez réellement, c'est une vérification indépendante par rapport au comportement attendu.

Le tour de passe-passe des démos

Presque tous les produits de cette catégorie font la même démonstration : décrivez un parcours en langage naturel, regardez-le s'exécuter, constatez qu'il passe. C'est réellement impressionnant, et cela ne teste presque rien de ce qui vous importe.

Ce que cela démontre, c'est que l'outil sait piloter un navigateur sur un chemin nominal choisi par quelqu'un. Ce que vous devez savoir, c'est ce qui se passe quand l'application se trompe, quand l'interface change et quand personne ne regarde. Rien de tout cela n'apparaît dans une démo scénarisée.

Demandez donc les trois autres. Montrez-moi un rapport d'échec. Montrez-moi ce qui se passe après une refonte. Montrez-moi la vérification qui s'exécute sans que personne ne la lance. Un produit qui gère les trois sera ravi de vous les montrer ; celui qui ne les gère pas ramènera la conversation au chemin nominal, ce qui constitue déjà une réponse.

Comment évaluer correctement

Cassez quelque chose de réel pendant l'essai. Un enregistrement qui ne persiste plus, un filtre qui renvoie silencieusement tous les résultats. Le candidat échoue-t-il, l'échec nomme-t-il la divergence, peut-on partir de là pour corriger. Une demi-journée, et cela vaut mieux qu'un mois de comparaison de fonctionnalités.

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.

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.

La lacune pour laquelle TestSprite est conçu

La confiance. TestSprite ouvre votre application en fonctionnement, la sollicite comme le ferait une personne et renvoie ce qui a cassé en un seul bloc que votre agent de codage peut exploiter. Les cas de test sont générés à partir de votre produit puis affinés en langage courant, les étapes sont des intentions plutôt que des sélecteurs, et la première session se termine par une vérification qui s'exécute sur vos pull requests plutôt que par un rapport à l'écran.

Il génère des cas de test et résiste aux changements d'interface, il touche donc aussi aux lacunes de volume et de maintenance, mais celles-ci servent le verdict plutôt qu'elles n'en constituent l'objectif.

Ce que vous obtenez : les parcours qui vous mettraient dans l'embarras s'ils cassaient, vérifiés à chaque modification, avec un échec qui nomme la divergence. Si votre vraie plainte est que l'écriture des tests est fastidieuse, ou que votre suite existante est instable, dites-le pendant l'évaluation et regardez plutôt les produits conçus pour cela.