Générer des cas de test avec l'IA : ce qui marche vraiment
Article 2 - Série : L'évolution de la QA avec l'IA
Générer des cas de test avec l'IA, c'est probablement le premier réflexe qu'ont les QA quand ils commencent à explorer le sujet. Et c'est logique : c'est visible, c'est concret, et le gain potentiel est immédiat. Passer de zéro à une liste de scénarios de test en trente secondes, ça a de quoi séduire.
Mais très vite, la déception pointe. Les cas générés sont trop génériques. Ils manquent de contexte. Ils répètent des choses évidentes et passent à côté des vraies subtilités métier. Et on se dit que finalement, c'était plus simple de les écrire soi-même.
Ce ressenti est courant. Et il cache une réalité importante : le problème n'est pas l'IA. C'est la façon dont on l'utilise. Générer de bons cas de test avec l'IA est une compétence qui s'apprend. Cet article vous donne les bases pour ne pas reproduire les erreurs les plus fréquentes et tirer le meilleur parti de l'outil.
Pourquoi les premiers essais déçoivent
La première erreur que font la plupart des QA quand ils testent la génération de cas de test par IA, c'est de soumettre une user story brute et d'attendre des miracles. Le prompt ressemble à quelque chose comme : « génère des cas de test pour cette user story » suivi d'un copier-coller. Et l'output est décevant.
Ce n'est pas surprenant. Un LLM fonctionne par inférence : il produit ce qui est statistiquement cohérent avec ce qu'il reçoit en entrée. Si l'entrée est pauvre, l'output l'est aussi. C'est le même principe que si vous demandiez à un consultant junior de rédiger un plan de test sans lui donner aucun contexte sur le produit, les utilisateurs, les risques ou l'environnement technique. Il ferait de son mieux, mais le résultat serait générique.
La bonne nouvelle, c'est que la solution est simple : enrichir le contexte. Plus vous donnez d'informations pertinentes à l'IA, plus elle produit des cas de test utiles. Ce n'est pas une question de puissance du modèle, c'est une question de qualité du prompt.
Les ingrédients d'un bon prompt de génération
Un prompt efficace pour générer des cas de test contient généralement quatre éléments : le rôle, le contexte, la demande et les contraintes.
Le rôle, c'est la façon dont vous cadrez l'IA. « Tu es un QA senior spécialisé dans les applications e-commerce » donne de meilleurs résultats que rien du tout. Le modèle adapte son niveau de détail et ses angles d'analyse en fonction du rôle qu'on lui assigne.
Le contexte, c'est tout ce qui permet à l'IA de comprendre dans quoi s'inscrit la fonctionnalité à tester : le type d'application, les utilisateurs concernés, les dépendances connues, les contraintes techniques ou réglementaires. Plus ce contexte est précis, plus les cas générés sont pertinents.
La demande doit être structurée. Plutôt que de dire « génère des cas de test », précisez ce que vous attendez : « génère des cas de test fonctionnels couvrant les scénarios nominaux, les cas limites et les cas d'erreur, en suivant le format Gherkin Given/When/Then ». La structure de la demande détermine la structure de l'output.
Les contraintes permettent de filtrer ce que vous ne voulez pas. « Ne génère pas de cas de test liés aux performances ou à la sécurité » ou « limite-toi aux cas testables manuellement » sont des précisions qui évitent de trier un volume inutile de résultats.
Un exemple concret, pas à pas
Prenons une user story simple pour illustrer la différence entre un prompt basique et un prompt structuré.
User story : En tant qu'utilisateur, je veux pouvoir me connecter avec mon email et mon mot de passe pour accéder à mon espace personnel.
Prompt basique : « Génère des cas de test pour cette user story. »
Résultat typique : trois ou quatre cas évidents : connexion réussie, mauvais mot de passe, email inconnu. Rien que vous n'auriez pas trouvé vous-même en deux minutes.
Prompt structuré : « Tu es un QA senior sur une application SaaS B2B. L'authentification utilise un système de tokens JWT avec expiration à 24h. Les utilisateurs peuvent avoir des rôles différents (admin, viewer, editor). Génère des cas de test couvrant : 1) les scénarios nominaux, 2) les cas limites (longueur des champs, caractères spéciaux), 3) les cas d'erreur (compte bloqué, token expiré, tentatives multiples), 4) les cas liés aux rôles utilisateurs. Format : Given/When/Then. »
Le résultat est radicalement différent. L'IA produit des scénarios sur l'expiration de session, le comportement après cinq tentatives échouées, la redirection selon le rôle, la gestion des caractères spéciaux dans le mot de passe... Des cas qu'un QA expérimenté aurait trouvés, mais qui auraient pris bien plus de temps à formaliser.
Ce que l'IA couvre bien, et ce qu'elle rate
Soyons honnêtes sur les forces et les limites de la génération automatisée.
L'IA excelle sur les cas standards et les cas limites prévisibles. Tout ce qui relève de la logique classique d'une fonctionnalité - les happy paths, les erreurs de saisie, les valeurs limites, les états vides - est bien couvert dès lors que le contexte est bien fourni. C'est là que le gain de temps est le plus significatif.
Elle se débrouille bien aussi sur la couverture de surface. Elle va rarement oublier un type de cas entier. Elle pense aux cas de déconnexion quand vous lui parlez de connexion, elle pense à la suppression quand vous lui parlez de création. Ce réflexe de couverture exhaustive est utile comme filet de sécurité.
En revanche, elle rate régulièrement les cas métier complexes qui nécessitent une connaissance profonde du domaine. Un cas de test qui croise deux règles métier contradictoires dans un contexte réglementaire spécifique, ou qui dépend d'un historique de données particulier : l'IA ne peut pas l'inventer si vous ne lui avez pas fourni ces informations. Elle ne devine pas votre logique métier, elle l'infère de ce que vous lui donnez.
Elle rate aussi ce qu'on pourrait appeler les tests d'expérience utilisateur : est-ce que ce parcours est fluide ? Est-ce que ce message d'erreur est compréhensible ? Est-ce que cet enchaînement d'écrans est logique ? Ces questions nécessitent un jugement humain que l'IA ne peut pas simuler.
Intégrer la génération IA dans votre workflow
La génération de cas de test par IA ne remplace pas le processus existant. Elle s'y intègre à une étape précise : la première ébauche.
Le schéma qui fonctionne le mieux en pratique est le suivant. Après le refinement, le QA rédige un prompt contextualisé à partir de la user story validée et des notes de session. Il soumet ce prompt à l'IA et obtient une première liste de cas. Il la passe ensuite en revue, élimine les doublons et les cas non pertinents, identifie les manques, et complète avec les cas métier spécifiques que l'IA n'a pas pu générer. La version finale est celle qui entre dans l'outil de gestion de tests.
Ce processus divise généralement par deux le temps de rédaction des cas de test sur les fonctionnalités standards. Sur les fonctionnalités complexes avec beaucoup de règles métier, le gain est plus limité mais la valeur de l'IA comme filet de couverture reste réelle.
Une précaution importante : ne jamais utiliser les cas générés sans les relire. L'IA peut produire des cas qui semblent corrects mais contiennent des hypothèses fausses sur le comportement attendu. Chaque cas doit être validé par quelqu'un qui connaît la fonctionnalité.
En résumé
Générer des cas de test avec l'IA fonctionne vraiment, à condition de ne pas attendre que l'outil fasse le travail à votre place. La qualité du prompt détermine la qualité de l'output. Un contexte riche, une demande structurée, des contraintes claires : voilà les trois leviers sur lesquels jouer. L'IA produit la première ébauche, le QA apporte le jugement et la connaissance métier. Ensemble, ils produisent plus vite et avec une meilleure couverture que chacun séparément.
FAQ
L'IA peut-elle générer des cas de test directement dans mon outil de gestion de tests ? Certains outils comme Xray, Zephyr ou qTest commencent à intégrer des fonctionnalités IA natives. Pour les autres, il faut une étape de copier-coller ou d'intégration via API. Des outils comme Notion AI ou Confluence AI permettent aussi de générer et structurer les cas avant import. Ce n'est pas encore totalement fluide partout, mais ça évolue vite.
Quelle est la différence entre générer des cas de test et générer des scénarios BDD ? Les cas de test classiques décrivent une action et un résultat attendu. Les scénarios BDD au format Gherkin (Given/When/Then) sont plus structurés et directement liés aux critères d'acceptance. L'IA gère bien les deux formats, il suffit de le préciser dans le prompt. Pour les équipes qui pratiquent le BDD, demander directement le format Gherkin est souvent plus efficace.
Comment éviter que l'IA génère des doublons ou des cas trop similaires ? En structurant la demande par catégories (nominal, limite, erreur, sécurité...) plutôt qu'en demandant une liste générale. Cette structuration force l'IA à couvrir des angles différents et réduit naturellement la redondance. Vous pouvez aussi demander explicitement : « assure-toi que chaque cas teste un comportement distinct ».
Peut-on utiliser l'IA pour générer des données de test en plus des cas de test ? Oui, et c'est même l'un des usages les plus efficaces. Demandez à l'IA de générer des jeux de données représentatifs pour vos cas limites : valeurs maximales, caractères spéciaux, formats invalides, combinaisons d'états. C'est une tâche répétitive et chronophage où l'IA est particulièrement à l'aise.
Les cas générés par l'IA sont-ils acceptables pour un audit ou une certification ? Les cas de test eux-mêmes, une fois relus et validés par un humain, sont tout à fait acceptables. Ce qui compte pour un audit, c'est la traçabilité (lien avec les exigences), la complétude (couverture des risques) et la qualité des résultats documentés, pas la façon dont les cas ont été rédigés initialement. L'IA est un outil de rédaction, pas un acteur du processus qualité.