Test IA : les trois choses différentes que ce terme désigne

Pourquoi « test IA » est une catégorie qui n'aide pas

Une catégorie désigne d'ordinaire un problème. Celle-ci désigne une technologie, et c'est pourquoi elle recouvre trois problèmes aux symptômes différents, aux acheteurs différents et aux modes de défaillance différents. Avant de comparer quoi que ce soit, mieux vaut énoncer clairement lequel est le vôtre.

Premier type : l'IA qui écrit vos tests

Le problème qu'il résout : vous avez du code sans tests, et les écrire à la main est lent et fastidieux.

À quoi cela ressemble : vous pointez un outil vers une fonction, un fichier ou une spécification, et il produit du code de test que vous pouvez committer.

Où cela s'arrête : les tests générés héritent des hypothèses du code dont ils sont issus. Si l'implémentation se trompe sur ce que renvoie un endpoint, le test généré affirmera la même erreur et passera. C'est la limite silencieuse de toute la catégorie. La couverture monte ; la confiance ne devrait pas suivre, en tout cas pas autant que le chiffre le laisse croire.

Vous en avez besoin si : votre lacune, c'est le volume. Il existe une grande quantité de code non testé et personne n'a le temps.

Deuxième type : l'IA qui exécute et maintient les tests

Le problème qu'il résout : vous avez déjà une suite de tests et la maintenir en vie coûte cher. Les sélecteurs cassent à chaque refonte, les tests sont instables, et une part non négligeable de chaque sprint passe à les réparer.

À quoi cela ressemble : l'exécuteur s'adapte quand l'interface bouge. Un bouton dont le libellé ou la position a changé est toujours trouvé, parce que l'étape est comprise comme une intention plutôt que comme un chemin figé dans le DOM.

Où cela s'arrête : l'adaptation est à double tranchant. Une suite qui se répare autour d'une vraie régression est pire qu'une suite qui échoue, parce qu'elle masque précisément ce que vous vouliez savoir. La version utile distingue un changement d'interface d'un changement de comportement, et ne pardonne que le premier.

Vous en avez besoin si : votre lacune, c'est la maintenance. Les tests existent, et les garder au vert est l'impôt à payer.

Troisième type : vérifier du code écrit par une IA

Le problème qu'il résout : votre équipe livre du code produit par un agent de codage plus vite que quiconque ne peut le lire, et l'étape de revue qui attrapait autrefois les erreurs est devenue, sans bruit, une formalité.

À quoi cela ressemble : l'application déployée est sollicitée comme une personne l'utiliserait, et le résultat revient sous forme de preuves exploitables par l'agent, si bien que la correction intervient dans la même boucle que le changement.

Avec quoi cela se combine : des tests unitaires locaux rapides pour la logique, et un instrument dédié pour la charge. Cette couche répond à la question que ces deux-là ne peuvent pas trancher : celle de savoir si la fonctionnalité marche vraiment dans le produit en cours d'exécution.

Vous en avez besoin si : votre lacune, c'est la confiance. Le volume de code a augmenté, pas la capacité de revue, et personne ne peut dire avec certitude si les vingt dernières fusions ont cassé quelque chose.

Le type de test IA dont vous avez réellement besoin

Un court diagnostic, dans l'ordre où il vaut la peine de poser les questions.

C'est la troisième ligne qui mérite qu'on s'y arrête. Une couverture qui monte et une instabilité qui baisse se mesurent facilement l'une comme l'autre, et aucune des deux n'est ce que vous vouliez vraiment. Ce que vous vouliez, c'est moins de surprises en production.

Une question qui sépare les outils sérieux des démos

Quel que soit le type que vous examinez, demandez ce qui se passe en cas d'échec.

Une démo vous montre une ligne rouge. Un outil avec lequel on peut vivre vous dit ce qui a été tenté, ce que l'application a fait à la place et où les deux ont divergé, sous une forme directement exploitable par la personne chargée de corriger, sans qu'elle ait à reconstituer toute l'histoire. Si la réponse à un échec est une capture d'écran et une trace d'appels, l'interprétation reste à la charge d'un humain, et cet humain est précisément le goulot d'étranglement que vous vouliez supprimer.

Cela compte deux fois plus quand c'est un agent, et non une personne, qui corrige, car un agent ne peut pas plisser les yeux devant une capture d'écran pour en déduire l'intention.

La deuxième question : est-ce que cela tourne sans vous

Chacune des catégories décrites ici se réduit à néant si les tests ne s'exécutent que lorsque quelqu'un y pense. Une suite qui se déclenche selon un planning ou à chaque pull request travaille. Une suite qui attend qu'un humain la lance est un document décrivant un travail que quelqu'un avait l'intention de faire.

La question d'installation n'est donc pas de savoir quel outil a la meilleure syntaxe d'assertions. C'est de savoir lequel termine sa première session avec un contrôle branché sur votre pipeline plutôt qu'avec un rapport à l'écran.

Où nous nous situons, sans détour

TestSprite est conçu pour le troisième problème. Il ouvre votre application en cours d'exécution, s'en sert comme un véritable utilisateur et renvoie ce qui a cassé sous la forme d'un ensemble unique exploitable par votre agent de codage. Il génère aussi des cas de test, mais au service de la vérification plutôt que comme finalité.

Si votre lacune est la confiance, c'est exactement le problème pour lequel il est conçu, et le plus rapide pour s'en rendre compte est de le pointer vers un changement livré par votre agent cette semaine et de lire ce qui revient.

Pour lequel des trois TestSprite est conçu

Le troisième. TestSprite existe pour les équipes dont les tests sont au vert, dont les mises en production cassent quand même, et dont le code arrive de plus en plus d'un agent, plus vite que quiconque ne peut le relire.

Concrètement : il ouvre votre application en cours d'exécution, la sollicite comme le ferait une personne et renvoie ce qui a cassé sous la forme d'un ensemble unique et cohérent, exploitable par votre agent de codage. Les cas de test sont générés à partir de votre produit et affinés en langage naturel, de sorte que la couverture ne dépend pas de quelqu'un qui trouverait un après-midi de libre. Les étapes sont des intentions plutôt que des sélecteurs : une refonte qui ne change rien de fonctionnel ne fait pas passer la suite au rouge.

Il génère aussi des cas de test, ce qui touche à la première lacune, et ses étapes survivent aux changements d'interface, ce qui touche à la deuxième. Mais tout cela sert le verdict, ce n'est pas la finalité. Si votre vraie plainte est que l'écriture des tests est fastidieuse, ou que votre suite actuelle est instable, un produit bâti autour de l'un ou de l'autre vous servira mieux, et autant le dire avant un essai plutôt que pendant.