IA et tests E2E/TNR : comment garder la maîtrise métier ?

Concevoir de bons tests exige une forte connaissance métier. C’est d’ailleurs pourquoi les équipes QA sont souvent, parmi tous les acteurs du Produit, celles qui maîtrisent le plus précisément le métier et le fonctionnel. Cette connaissance est le fruit de l’expérience et leur est transmise au travers de discussions informelles, au moins autant que par le corpus documentaire de l’entreprise.

L’exigence fondamentale de connaissance métier constitue un challenge sérieux pour les solutions IA de génération de tests à partir des User Stories qui fleurissent actuellement. Leur niveau de performance dépend en effet de la qualité des US.

Pourtant, le principe de base est on ne peut plus simple. Nous fournissons à l’IA générative les user stories et les critères d’acceptation, et celle-ci génère « d’un simple clic » les cas de test correspondants, correctement formatés et, dans l’idéal, déjà automatisés. Cela fonctionne plutôt bien, à condition que la user story puisse être considérée isolément. L’IA générative prend les critères d’acceptation un par un et les transforme en un ou plusieurs cas de test. Pour obtenir un bon résultat, les user stories doivent être formulées de manière claire et exhaustive. Toutes les « évidences » tacites que nous avons en tête doivent être explicitement consignées par écrit.

Dès qu’il y a des dépendances, les choses se compliquent. Car même si les chatbots sont désormais capables de traiter d’énormes quantités de texte, un LLM risque de se perdre dans les détails ou de négliger les contextes plus larges. Il est donc difficile de fournir au LLM toutes les User Stories à la fois.

Idéalement, chacune des US doit porter l’ensemble de la connaissance métier nécessaire à la génération de tests pertinents pour l’US en question. Sinon, les cas de test risquent d’être incomplets ou non pertinents. Dans le pire des cas, l’IA générative va se mettre à halluciner et inventer les informations qui lui manquent.

Au fond, ce problème n’est pas nouveau. Depuis toujours, le manque de clarté des exigences est la principale cause d’échec des projets. Pour remédier à cela, il faudrait impliquer davantage les analystes métiers ou les Product Owners. Cela signifie un transfert de charge des testeurs vers ces profils, généralement plus coûteux que les QA ; un transfert de charge d’autant plus difficile à accepter pour ces personnes qu’il ne bénéficie pas à leur mission première. De plus, ce transfert de charge ne dispense pas les QA de l’effort lié à la relecture et à la validation des tests générés.

Nos recommandations :
1 : des US atomiques et bien rédigées,
2 : des connaissances de prompting,
3 : accès à un LLM suffisamment performant avec – idéalement – du contexte supplémentaire (c’est-à-dire un système RAG qui a accès à la documentation complète à jour),
4 : le temps et la motivation pour une revue humaine sérieuse, non-bâclée.

Les tests d’Epic et les tests de bout en bout sont différents des tests d’US. Ici, il s’agit de tester des processus complexes avec des interactions entre différentes fonctions ou composants du système. Pour concevoir ces tests, il faut avoir une vue d’ensemble. C’est là, au plus tard, que le savoir-faire métier, largement non documenté, entre en jeu. Il ne sert alors à rien de fournir des documents supplémentaires au LLM, car les connaissances implicites ne sont, par définition, pas documentées de manière explicite. D’ailleurs, il serait déraisonnable de vouloir consacrer beaucoup plus de temps à parfaire la documentation. D’abord parce que le temps est justement ce qui manque à toutes les équipes ; ensuite parce qu’une documentation, l’expérience le prouve tous les jours, est obsolète avant même l’instant du point final.

Bref, confier les tests d’Epic ou de bout en bout à une IA revient à attribuer cette tâche à un testeur sans expérience ni connaissance métier. Ce serait probablement même pire. Car le testeur humain n’hésitera sans doute pas à afficher sa méconnaissance des subtilités métier et posera des questions, alors que l’IA apportera une réponse à tout prix, même au risque des pires âneries.

Nos recommandations :
1 : utiliser l’IA avec modération (pour l’instant) et privilégier l’humain avec expérience métier,
2 : oublier le rêve d’une documentation textuelle exhaustive,
3 : lire la section suivante…

Outre leur granularité, leur nombre et leur degré d’automatisation, il existe une quatrième différence entre le test d’US et le test d’Epic. Les tests d’US sont nettement plus volatils que les tests d’Epics. Si une US change, on la remplace par une nouvelle. Mais il est rare qu’une Epic change complètement. Les tests d’Epic forment ainsi la suite de tests de non-régression (TNR). Il est important de les garder à jour, ce qui représente une charge de travail importante. Selon une règle empirique, la maintenance d’un logiciel coûte au moins aussi cher, voire deux fois plus cher, que son développement initial.

Ce sont donc précisément les tests qui se prêtent le moins bien à l’IA générative qui doivent être maintenus à jour sur le long terme. Justement les tests pour lesquels les connaissances implicites sont si importantes, celles qui se trouvent dans la tête de ceux qui, au fil du temps, changent de projet, d’entreprise ou partent à la retraite.

En conclusion : les tests d’Epic requièrent des connaissances implicites, lesquelles rendent les solutions de génération par IA « en 1 clic » inopérantes ou inappropriées. D’autant plus que ces tests doivent ensuite être maintenus et, pour certains, automatisés.

Pour capturer, partager et capitaliser la connaissance métier, y compris l’implicite, dans l’objectif de concevoir des tests d’Epic/TNR/E2E, la conception visuelle est la bonne approche. Et pour maintenir et automatiser efficacement ces tests, il faut un IDE de test. C’est précisément ces deux services (et d’autres) que couvre notre solution Yest.

Yest permet de documenter la connaissance métier de façon graphique pour ensuite produire les tests les plus pertinents d’un point de vue métier. L’approche graphique est une méthode efficace qui permet de commencer la conception des tests beaucoup plus tôt que d’habitude. Car il n’est pas nécessaire de connaître les détails de l’IHM (par exemple d’un formulaire) pour savoir quelles informations doivent être renseignées. Les parcours graphiques servent de documentation vivante. En cas de changement d’US, ils permettent rapidement d’identifier les actions de test concernées, d’autant plus qu’il est possible de faire référence aux différentes user stories dans le parcours.

Nos recommandations pour mieux maîtriser la maintenance des TNR, utilisez Yest pour :
1 : capter et documenter la connaissance métier des PO / BA,
2 : communiquer autour de représentations visuelles plus faciles à comprendre que des spécifications purement textuelles (et verbeuses),
3 : profiter des nombreux accélérateurs intégrés dans Yest qui facilitent la création et la maintenance des TNR.

Avec Yest, il est possible de générer le minimum de scénarios de test garantissant une couverture complète des aspects à tester. Yest aide également à l’automatisation en implémentant une approche basée sur des mots-clés. Mais c’est plus qu’un générateur de tests à base de parcours graphiques. Avec ses nombreux accélérateurs, Yest est un véritable IDE pour les testeurs.

Exemple : si une nouvelle US s’intègre à un parcours existant, il suffit de mettre à jour le parcours. Yest identifiera les scénarios de test affectés et proposera des corrections automatiques. Ces modifications se feront de façon transparente, contrairement à l’IA générative qui agit davantage comme une boîte noire.

Les avantages de Yest sont mesurables : des tests plus smart, 40 % plus vite.

Depuis la version 4.0, Yest intègre la possibilité de faire appel à l’IA pour reprendre et uniformiser un patrimoine de tests existant / legacy (non conçu avec Yest). Ainsi, si vous souhaitez améliorer vos tests existants et en créer de nouveaux en profitant des avantages d’une conception visuelle des tests, l’IA dans Yest vous aidera à nettoyer les tests existants, à les paramétrer et, finalement, à les traduire en parcours graphiques.

Mais l’avenir s’annonce encore plus prometteur. À partir de la prochaine version, Yest intégrera un agent IA jouant le rôle de copilote. Il sera alors possible de créer des workflows et des tests à l’aide d’instructions dans le chat avec l’IA.

Exemple : reprenons la nouvelle US mentionnée ci-dessus. Avec l’IA dans Yest, il sera possible de demander où l’intégrer dans le parcours existant, d’ajouter des étapes de test et Yest corrigera automatiquement les scénarios.

Un point nous tient particulièrement à cœur : nous sommes fermement convaincus que les testeurs doivent garder le contrôle sur toutes les modifications.

L’IA ne doit pas se comporter comme une boîte noire ; la logique de son travail doit être exposée et explicite. Les modifications de type « big bang » sont en effet difficiles à vérifier et nécessitent un travail de validation considérable. C’est pourquoi, chez Smartesting, nous privilégions des étapes plus petites et traçables, dans un esprit de collaboration avec l’IA générative.

Abonnez-vous à la newsletter de Smartesting pour rester informé des évolutions de Yest.

Il ne fait aucun doute que la conception de tests est un cas d’usage particulièrement propice à l’IA.

Pour autant, derrière ces deux simples lettres « IA » se cache désormais une grande variété de solutions, tout comme le mot « test » regroupe de nombreux types de tests de nature et d’objectifs différents. Il s’agit donc, pour les équipes QA, de mettre en œuvre la solution IA la plus adaptée à chaque type de test à concevoir.

Pour les tests d’Epic, les tests E2E et les TNR, qui sont complexes et font appel à une profonde connaissance métier, le travail confié à l’IA doit être fortement guidé par l’humain et respecter les bonnes pratiques. Yest offre ce socle méthodologique qui garantit un apport optimal de l’IA.