La taverne du testeur

Générez ses tests de régression à la volée : pour quoi faire ?

On parle d’IA depuis déjà quelques années mais depuis la parution de ChatGPT cette dernière est maintenant considérée comme un Eldorado accessible !

De mon côté l’IA reste un outil et le plus important n’est pas de savoir si c’est de l’IA mais bien de savoir quels sont les usages possibles avec. Qu’est-ce l’IA me permet de mieux faire qu’avant ? Qu’est-ce que l’IA me permet de faire que je ne pouvais pas faire avant et qui m’apporte de la valeur ?

Dans l’IA il y a de nombreux usages comme la priorisation et la sélection des tests pour les campagnes de régression. Ces usages, basés sur du Risk Based Testing ont pour but de réduire le périmètre de test en limitant un maximum l’augmentation des risques. Un autre usage de l’IA dans le test est de générer des campagnes de test de régression directement basés sur la manière dont le logiciel est utilisé.

Cela parait vraiment bien mais au final dans quels contextes puis-je utiliser cette génération automatique pour qu’elle m’apporte de la valeur ?

Dans cet article je vais vous proposer des contextes où la création d’une campagne de régression par l’IA apporte de la valeur

  • L’équipe n’a pas de campagne de régression

C’est le cas le plus évident. Avoir une campagne de régression toute faite alors qu’actuellement on n’en n’a pas où est n’est plus du tout à jour permet d’avoir une base pour vérifier le comportement de l’application.

Dans ce cas la génération de cette campagne est un excellent début car elle permet d’avoir quelque chose de concret et de ne pas se retrouver perdu

Par contre cette campagne, basée uniquement sur des usages reste incomplète et l’équipe devra également penser à implémenter quelques tests comme des tests négatifs ou liés à la sécurité.

  • L’équipe ne connait pas bien son produit et la manière dont il est utilisé

C’est un problème récurrent ! L’équipe développe un produit mais ne sait pas concrètement comment ce dernier est utilisé. Au final les tests ne sont pas forcément bien ciblés et les évolutions proposées n’ont pas autant de valeurs qu’attendues.

On fait alors potentiellement face à l’illusion d’absence d’erreur et à la réalisation d’un travail inutile.

Générer une campagne basée sur les usages permet de savoir concrètement comment les utilisateurs se servent du produit et donc de mieux cibler ses tests et évolutions.

Il faut cependant faire très attention à générer cette campagne sur une période représentative de l’ensemble des usages du produit.

  • L’équipe souhaite lutter contre le paradoxe du pesticide (usure des tests)

On est ici plus sur une campagne de régression assez conséquente avec des tests à jour mais sur un produit « ancien ». Les tests ne détectent plus aussi bien les anomalies et les défaillances se multiplient en production. Repenser l’ensemble de la campagne avec l’identification des tests à faire évoluer, à supprimer ou à ajouter demande un très gros effort manuel. Il peut alors être intéressant de regénérer une campagne de régression rapidement et de la compléter avec des tests essentiels issus de la campagne historique.

Comme indiqué il est nécessaire de compléter la campagne générée car la régression ne doit pas couvrir uniquement les potentielles défaillances d’usage commun mais aussi d’usage plus rare mais potentiellement malveillants ou tout simplement problématiques.

  • Le coût de maintenance de la régression est trop élevé

La maintenance des tests de régression (souvent automatisés) est un vrai sujet. On retrouve beaucoup d’articles donnant des bonnes pratiques pour limiter cette maintenance ou d’articles expliquant comment limiter son nombre de test afin de maintenir une maintenance soutenable.

Dans ce cas la génération de tests de régression à la volée permet de maintenir qu’un faible nombre de tests (ceux jugés les plus importants) et de compléter la campagne avec des tests générés à la volée.

Dans cet exercice il faut attacher une attention particulière aux tests qui sont conservés et continuer à les faire évoluer.

  • L’équipe souhaite implémenter des campagnes de tests de charge « réalistes »

Lorsque l’on fait des campagnes de tests de charge on essaie de simuler un flux d’utilisation générés par un certain nombre d’utilisateurs.

Avoir des tests liés à l’usage permet alors d’utiliser comme tests des parcours proches de ce que font réellement les utilisateurs et donc de simuler de manière plus représentative ces charges.

Il est important dans ce cas de pondérer l’occurrence des tests générés par rapport à la fréquence observée.

Conclusion

Utiliser l’IA ou ne pas utiliser l’IA, j’ai envie de dire que là n’est pas la question. La vraie question est quel est mon besoin et qu’est-ce qui permet d’y répondre.

Il est vrai que l’IA ouvre de nombreuses possibilités et permet d’accélérer de nombreuses tâches. Dans cet article j’ai proposé quelques exemples de contextes où le cas d’usage de génération des tests de régression a un potentiel intéressant et Il y a évidemment d’autres !

Il est également important de bien faire attention aux conséquences et aux limites des choix. L’IA, comme toute autre technologie, n’est pas magique. Elle a son lot de limitations et de problématiques. Il faut en être conscient afin d’adapter ses pratiques et ses usages si l’on souhaite en tirer le meilleur

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Présentation

[STLS 2022] Création et diffusion d’un jeu pour le test

Retrouvez le support de présentation de la conférence « Création et diffusion d’un jeu pour le test » utilisé lors de la STLS de 2022. Cette présentation est un REX de la création des 1001 tests et de sa diffusion Les autres supports de présentations de la STLS sont disponibles ici. Pensez

Lire la suite »
culture générale

Industrie classique ≠ Industrie logicielle

Encore trop de personnes haut placées dans les entreprises logicielles ne jurent que par la « productivité ». La sacro-sainte « productivité » ! Dans l’industrie classique cela revient à produire des pièces mécaniques. Dans l’industrie logicielle on  représente malheureusement souvent cela comme « pisser du code » (ce qui explique « productivité »). Cela me met hors de

Lire la suite »
conférence

[JFTL] Retours de participants

En juillet dernier la taverne vous proposait un webinaire proposant des retours sur la JFTL. Lors de cet événement nous avons lancé un sondage pour avoir les vôtres. Cet article a pour but de restituer ces retours en s’appuyant sur le sondage mais aussi et surtout sur les retours directs

Lire la suite »