J’écris des tests pour gagner ma vie. Enfin, en partie pour gagner ma vie. Et le secret honteux de la profession de test est que la plupart d’entre nous passent plus de temps à maintenir de vieux tests qu’à en écrire de nouveaux. Un bouton change de nom, un sélecteur change, une page est redesignée — et soudain, 40 tests échouent, aucun à cause de véritables bugs. Juste parce que l’interface a changé.
Alors quand les outils de test AI ont promis des “tests auto-réparateurs,” j’étais sceptique mais désespérément optimiste. Comme un pompier épuisé entendant parler d’un bâtiment qui s’éteint de lui-même.
Il s’avère que certains d’entre eux tiennent réellement leurs promesses.
Où les tests AI fonctionnent réellement
Génération de tests avec Copilot est la fonctionnalité de test AI la plus pratique que j’ai rencontrée. Écrire une fonction, basculer vers le fichier de test, et Copilot propose des cas de test — y compris des cas limites auxquels je n’aurais pas pensé.
La semaine dernière, il a proposé un test pour une entrée de nombre négatif sur une fonction que je n’avais pas envisagée. La fonction plantait avec des nombres négatifs. Copilot a trouvé un véritable bug en écrivant un test que je n’aurais pas écrit. C’est… plutôt génial.
Le hic : Copilot génère des tests qui passent, mais “passent” et “testent la bonne chose” sont différents. Il a tendance à tester l’implémentation plutôt que le comportement — donc si l’implémentation est incorrecte mais cohérente, Copilot écrira des tests qui valident le mauvais comportement. Vous devez toujours lire les tests générés et vous demander “ce test vérifie-t-il ce qui m’importe réellement ?”
Tests visuels avec Applitools ont résolu un problème qui me faisait craindre les changements en frontend. Le test de régression visuelle signifiait autrefois une comparaison pixel par pixel, ce qui échouait constamment à cause des différences de lissage, des mises à jour du moteur de rendu, et du contenu dynamique comme les horodatages ou les publicités.
Applitools utilise l’IA pour comparer les captures d’écran comme un humain le ferait — en ignorant les différences non pertinentes tout en capturant les significatives. Une date qui change ? Ignorée. Un bouton qui bouge de 50 pixels ? Signalé. Un changement de couleur de texte ? Signalé. Contenu publicitaire dynamique ? Ignoré.
Nous sommes passés de plus de 30 échecs visuels faux positifs par version à environ 2. Mon équipe QA a cessé de redouter les revues de tests visuels.
Tests auto-réparateurs avec Testim sont la chose la plus proche de la magie. L’IA suit plusieurs attributs de chaque élément d’interface — son texte, sa position, sa classe CSS, les éléments environnants, et plus encore. Lorsque l’un des attributs change (comme une classe CSS renommée), l’IA utilise les autres attributs pour retrouver l’élément.
Avant Testim : un refactoring CSS a cassé 120 tests. Après Testim : le même type de refactoring a cassé 3 tests (ceux où l’élément a réellement été supprimé, pas juste renommé). Cela représente une réduction de 97,5 % des échecs faux positifs. Les heures économisées sur la maintenance des tests sont significatives.
Les outils qui m’ont déçu
Agents de test entièrement autonomes — ceux qui promettent “il suffit de les diriger vers votre application et ils testeront tout” — n’y sont pas encore. J’ai essayé deux outils de test autonome différents. Ils ont trouvé quelques problèmes de fonctionnalité de base mais ont manqué des cas limites, écrit des tests fragiles, et généré des faux positifs qui prenaient plus de temps à enquêter que les problèmes qu’ils avaient trouvés.
La technologie y arrivera. Ce n’est juste pas le cas aujourd’hui.
Tests d’intégration générés par l’IA sont médiocres. Les tests unitaires (testant des fonctions individuelles) sont bien adaptés à la génération par l’IA car le périmètre est petit et les attentes sont claires. Les tests d’intégration nécessitent de comprendre comment les composants interagissent, quel est le comportement système attendu, et où se trouvent les modes de défaillance intéressants. L’IA n’a pas encore suffisamment de contexte pour cela.
Mon actuelle pile de tests
Tests unitaires : Copilot génère des premiers jets, je révise et ajuste. La couverture est passée de 45 % à 78 % sans ajouter de temps de test dédié. La qualité des tests individuels n’est pas toujours parfaite, mais le volume compense.
Tests E2E : Testim pour les parcours utilisateurs clés. L’auto-réparation maintient la maintenance basse. Nous avons plus de 200 tests E2E qui s’exécutent dans CI et qui restent réellement verts.
Tests visuels : Applitools pour les pages et composants clés. Détecte les régressions CSS que les tests fonctionnels manquent complètement.
Tests manuels : Toujours irremplaçables pour les tests exploratoires, l’évaluation de l’UX, et les questions “est-ce que cela semble correct ?” auxquelles aucune IA ne peut encore répondre.
Ce que je dis aux équipes qui commencent
Commencez avec Copilot pour les tests unitaires. C’est l’investissement en tests AI le moins exigeant et le plus rentable. Vous écrivez déjà du code dans un IDE — les tests viennent essentiellement gratuitement.
Ajoutez ensuite Applitools si vous avez une application axée sur le visuel. La configuration prend une journée, et la réduction des faux échecs visuels est immédiate.
Envisagez Testim ou similaire si la maintenance des tests E2E prend beaucoup de temps à votre équipe. La valeur est proportionnelle à la taille de votre suite de tests — si vous avez 20 tests E2E, la maintenance manuelle est gérable. Si vous en avez 200+, l’auto-réparation est un sauveur.
Ne vous procurez pas encore d’outils de test autonomes. Donnez-leur encore un an.
La vérité inconfortable
Les outils de test AI rendent le test plus rapide et moins douloureux. Ils ne rendent pas le test réfléchi. La partie difficile du test — décider quoi tester, comprendre les risques, prioriser les cas de test qui comptent réellement — reste entièrement un travail humain.
Une suite de tests avec 95 % de couverture de code provenant de tests générés par l’IA peut toujours manquer le bug qui met en panne la production, car la couverture de code mesure ce qui a été exécuté, pas ce qui a été vérifié. L’IA a écrit des tests qui vérifiaient les valeurs de retour mais ne vérifiaient pas les effets secondaires. Elle a vérifié le chemin heureux mais a sauté le traitement des erreurs.
Utilisez l’IA pour gérer le travail ennuyeux. Utilisez votre cerveau pour le travail important. C’est la combinaison qui fonctionne réellement.
🕒 Published: