Le véritable risque de l'IA dans les tests : la fausse confiance, pas les bugs

Le tableau de bord s'est illuminé en vert. Tous les tests automatiques ont réussi. L'assistant IA a généré de nouveaux cas de test, supprimé les anciens et a même indiqué en quelques minutes comment la couverture des tests s'était améliorée. L'équipe s'est dirigée vers le lancement avec confiance vendredi.

Nous sommes maintenant lundi matin.

Il y a des tickets dans le support. Des clients dont les adresses enregistrées n'ont pas pu finaliser leur achat. Comment leurs adresses enregistrées se sont-elles cassées ? L'interface utilisateur semble complètement cassée sur un appareil mobile typique. Une API critique n'avait pas de gestion robuste des cas limites. Pris ensemble, tous ces problèmes pointent vers une menace plus grande : la volonté d'une équipe de s'appuyer aveuglément sur des entrées externes, en supposant que tout est correct.

C'est le véritable danger que l'IA apporte au QA.

Ce n'est pas que l'IA introduira des bugs dans nos tests. Tous les logiciels ont des bugs. Toutes les équipes QA sont douées pour les identifier et les résoudre. Cependant, la plus grande menace de l'IA est qu'elle peut faire croire à une équipe que ses tests sont approfondis alors qu'ils ne le sont pas. Avec l'IA dans les tests, une équipe QA peut acquérir un faux sentiment de confort que tout est exact.

Cette fausse confiance peut être très coûteuse. Cet excès de confiance peut entraîner d'énormes responsabilités financières. Même les systèmes IA entièrement testés peuvent parfois échouer face aux complexités du monde réel. McDonald's a récemment fermé un système IA d'IBM qu'il testait à ses comptoirs de service au volant après qu'il ait fait des erreurs répétées dans les commandes. C'est un rappel que même les technologies fiables peuvent avoir de graves défauts.

Ce que signifie vraiment la fausse confiance en QA

Le vrai problème se produit lorsqu'une équipe est convaincue que les tests ont suffisamment testé un système donné. Ce faux sentiment de sécurité provient du fait que les risques de sécurité pertinents ne sont soit pas découverts, soit pas testés rigoureusement.

Cela a longtemps été un problème dans les méthodes d'automatisation traditionnelles. Dans ces méthodes, un grand nombre de tests peuvent être exécutés, mais il n'y a pas beaucoup de profondeur dans les tests. Le fait qu'un rapport de pipeline indique que toutes les vérifications ont réussi (tout en vert) ne signifie pas que le système lui-même sera nécessairement parfaitement opérationnel.

L'automatisation devient encore plus complexe lors de la mise en œuvre de l'IA. Une chose à savoir sur les modèles de langage IA est qu'ils peuvent présenter des informations d'une manière qui semble convaincante mais qui est en réalité erronée. 

Nous pourrions voir des tests s'exécuter et même une meilleure couverture de test, car l'IA aide à la construction de tests et à l'analyse technique des résultats de toute exécution de test. Tout cela est bénéfique.

Mais tous les avantages ne sont pas parfaitement fiables.

Un test construit par l'IA pourrait manquer un élément critique de la logique métier. Alternativement, il pourrait être conçu uniquement pour tester les scénarios courants. Un tel test semblera entièrement adéquat. Si les résultats sont nets et exprimés clairement, l'équipe considérera probablement le test comme adéquat, laissant de graves défauts non découverts.

C'est pourquoi les tests peuvent souvent créer des opportunités pour les équipes de faire de fausses hypothèses.

La question la plus cruciale aujourd'hui, pour toute personne impliquée dans les tests automatiques de logiciels utilisant l'intelligence artificielle, ne devrait pas être « L'IA construit-elle des tests plus efficacement ? » Mais plutôt « Les tests construits par l'IA sont-ils vraiment fiables ? »

Pourquoi l'IA rend le problème plus difficile à remarquer

Un mauvais test manuel peut être rapidement identifié. Les tests scriptés qui ne sont pas correctement écrits font souvent des erreurs.

​Mais lorsque les tests construits par l'intelligence artificielle (IA) échouent, il est difficile de le dire au premier coup d'œil. Ils peuvent faire des assertions qui semblent très précises, et des noms et scénarios qui semblent réalistes. Mais ils peuvent silencieusement omettre les facteurs les plus importants. Ils peuvent mal interpréter le véritable objectif d'une fonctionnalité. Ils peuvent présenter les mêmes idées différemment. L'IA peut également faire des rapports trop confiants sur une version logicielle sans preuves suffisantes.

​Cela crée un écart dangereux entre la fluidité qui apparaît à l'extérieur et la qualité qui est à l'intérieur.

​Dans l'assurance qualité (QA), notre confiance devrait provenir de la traçabilité des tests, de la profondeur de la couverture, des évaluations des risques et des résultats observables. Pas de la beauté des données produites par l'IA.

Cinq façons dont l'IA crée une fausse confiance dans le QA moderne

Sur-test des scénarios courants

L'IA excelle là où il y a des modèles réguliers. Par conséquent, elle est facilement attirée par les flux normaux, les entrées attendues et le comportement utilisateur courant.

Mais les défauts logiciels graves se cachent souvent ailleurs :

• Transitions d'état : Lors des changements d'un état à un autre.
• Problèmes de timing : Erreurs dans le timing des processus.
• Tentatives et interruptions : Problèmes lorsque les transactions échouées sont réessayées ou interrompues.
• Limites de permissions : Lacunes de sécurité dans les limites des permissions.
• Échecs partiels : Lorsque seules des parties du système échouent sans s'effondrer complètement.
• Entrée du monde réel incohérente : Informations aléatoires fournies par les clients dans le monde réel. 

Si les tests générés par l'IA ne suivent que les scénarios courants envisagés par un concepteur de produits, ils laisseront les chemins risqués intacts. Cela ne sert qu'à créer l'illusion que les tests sont complets.

Crée de mauvaises assertions 

La vraie valeur d'un test est ce qu'il prouve sur le logiciel. Trop de tests terribles couvrent une énorme portée d'actions sur l'application, mais ne vérifient pas correctement si ces actions réussissent pour l'entreprise. Un test est simplement un mouvement où tout ce qu'il fait est de cliquer sur des boutons, de remplir des champs, de cliquer sur plus de boutons, de visualiser des écrans et de voir quelque chose apparaître.

L'IA peut exécuter de tels tests automatiques légers beaucoup plus rapidement qu'un humain. Cependant, si vos conditions de test (assertions) sont trop générales, mal définies ou non pertinentes pour le cas d'utilisation commercial, alors simplement exécuter un test réussi ne fournit pas beaucoup de sécurité pour une version logicielle. Un test réussi lors d'un paiement pourrait simplement afficher une bannière de succès et ne pas garantir qu'une commande est traitée correctement (taxe, totaux, etc.), qu'un e-mail est envoyé ou que l'inventaire est réduit.

Plus de cas de test et plus de défauts

Une équipe peut vérifier 40 cas de test écrits à la main. Mais elle peut ne pas adopter la même approche pour 400 créés rapidement en utilisant l'IA. C'est l'un des plus grands pièges de l'assurance qualité (QA) basée sur l'IA : les tests minutieux diminuent naturellement à mesure que le nombre augmente.

Avoir plus de cas de test peut nous donner une sorte de confiance psychologique. Lorsque le nombre augmente, nous sentons que la suite de tests est très vaste et que les rapports sont impeccables. Mais augmenter le nombre de cas de test n'est jamais un substitut à leur qualité.

Sans cartographie appropriée des risques et traçabilité des exigences, l'IA ne fera qu'aider à enregistrer des suppositions au lieu de vérifier la vraie qualité du système.

Crée une confiance aveugle dans les feux verts

Lorsque les rapports de pipeline affichent toujours du vert, cela donne aux équipes un fort sentiment de confiance et encourage des décisions rapides. Cela supprime les obstacles pour faire avancer le travail, de sorte que ce sentiment de sécurité se propage facilement lorsque les équipes commencent à construire, corriger et prioriser leurs propres tests en utilisant l'IA. Leur instinct passe de la vérification des résultats à la simple confiance aveugle dans le système. En surface, cela semble mineur, mais cela peut changer la culture QA pour toujours. La question cesse d'être « quel risque ce test couvre-t-il ? » et devient « l'IA a-t-elle exécuté un test pour cela ? » À ce stade, les gens ont tendance à supposer que tout va bien et cessent de remettre en question la qualité.

Fait même des erreurs aveugles qui semblent intelligentes

L'une des caractéristiques les plus dangereuses des systèmes IA modernes est qu'ils peuvent présenter même les erreurs les plus évidentes avec une grande authenticité. Ceci est d'une grande importance dans l'assurance qualité (QA).

Même si un test IA est écrit avec une mauvaise compréhension d'une exigence ou des informations incomplètes, sa sortie sera très précise et polie pour donner l'impression qu'elle a été écrite correctement. Un test typique ne sera pas capable de trouver rapidement l'erreur. Le danger ici n'est pas seulement dans l'erreur elle-même, mais aussi dans la facilité avec laquelle l'erreur peut être crue.

Une erreur évidente peut être rapidement corrigée. Mais une fausse conclusion qui semble crédible est susceptible d'être publiée sans être testée.

Ce que les équipes QA intelligentes font différemment

Cela ne signifie pas que l'IA devrait être complètement évitée.

La solution est de l'utiliser sans abandonner votre jugement à l'IA. Les meilleures équipes d'assurance qualité (QA) voient l'IA comme un assistant, pas quelque chose à qui faire aveuglément confiance. Bien qu'elles l'utilisent pour augmenter la vitesse, elles ne lui accordent pas une confiance finale. C'est-à-dire qu'elles suivent un style de travail où elles ne font confiance à la sortie fournie par l'IA qu'après l'avoir vérifiée.

Voyons comment cela fonctionne en pratique.

Comprendre le risque avant de construire des tests

Avant de créer des cas de test, vous devez définir clairement les principaux problèmes qui pourraient affecter l'entreprise ou l'utilisateur.

Les domaines liés aux transactions financières, aux questions juridiques (conformité), à l'identité, aux permissions et à la confiance des clients devraient être les premiers à recevoir de l'attention. Quelles sont les erreurs qui se produisent très rarement mais causent beaucoup de pertes ? Où les erreurs passent-elles facilement inaperçues ?

L'IA peut fournir de nouvelles idées dans de tels domaines. Mais c'est aux humains de décider où se trouvent davantage de risques.

Vérifiez ce que le test affirme, pas seulement les étapes

Chaque étape dans un cas de test généré par l'IA peut sembler correcte au premier coup d'œil. Mais la vraie question est de savoir si le test teste réellement le résultat correct.

C'est une bonne idée de développer une habitude simple lors des tests : se concentrer davantage sur ce que le test prouve que sur la façon dont il fonctionne.

Maintenir une couverture de test en couches

Une seule couche de test ne peut pas à elle seule garantir que le système est complet. Les tests unitaires, l'API, l'intégration, de bout en bout (E2E), les tests exploratoires et les retours de production exposent tous différents types de risques.

Si l'IA teste une seule couche, les équipes ne doivent pas considérer que leur système est complètement sécurisé. Chaque couche doit être testée avec sa propre importance.

L'avenir du QA n'est pas moins humain

Beaucoup craignent que l'IA dans les tests devienne une entreprise sans humain. Mais en réalité, l'inverse se produit.

À mesure que l'IA prend en charge les tâches répétitives, l'intervention humaine devient plus précieuse. Identifier les risques, éliminer les ambiguïtés, remettre en question les hypothèses, tester des cas limites complexes et demander « Le système est-il sécurisé parce qu'un test a réussi ? » Tout cela nécessite l'intelligence humaine.

Il ne s'agit pas de moins de travail, mais d'une meilleure qualité. Les meilleures équipes de l'avenir ne sont pas celles qui construisent d'innombrables tests. Ce sont celles qui peuvent travailler rapidement et soigneusement, mais qui remettent en question là où c'est nécessaire.

Parce que les bugs dans les systèmes sont toujours visibles. Mais l'excès de confiance nous conduit souvent à les ignorer.

Leçons pour votre prochaine étape

L'IA peut certainement accélérer les processus QA. Elle peut aider les équipes à construire des tests, à réduire les tâches répétitives et à répondre aux changements plus rapidement.

Mais cette vitesse non supervisée peut conduire à un nouveau type de problème de qualité. Lorsque les tests générés par l'IA nous font nous sentir complets, lorsque les tableaux de bord brillants nous font croire en eux, lorsque les rapports sophistiqués prennent le pas sur les évaluations rigoureuses, le QA n'est pas vraiment robuste. Au contraire, il devient facilement trompé.

Les équipes les plus sûres sont celles qui se souviennent du simple fait que ce n'est pas parce qu'un test réussit qu'il s'agit d'une preuve absolue que le système est sécurisé. Ce n'est qu'une indication, et l'intelligence humaine doit encore être utilisée pour évaluer cette indication.

Donc, la vraie menace que l'IA pose au QA n'est pas les bugs. C'est plutôt la fausse confiance qu'elle donne.