De la User Story à l’exécution automatique des tests : j’ai testé un workflow IA dans Jira (Rovo + Xray + Lynqa)

Comme le montrent différentes enquêtes auprès des professionnels des tests logiciels (par exemple celle du CFTL – décembre 2025), l’utilisation de l’IA se développe dans de nombreuses organisations. Parmi les premiers cas d’usage cités figurent l’amélioration de la formulation des User Stories, la génération de cas de test et l’automatisation des tests. 

Les expérimentations de l’IA générative pour les activités de test ont d’abord été réalisées à travers des interfaces de chatbots IA conversationnels tels que ChatGPT ou Gemini. Ce mode de chatbot IA permet d’effectuer des expérimentations sur de nombreuses tâches de test en requêtant l’IA et en fournissant des données de contexte (généralement par copier-coller dans le « prompt »). 

Le mode chatbot IA permet d’évaluer la pertinence des réponses de l’IA (qui s’est grandement améliorée), mais il n’est pas viable de façon productive : un testeur ne va pas passer son temps à copier les données dans l’IA pour reprendre à la main, dans son outillage de test, les résultats de l’IA. 

Pour mettre en place l’IA pour les tests de manière opérationnelle et productive, il faut l’implémenter dans un processus fluide et intégré, tout en restant dans l’environnement de travail du testeur. C’est d’ailleurs le cas pour les développeurs : l’IA est intégrée à leur environnement de développement, comme VS Code avec GitHub Copilot.

Cette intégration de l’IA dans l’outillage de test est maintenant disponible dans de nombreux environnements et permet de réaliser un processus complet de test avec les assistants et agents IA disponibles. C’est par exemple le cas dans Jira, où de nombreuses applications sont disponibles pour assurer les services fondés sur l’IA.

L’expérience que nous relatons dans cet article porte sur l’enchaînement de trois cas d’usage de l’IA dans l’environnement Jira, avec Xray comme outil de test management et Lynqa pour l’exécution automatique des tests par l’IA.

Trois cas d’usage de l’IA pour les tests intégrés dans l’environnement Jira

Pour cette expérience, nous sommes dans Jira Cloud, au sein duquel j’utilise :

  • Rovo, l’assistant IA de Atlassian (éditeur de Jira) pour l’amélioration des tickets
  • Xray, outil de Test Management dans Jira qui intègre un assistant IA de génération de tests
  • Lynqa, un agent IA d’exécution des tests manuels (de Smartesting auquel appartient l’auteur de ces lignes).

Application testée et User Story

Pour cette expérience, j’ai utilisé une application web de petites annonces spécialement conçue pour l’expérimenter : https://demo.osclasspoint.com.

L’IHM de l’application est en anglais, mais, pour notre expérience, nous utilisons le français pour les US, les cas de test et le reporting de test. La fonctionnalité testée est la possibilité de noter (rating) et de commenter les petites annonces.


Passons en revue les différentes étapes : 1- Rédaction de la User Story avec l’IA, 2- Génération de cas de test avec l’IA et 3- Exécution de cas de test avec l’IA.

Rédaction de la User Story avec Jira Rovo

La rédaction des US est souvent un point de peine pour l’équipe agile, autant pour le PO, qui y consacre beaucoup de temps, que pour les QA, lorsque des informations nécessaires aux tests manquent, la rédaction n’est pas claire ou que certains critères d’acceptation ne sont pas testables.

Rovo est l’IA intégrée à Jira. Elle est disponible dès le premier niveau d’abonnement à Jira et intégrée pour faciliter la rédaction des tickets. Cela se présente avec deux possibilités :

  • Utiliser les tâches prédéfinies : amélioration de la rédaction, correction orthographique, raccourcir, traduire, résumer le texte, …
  • Utiliser l’invite de prompting pour requêter l’IA sur une tâche spécifiée par l’utilisateur.

Pour la rédaction de cette User Story, j’ai utilisé ces deux possibilités, car le mode est interactif et permet, par itérations successives, de clarifier, d’améliorer et de finaliser le descriptif de la User Story. La capture d’écran ci-dessous montre les actions prédéfinies.

Mon point de départ pour la formulation de la User Story est le suivant : “En tant qu’utilisateur connecté, je souhaite ajouter des commentaires et des notes aux petites annonces afin de partager mes impressions ou de poser des questions.

Voici un exemple de requête spécifique à l’IA lors de la rédaction de ma User Story :

Réponse de l’IA Rovo :

Mon retour d’expérience :

  • Globalement un apport clair et un gain de temps :
    • Les fonctions prédéfinies ont amélioré ma qualité rédactionnelle
    • Le prompting m’a donné quelques idées pour augmenter et préciser les critères d’acceptation
  • Lors des tâches IA libres (prompting par l’utilisateur), il s’agit d’un dialogue testeur/IA, et la fenêtre IA intégrée au descriptif n’est pas actuellement adaptée à ce mode d’usage.
  • Le modèle IA utilisé par Rovo n’est pas indiqué et n’est pas configurable facilement. Pour les actions spécifiques et complexes que j’ai demandées, Rovo m’est apparu un peu faible dans ses réponses. Par exemple, la recommandation ci-dessus sur l’indépendance n’est pas pertinente. Mais Rovo a le grand avantage d’utiliser les données de Jira et de Confluence, sans avoir à copier-coller ; c’est un vrai plus.

Bilan : Utiliser l’assistant Rovo pour les tâches courantes d’amélioration rédactionnelle des tickets est pertinent. L’utiliser pour des tâches d’approfondissement de l’expression du besoin est moins convaincant.

Au final, cette mise au point de mon US assistée par l’IA conduit à préciser neuf critères d’acceptation. Mon US est prête à passer en génération de tests assistée par l’IA.

Génération de cas de test avec Xray – AI test case generator

Les tests de User Stories visent une bonne couverture des critères d’acceptation. Ces cas de test des US sont souvent assez volatiles au sens où ils sont utilisés lors des phases de validation d’un sprint, mais pas au-delà. L’apport de l’IA consiste à accélérer leur création et à augmenter la couverture des critères d’acceptation de chaque US testée. Il est très facile, grâce à l’IA, de générer un grand nombre de ces cas de test. Mais, comme dans le cas d’usage précédent, c’est bien le testeur QA qui doit contrôler le processus, revoir et valider (ou non) chaque cas de test généré. L’augmentation du nombre de tests générés pose aussi le problème du temps nécessaire à leur exécution… résolu par l’exécution par agent IA des tests générés.

Dans Xray, l’assistant IA (en bêta) de génération de cas de test est accessible depuis le ticket US, dans la zone « Couverture de test », ainsi que depuis un ticket de test. Je lance l’assistant depuis mon ticket US, en choisissant le type « test manuel » et un prompt simple « Test US CLAS-5. Couvre les critères d’acceptation ». J’obtiens 57 objectifs de test pour ma User Story, classés par nature.

Je recommence en mettant l’accent sur les tests fonctionnels et les cas nominaux et alternatifs, ainsi que sur les cas d’erreur : j’atteins 53 cas de test. L’assistant IA de génération de cas de test de Xray vise la complétude et produit rapidement un grand nombre d’objectifs de test puis de cas de test rédigés.

Le cycle de cet assistant IA se décompose en trois temps : 1- Génération des objectifs de test (vérifiés et modifiés par l’utilisateur) –> 2- Génération des cas de test sur le périmètre choisi (vérifiés et modifiés par l’utilisateur) –> 3- Création des tickets « Test » associés à la User Story testée.

La capture d’écran ci-dessous montre un extrait des tests générés, avec la création de tickets « test » dans le backlog.

Voici l’en-tête puis le corps du test CLAS-35, constitué de 4 étapes de test.

Mon retour d’expérience :

  • Le cycle de génération de tests est bien réalisé, avec une première phase portant sur les objectifs de test, un choix des priorités par le testeur, puis la génération des cas de test, la vérification et la correction par le testeur, et enfin la création des tickets « Test » qui seront vérifiés et modifiés individuellement.
  • La logique de l’assistance IA incite à une inflation des cas de test, ce qui soulève évidemment le problème de leur exécution (l’équipe aura-t-elle le temps pour cela) ?

Bilan : On voit apparaître une nouvelle façon de travailler pour les équipes QA, avec un pilotage de l’IA, ainsi que la vérification et la modification de ses sorties. À cela s’ajoute un travail de priorisation et de sélection, et potentiellement de convergence, entre les tests proposés par l’IA. La maîtrise de ce processus de création de tests assistée par l’IA requiert une double expertise des testeurs : en conception de tests et sur l’application testée, afin de piloter correctement l’IA.

Exécution des tests avec l’agent IA Lynqa

Dans une série de deux articles précédents, j’ai présenté les agents IA pour exécuter les tests sur IHM. La partie 1 en décrit l’architecture et le fonctionnement général, et la partie 2 montre, de façon concrète et pas à pas, l’utilisation de l’exécution par l’IA avec Lynqa.

Comme le montre la capture d’écran ci-dessous, l’exécution automatique par un agent IA est lancée dans le ticket « Test exec », lié à mon cas de test CLAS-35 généré précédemment.

L’exécution réalisée par un agent IA se déroule de manière analogue à une exécution effectuée par un testeur humain, sur l’IHM, avec, à chaque pas de test, la réalisation des actions et vérifications demandées. La capture ci-dessous montre un extrait de l’exécution Lynqa sur la fiche « Test exec » précédente. Aucune retouche au cas de test n’est réalisée ; l’agent exécute et restitue chaque pas de test exécuté avec l’énoncé des actions réalisées, l’analyse des vérifications des résultats attendus et les captures d’écran dans les deux cas.

L’exécution du cas de test a donné un résultat de succès ; pour chaque étape du test, les actions ont été réalisées et les résultats attendus ont été vérifiés. La capture d’écran suivante, fournie en preuve de vérification lors de l’étape 2, montre que le commentaire saisi est bien enregistré.

La publication du résultat des tests, avec le reporting complet depuis Lynqa dans Xray, est réalisée par le testeur, qui conserve la décision de statut du test après vérification de l’exécution. La capture d’écran montre le choix de cette publication dans l’interface Jira avec Xray et Lynqa.

Cette publication sur Xray propage l’ensemble des étapes d’exécution réalisées avec l’agent IA dans la fiche « Test exec » correspondante, ce qui permet aussi d’actualiser le statut du test dans la traçabilité avec la User Story. L’enchaînement est très fluide : génération de cas de test avec l’IA –> exécution par un agent IA.

L’agent IA a exécuté parfaitement le test généré par Xray sans aucune modification humaine préalable.

En conclusion

Cette expérience d’enchaînement de trois assistants IA dans Jira démontre que nous avons franchi un cap vers un processus intégré et fluide pour le test des US assistés par l’IA.

  • Sur la formulation des US : Rovo, bien qu’encore perfectible en termes d’ergonomie pour les tâches complexes, apporte la puissance de l’accès aux données natives du projet.
  • Sur la génération des cas de test de User Story : l’assistant de Xray offre une force de frappe indéniable pour la couverture, générant des dizaines de tests en quelques secondes, même si cette « inflation » exige un pilotage humain rigoureux.
  • Concernant l’exécution automatique des cas de test : en toute transparence, comme contributeur de Lynqa, je constate avec satisfaction la fluidité de la dernière étape. Sur l’ensemble de mes essais, l’agent a pu exécuter les tests générés par Xray, dans la plupart des cas sans retouches, et parfois avec des retouches mineures.

Au final, pour ces trois activités assistées par l’IA, la conclusion reste la même : les testeurs ne sont pas remplacés.

Leur rôle évolue vers celui d’architectes des activités de test et de superviseurs de l’IA. L’enchaînement automatique des trois tâches par l’IA, sans maîtrise humaine et donc sans contrôle, n’est ni réaliste ni souhaitable, car le résultat en matière d’identification d’anomalies serait très incertain. Mais l’apport au flux de travail QA et au gain de temps pour l’équipe apparaît clairement.

Et vous, où en êtes-vous dans l’intégration de l’IA au sein de votre processus et outillage de test ?

L’intégration de l’IA dans nos outils du quotidien (Jira, Xray, Azure DevOps…) évolue très vite. Avez-vous déjà testé ces assistants pour la rédaction, la génération de tests et l’exécution automatique des tests ?

Partagez votre expérience ou vos doutes en commentaire ci-dessous ; le débat est ouvert !

À propos de l’auteur

Bruno Legeard dirige le Lab IA de Smartesting (éditeur de Lynqa). Expert en test logiciel et membre du CFTL, il contribue activement à la définition de la certification ISTQB CT-GenAI « Tester avec l’IA générative ».

4 réponses

  1. Merci pour cet article très instructif mais aussi « rassurant ».
    L’enchainement de différents agents IA ayant chacun son propre périmètre est sans aucun doute le chemin à suivre afin de gagner en qualité tout en gardant le contrôle.
    Le rôle du QA change, tout comme au début de l’autom, le rôle du testeur à changé.

    1. Merci pour le retour. Le point important bien souligné dans le commentaire (et l’article) : pas de testeur expérimenté = pas d’intérêt à l’IA.

      L’IA apporte une (forte) plus value lorsque les assistants sont pilotés et orchestrés par un professionnel expérimenté des tests. Cela a été mon expérience lors du déroulé que je relate dans l’article.

  2. Intéressant comme démonstration. Quelques questions techniques sur la chaîne cependant.

    Rovo « challenge et complète » l’US …

    Sur quelle base factuelle valide-t-on que ce qu’il ajoute est correct et pas simplement plausible ?
    Rovo travaille à partir du contexte Jira, mais il ne connaît ni les règles métier implicites, ni ce que le PO avait en tête.
    Tout le reste de la chaîne hérite de ces hypothèses non validées.

    Xray IA génère les tests :
    A partir du texte de l’US,, pas d’une analyse de risques ni de la connaissance des cas limites du système.
    Un QA expérimenté conçoit ses tests à partir de son modèle mental du système, pas uniquement d’un texte.
    Quel taux de couverture réel vs. un QA senior sur la même US ?

    Le fond du problème : dans une chaîne IA → IA → IA, chaque maillon propage et amplifie les approximations du précédent sans contrôle humain intermédiaire. En ingénierie, c’est la propagation d’erreur.

    Cela ne va donc que si le PO ou la source en entrée est parfaite. Non?

    Si je peux me permettre, on est loin de toute fiabilité le jour où on lances ça sur un ERP avec des règles métier implicites, des droits par profil et des données de test complexes. ( surtout pour ROVO et XRAY)

    1. Merci Julien pour les éléments. Ton commentaire rejoint mon expérience vécue. En deux mots, j’ai travaillé pour expliciter ma User Story et l’apport de l’IA ma fait gagner tu temps sur la clarté des formulations et la complétude des critères d’acceptations. De même pour la génération des cas de test, je suis rentré dans le détail des propositions d’objectfs et dans la génération des cas détaillé. Sur ce 2ème cas d’usage, mon expérience est très positive dans le ratio complètude / temps. De plus, l’exécution par agent IA, revue humainement, est aussi une validation du la formulation du cas de test.

      Bref, chaque étape est pilotée par les compétences humaines, mais mon constat est d’un apport important tant en gain de temps qu’en qualité des artefacts de test.

Laisser un commentaire

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

Bug

Les 7 principes du test: les tests montrent la présence de défauts (1/7)

Nouvelle série dans la taverne! Dans cette série vous pourrez trouver dans chaque article une présentation d’une des 7 principes fondamentaux du test. Les tests montrent la présence de défaut Description Ce principe rappelle que les tests servent de détecteur de défaut. Par défaut vous pouvez comprendre « imperfection dans le

Lire la suite »
Agilité

20 : De l’ATDD pratiquée manuellement à l’ATDD automatisée (2 / 2)

Terminons notre conclusion sur l’ATDD manuelle et l’ATDD automatisée : Structuration de la documentation et outillage Normalement une US INVEST donne lieu à une fonctionnalité dans le produit, c’est-à-dire “une tâche métier”. Les “corrections de spécification” devraient être traitées comme pour les bugs. Ce sont des tickets à évaluer, attachés

Lire la suite »
ATDD

5- Illustrer et appréhender les concepts

Prenons l’US INVEST classique “S’authentifier de manière simple” destiné à un client ou un prospect déjà identifié.  Cela signifie que, dans le sprint prévu, le choix qui a été fait est de pouvoir s’authentifier par identifiant et mot de passe, avec 3 tentatives maximum, mais que l’utilisateur ne peut pas

Lire la suite »