L'IA dans les tests logiciels : ce qui a changé et ce qui n'a pas changé

Ce que l'IA dans les tests logiciels a réellement changé

• L'écriture des tests n'est plus le goulot d'étranglement. Traduire un comportement connu en code de test représentait l'essentiel du travail. C'est aujourd'hui quasi gratuit, ce qui déplace la contrainte vers la décision de ce qui doit être vrai.

• Ce n'est souvent pas un humain qui corrige. Quand c'est un agent de code qui consomme l'échec, le format de sortie compte plus que le tableau de bord. Une capture d'écran n'est plus un livrable.

Ce qui n'a pas changé

Ce qui est devenu plus difficile

Le volume de code a augmenté, pas la capacité de relecture. C'est la véritable crise derrière la plupart de l'intérêt actuel pour l'IA dans les tests logiciels, et générer davantage de tests ne la résout pas. Ce qui la résout, c'est une vérification indépendante du comportement, car des tests générés à partir des mêmes hypothèses que le code sont d'accord avec le code.

Le deuxième risque nouveau est plus subtil : un agent à qui l'on demande de faire passer une vérification peut satisfaire la vérification au lieu de corriger le produit. Les vérifications vagues y invitent. Les vérifications précises et réfutables, non.

L'habitude à prendre

Cassez volontairement quelque chose et vérifiez que le test passe au rouge. Cela prend une minute et c'est la seule preuve qu'une vérification, générée ou écrite à la main, est bien reliée à votre produit.

La métrique qui trompe le plus vite

Le pourcentage de couverture a toujours été un indicateur imparfait, et la génération l'a complètement cassé, ce qui compte puisque c'est encore ce que la plupart des équipes remontent.

Ce chiffre mesure quelles lignes ont été exécutées. Il n'a jamais mesuré si quelque chose de significatif avait été vérifié, et quand les tests sont générés en masse, l'écart se creuse fortement : il est facile de produire une suite qui touche quatre-vingt-dix pour cent du code sans rien affirmer d'important. La couverture monte, la courbe est belle, et les défauts passés en production ne bougent pas.

Deux chiffres qui n'ont pas ce problème : la part des défauts trouvés avant la mise en production, et le délai entre un échec et sa correction. Ni l'un ni l'autre ne se gonfle en écrivant plus de tests, les deux bougent quand quelque chose s'améliore vraiment, et les deux sont plus difficiles à collecter, ce qui est précisément la raison pour laquelle les équipes continuent de remonter la couverture à la place.

Par où commencer

Le tableau de bord couvre le même terrain pour qui ne veut pas d'installation locale, et l'ensemble des commandes se trouve dans le dépôt 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 nouvelle version en ligne. Si vous préférez que la vérification soit visible dans le dépôt, une étape GitHub Actions s'en charge.

Ce que TestSprite apporte sur la partie devenue plus difficile

C'est le problème de volume que TestSprite est conçu pour traiter. La couverture est générée à partir de votre produit au lieu d'être écrite, elle n'entre donc pas en concurrence avec le développement de fonctionnalités pour le temps des équipes, et elle s'exécute à chaque changement plutôt que quand quelqu'un y pense.

Le problème d'indépendance est réglé par l'endroit où se place la vérification. Elle sollicite l'application déployée face au comportement que vous avez décrit, et non face aux hypothèses du code lui-même, ce qui la rend informative quand l'implémentation et ses tests unitaires viennent du même agent.

Ce qui est inchangé l'est aussi ici : c'est toujours vous qui décidez ce que signifie « correct », et les données de test comme les environnements restent les vôtres. Ce que vous gagnez, c'est que la couverture cesse de prendre du retard sur le rythme auquel le code arrive.