Comment l'IA peut simplifier et accélérer les tests d'acceptation utilisateur ?

SECTION 1

Introduction

Les tests d'acceptation utilisateur (UAT) ont longtemps été le dernier gardien avant qu'un produit ne soit mis en ligne. C'est le moment où le caoutchouc rencontre la route, où les product owners et les parties prenantes business enfilent leur casquette d'utilisateur et testent une nouvelle fonctionnalité ou application. Mais pour beaucoup, ce processus critique ressemble moins à une passation en douceur qu'à un obstacle.

Cependant, l'IA a le potentiel de nous aider à surmonter ces obstacles et de faire des tests d'acceptation utilisateur une étape plus facile et moins difficile dans le processus de développement produit.

SECTION 2

Les points de douleur du processus UAT d'aujourd'hui

Avant de plonger dans le futur, reconnaissons les frustrations communes que nous connaissons tous. Le processus actuel d'UAT et de validation des fonctionnalités présente des limitations significatives.

### Un état d'esprit fonctionnel, pas technique

Un état d'esprit fonctionnel, pas technique, L'UAT est typiquement effectué par des personnes business qui sont expertes sur la fonctionnalité mais pas sur l'exécution du code. Elles comprennent ce que la fonctionnalité devrait faire, mais elles manquent du savoir-faire technique pour investiguer en profondeur quand quelque chose ne va pas. Parce qu'elles ne sont pas non plus bien versées dans les systèmes techniques, il devient difficile pour elles de tester de nouveaux scénarios.

Cette asymétrie d'information crée une frustration des deux côtés. Les testeurs business se sentent impuissants quand ils rencontrent des problèmes qu'ils ne peuvent pas diagnostiquer. Les équipes techniques se sentent interrompues par des demandes de support qui pourraient être évitées avec une meilleure outillage.

Chez Adservio, nous observons régulièrement ce pattern : un product owner découvre un comportement inattendu, ne peut pas déterminer si c'est un bug ou un comportement intentionnel, et doit interrompre l'équipe engineering pour clarification. Ce back-and-forth consomme un temps précieux et retarde la validation.

### Une dépendance envers l'équipe QA

Une dépendance envers l'équipe QA, Les équipes business ont souvent besoin de beaucoup d'aide de l'équipe d'assurance qualité (QA) juste pour exécuter leurs cas de test. Les équipes QA créent généralement les scénarios et les partagent avec les personnes UAT, et cela nécessite beaucoup d'accompagnement pour exécuter ces scénarios.

Cela crée un goulot d'étranglement et une dépendance qui ralentit tout le processus. Si un product owner veut tester un scénario spécifique, il doit typiquement attendre qu'un ingénieur QA soit disponible pour l'aider à naviguer dans l'environnement de test et exécuter les étapes nécessaires.

Ce modèle de "ticket support" pour les tests n'est pas scalable. À mesure que les produits deviennent plus complexes et les cycles de release plus fréquents, le volume de demandes de support UAT peut submerger les équipes QA, créant des retards et de la frustration.

### La course contre la montre

Dans la petite fenêtre de temps allouée pour l'UAT, les équipes business doivent s'assurer que tous les scénarios sont couverts. Cette pression peut conduire à des vérifications précipitées, des cas limites manqués et un produit final moins poli. Le volume pur de cas de test rend souvent impossible de tout couvrir manuellement et avec un temps limité.

Chez Adservio, nous avons observé des situations où les équipes business, sous pression de délais, ont dû prioriser drastiquement les tests, se concentrant uniquement sur les "happy paths" et ignorant les scénarios d'erreur ou les cas limites. Le résultat ? Des bugs découverts en production qui auraient pu être détectés lors de l'UAT si le temps et les ressources l'avaient permis.

SECTION 3

La solution propulsée par l'IA : LLMs et le Model Context Protocol (MCP)

Et si nous pouvions aborder ces problèmes et changer fondamentalement la façon dont l'UAT est effectué ? La réponse réside dans l'exploitation de la puissance des grands modèles de langage (LLMs) et d'un serveur Model Context Protocol (MCP).

### Repenser l'architecture des tests

Bien que les tests de fonctionnalités soient habituellement limités aux tests manuels, pour utiliser l'IA dans ce contexte, une approche différente est nécessaire. Spécifiquement, les équipes QA doivent écrire leurs cas de test de manière modulaire et fonctionnelle, qui peuvent être appelés et exécutés indépendamment.

Au lieu d'écrire de longs plans de test scriptés, les QA devront écrire des fonctions nettes, claires et réutilisables. Ce changement de mentalité est crucial : passer de "documenter les tests" à "architect des primitives de test".

Cette approche n'est pas nouvelle en soi. Le concept de fonctions de test réutilisables existe depuis longtemps dans l'automation des tests. Mais ce qui change avec l'IA, c'est la capacité des non-techniques à composer ces primitives via le langage naturel, sans avoir à comprendre la syntaxe de programmation ou l'architecture système.

SECTION 4

Comment cela fonctionne en pratique

Examinons un exemple pour voir comment cela fonctionne en pratique, considérons les tests de fonctionnalités pour une application de shopping en ligne. L'exigence serait, dans cet exemple, de tester les APIs qui permettent aux utilisateurs de se connecter, ajouter des articles à leur panier et soumettre la commande.

### Définir les primitives de test

Chacune de ces fonctions représente des actions ou scénarios spécifiques :

loginWithCredentials(username, password) ou submitOrder(items, shippingAddress)

Les QA devront mapper ces différents cas de test ou écrire de nouvelles fonctions pour tester différentes fonctionnalités. Par exemple :

loginAsNewUser() : Connecte un utilisateur nouvellement créé ; loginAsReturningUser(userId) : Connecte un utilisateur existant ; addItemToCart(itemId, quantity) : Ajoute un produit au panier ; removeItemFromCart(itemId) : Retire un produit du panier ; applyDiscountCode(code) : Applique un code promo ; navigateToCheckoutPage() : Navigue vers la page de checkout ; submitOrder(paymentMethod) : Finalise la commande

### Exposer les fonctions via un serveur MCP

Une fois créées, ces fonctions peuvent être exposées via un serveur MCP central. Ce serveur agit comme un pont, rendant les fonctions appelables par le LLM. Un product owner ou utilisateur business peut alors simplement écrire un scénario en langage naturel, comme :

"En tant que nouvel utilisateur, connecte-toi et vérifie que je peux ajouter trois articles à mon panier et procéder à la page de checkout."

Les LLMs ou modèles GenAI sont bons pour comprendre la question utilisateur et la diviser en tâches ou sous-questions subséquentes. La plupart des modèles GenAI Frontier sont également bons pour classifier l'intention utilisateur. Pour obtenir une plus grande précision, les modèles pourraient également être entraînés ou peuvent être augmentés à l'aide d'un système RAG.

Traduction et exécution, Le LLM traduit ensuite cette requête en une séquence d'appels de fonction au serveur MCP :

loginAsNewUser() ; addItemToCart('item1') ; addItemToCart('item2') ; addItemToCart('item3') ; navigateToCheckoutPage()

Le serveur MCP exécute ensuite ces fonctions et rapporte les résultats.

Soudainement, les personas UAT peuvent exécuter des tests complexes, end-to-end, sans avoir besoin d'aide constante de l'équipe QA. Ils sont autonomisés pour être des testeurs auto-suffisants, se concentrant sur les scénarios qui comptent le plus pour eux en tant qu'utilisateurs.

SECTION 5

Un nouvel état d'esprit pour l'assurance qualité

Avec cette approche, le rôle de l'équipe QA évolue de testeurs manuels à architectes d'un framework de test automatisé. Pour que cela fonctionne, la façon dont les équipes QA écrivent leurs fonctions doit changer.

Principes de conception des fonctions de test, Chaque fonction doit être conçue pour être appelée par un LLM. Cela signifie :

La clarté est reine : Les fonctions doivent être nommées clairement et de manière descriptive. Par exemple, verifySuccessfulPayment() est mieux que checkPay(). Le nom de la fonction doit communiquer sans ambiguïté ce qu'elle fait. Un LLM, comme un humain, s'appuie sur ces indices sémantiques pour comprendre quelle fonction utiliser pour quelle intention.

Informations pertinentes : Chaque fonction devrait avoir une docstring ou description claire et concise qui explique ce qu'elle fait, ses entrées et ses sorties attendues. C'est le contexte dont le LLM a besoin pour prendre des décisions intelligentes.

Un exemple de bonne documentation : pour une fonction addItemToCart(itemId, quantity) qui ajoute un article au panier de l'utilisateur connecté, la docstring précise le rôle de chaque paramètre (itemId, l'identifiant unique du produit à ajouter ; quantity, le nombre d'unités, qui doit être supérieur à zéro), la structure du résultat retourné (un dictionnaire avec un booléen success, le nouveau montant total du panier cartTotal, et un éventuel errorMessage), ainsi que les erreurs possibles (une ValueError si quantity est inférieure ou égale à zéro, une AuthenticationError si aucun utilisateur n'est connecté).

Cette documentation n'est pas qu'une bonne pratique pour les humains, elle est essentielle pour que le LLM comprenne quand et comment utiliser la fonction.

Définitions claires input/output : Les paramètres et valeurs de retour de la fonction doivent être explicitement définis. Ces données structurées sont ce qui permet au LLM et au serveur MCP d'exécuter les bonnes actions et de fournir un résultat significatif et compréhensible.

Le nouveau rôle de QA, En adoptant ces pratiques, les équipes QA peuvent construire une bibliothèque d'actions de test robuste, maintenable et lisible par les humains. Ce sont des fonctions modulaires qui permettent aux testeurs (UAT) d'exécuter des scénarios de test dans le langage du domaine business.

Cela transforme QA en plus que du testing, ils deviennent des enablers d'un processus UAT plus rapide et plus efficace. Le QA devient un rôle d'architecture et d'enablement plutôt qu'un rôle d'exécution répétitive.

Chez Adservio, nous observons que cette évolution du rôle QA est généralement bien accueillie par les équipes. Les professionnels QA sont souvent frustrés par les aspects répétitifs et manuels de leur travail. L'opportunité d'évoluer vers un rôle plus stratégique et technique, architect des frameworks plutôt qu'exécuteur de scripts, est attrayante pour beaucoup.

SECTION 6

Au-delà de l'efficacité : Nouvelles capacités

Cette approche ne fait pas que rendre les tests existants plus rapides. Elle débloque de nouvelles capacités qui étaient auparavant impratiques.

Tests exploratoires augmentés, Avec la barrière technique abaissée, les product owners peuvent effectuer des tests exploratoires beaucoup plus librement. Au lieu de se limiter aux scénarios pré-scriptés par QA, ils peuvent improviser, suivre leur intuition, tester des hypothèses spontanées.

"Que se passe-t-il si un utilisateur applique deux codes promo simultanément ?" "Et si quelqu'un change d'adresse de livraison après avoir initié le paiement ?" Ces questions peuvent maintenant être explorées immédiatement, sans attendre qu'un ingénieur QA écrive et exécute le scénario.

Tests de régression à la demande, Avant un release majeur, un product owner peut demander : "Teste tous les scénarios de checkout que nous avons validés le mois dernier pour confirmer qu'ils fonctionnent toujours."

Le LLM peut interpréter cette requête, identifier les fonctions de test pertinentes, les exécuter, et fournir un rapport de synthèse. Ce qui aurait pu prendre des heures de travail manuel peut maintenant être fait en minutes.

Tests guidés par des personas, Les product owners peuvent spécifier des personas utilisateur et le LLM peut adapter le comportement de test en conséquence.

"Teste le flow de checkout du point de vue d'un utilisateur senior qui n'est pas à l'aise avec la technologie, simule des hésitations, des erreurs de saisie typiques, et vérifie que les messages d'aide sont clairs."

Cette capacité à incorporer des nuances comportementales dans les tests crée une couverture plus réaliste des vrais scénarios utilisateurs.

@cite:cas-de-tests-generes-par-ia-a-partir-de-user-stories

SECTION 7

Défis et considérations

Bien que cette approche soit prometteuse, elle n'est pas sans défis.

Investissement initial, Construire une bibliothèque complète de fonctions de test bien documentées nécessite un investissement initial significatif. Les équipes QA devront refactorer les tests existants et développer de nouvelles primitives.

Chez Adservio, nous recommandons une approche incrémentale : commencer avec les flows critiques les plus fréquemment testés, démontrer la valeur, puis étendre progressivement la couverture. Cette approche permet de prouver le concept et de construire l'adhésion avant un investissement majeur.

Maintenance et évolution, À mesure que le produit évolue, la bibliothèque de fonctions de test doit évoluer avec lui. Les APIs changent, les flows sont refactorisés, de nouvelles fonctionnalités sont ajoutées. Maintenir l'alignement entre les fonctions de test et le système actuel nécessite discipline et processus.

Nous recommandons de traiter les fonctions de test comme du code de production : version control, code reviews, tests automatisés, documentation à jour. Les mêmes standards d'ingénierie qui s'appliquent au code produit doivent s'appliquer aux primitives de test.

Limites des LLMs, Les LLMs actuels, bien qu'impressionnants, ont des limites. Ils peuvent mal interpréter des requêtes ambiguës, composer des séquences de fonctions de manière sous-optimale, ou halluciner des capacités qui n'existent pas.

Les testeurs doivent rester vigilants et valider que les tests exécutés par l'IA correspondent vraiment à leurs intentions. Au moins initialement, un processus de "human-in-the-loop" où le LLM propose un plan de test pour approbation avant exécution est prudent.

@cite:shift-left-testing-benefices

SECTION 8

Conclusion : Du goulot d'étranglement au driver de qualité

En combinant la puissance des LLMs et une architecture serveur modulaire, nous pouvons transformer l'UAT d'un goulot d'étranglement frustrant en une phase efficace et collaborative. Les product owners peuvent maintenant tester les fonctionnalités de manière indépendante et avec vitesse, réduisant le temps jusqu'à la validation et garantissant des releases de meilleure qualité.

Le processus d'UAT et de validation passe d'un effort fragmenté et manuel à une expérience automatisée et pilotée par l'utilisateur. Ce n'est pas qu'une amélioration, c'est un changement fondamental dans la façon dont nous définissons et atteignons la qualité à l'ère de l'IA.

Chez Adservio, nous croyons que l'avenir des tests n'est pas "QA vs. IA" mais "QA enableurs d'IA". Les meilleurs ingénieurs QA ne seront pas remplacés par l'IA, ils deviendront les architects des frameworks qui permettent à l'IA d'amplifier la capacité de testing de toute l'organisation.

Cette vision demande un changement de mentalité, mais le bénéfice potentiel est énorme : des tests plus complets, des cycles plus rapides, une meilleure qualité, et des équipes plus épanouies qui passent moins de temps sur des tâches répétitives et plus de temps sur des problèmes complexes qui nécessitent jugement humain et créativité.

Note : Les déclarations et opinions exprimées dans cet article sont celles de l'auteur et ne reflètent pas nécessairement les positions d'Adservio.

FAQ

Questions fréquentes