Apprendre à prompter: IA pour les tests
Gagner en productivité et en vélocité avec l’IA générative
Apprendre à prompter est devenu indispensable! Les attentes sur l’IA générative pour les tests logiciels portent principalement sur des gains de productivité et de vélocité. Il s’agit de réaliser plus vite et avec moins d’effort les tâches de tests grâce à l’IA. Ces attentes sont bien illustrées par l’enquête annuelle World Quality Report 2023”, dont la figure suivante est extraite : l’amélioration de la productivité et une plus grande vélocité ressortent respectivement à 65% et 53% dans les réponses des participants à cette enquête.
Ces résultats sont aussi conformes aux attentes exprimées par les participants aux sessions de formation “Accélérer vos processus de test grâce à l’IA générative” proposées par Smartesting avec ses partenaires. Par la pratique, les participants viennent acquérir les savoir-faire essentiels pour utiliser de façon productive une IA générative, apprendre à prompter de façon efficace et obtenir effectivement les gains de productivité et de vélocité attendus.
Car pour obtenir ces gains de productivité et de vélocité en utilisant l’IA générative, il faut apprendre à prompter avec les modèles d’IA. C’est ce que nous allons présenter ici, mais l’acquisition des savoir-faire requis nécessite de pratiquer et d’évaluer sa pratique ainsi que nous le faisons lors de la formation.
Modèles LLM : des progrès rapides utiles pour les activités de test
L’IA générative peut être utilisée de façon directe, au travers d’un Chatbot IA, par des requêtes (les prompts) en mode conversationnel avec un LLM – Large Language Model, ou bien pour des tâches prédéfinies au travers d’un outil de test qui fait appel à un LLM.
Cet article porte sur le premier mode, c’est-à-dire le requêtage d’un LLM pour des tâches de test, car ce mode est directement accessible via les Chatbot IA disponibles, et permet une grande souplesse d’usage pour les testeurs.
Depuis la sortie de ChatGPT par OpenAI en novembre 2022, l’offre en matière de LLM s’est considérablement développée et leur capacité progresse de façon rapide.
Ces progrès apportent des opportunités d’usage pour les tests logiciels donc voici quelques exemples :
- Le module vision, présent dans les principaux LLM actuels, tels que GPT-4o, Claude-3 ou Gemini-1.5, permet l’analyse d’images, par exemple des captures d’écran de l’application à tester. Nous pouvons ainsi associer des données textuelles (user stories, critères d’acceptation, rapports d’anomalies, …) avec des captures d’écran (de l’application, de messages d’erreurs, …) pour une meilleure précision des données fournies au LLM.
- L’optimisation des modèles LLM s’est renforcée, permettant un traitement plus rapide, et moins coûteux de nos requêtes, à performances égales. Claude-3.5-Sonnet ou GPT-4o-Mini sont des exemples de sorties récentes de LLM à la fois performants, moins consommateurs de ressources de calcul et plus rapides que les versions précédentes en termes de temps de réponse du modèle.
- La disponibilité accrue de modèles LLM avec licence open-source ou communautaire tels que Mixtral-8x22B ou LLama-3, facilite à la fois l’intégration de l’IA générative sur des ressources de calcul restreintes à l’organisation, et permet d’éviter des modèles coûteux d’abonnement.
Des performances en progrès rapide, de nouvelles fonctionnalités et une accessibilité renforcée : à nous maintenant d’exploiter ces capacités des LLM en maîtrisant les bonnes pratiques du requêtage – appelées aussi “Prompt Engineering” ou “Prompting”.
Apprendre à prompter pour les activités de test
Les techniques de Prompting vise la conception de requêtes de qualité qui guident les modèles LLM pour produire des sorties précises et pertinentes pour la tâche réalisée. Il s’agit de travailler la structure, le style et le contenu des requêtes, d’optimiser leur longueur en fonction de la tâche de test à réaliser par le LLM. Vos résultats vont dépendre du modèle LLM utilisé et de vos prompts.
Voici les techniques que nous passons en revue dans cet article, avec illustration sur des tâches de génération de tests :
- Prompt structuré en 6 parties : Rôle, Contexte, Instructions, Contraintes, Format, Données ;
- Décomposer les instructions en étapes pour aider le modèle ;
- Demander au modèle de vérifier ses résultats ;
- Méta-requêtage : demander au modèle d’évaluer, d’améliorer ou de générer votre prompt
Ces techniques sont simples à utiliser, mais essentielles pour obtenir de bons résultats des modèles d’IA générative, en particulier dans notre domaine des tests logiciels qui requiert précision et complétude dans les résultats.
Mise en œuvre pour générer des cas de test pour une User Story et des critères d’acceptation
Notre objet de test est l’application de démonstration de la plateforme open-source Spree Commerce, qui propose une structure front-end / back-end pour développer son commerce en ligne. La User Story qui sert de base pour notre génération de cas de tests est la gestion du panier dont voici l’image écran.
Image écran du panier – obtenu avec l’application de démonstration Spree Commerce – https://spree-multi-vendor-demo.herokuapp.com/ – Juillet 2024
Voici la User Story “Gestion des articles du panier” que nous allons tester, avec ses critères d’acceptation :
En tant que client du site e-commerce,
Je veux pouvoir modifier la quantité des articles dans mon panier,
Afin de voir les prix et le total du panier se mettre à jour en conséquence.
Critères d’acceptation :
- La quantité d’un article doit pouvoir être modifiée en utilisant les boutons « – » et « + ».
- La mise à jour de la quantité d’un article doit être immédiate.
- Le total par article doit être mis à jour immédiatement après modification de la quantité (prix unitaire * quantité).
- Le sous-total du panier (somme des totaux par article) doit être mis à jour immédiatement après toute modification de la quantité d’un ou plusieurs articles.
- Chaque ligne d’article doit avoir une icône de poubelle pour permettre la suppression de l’article du panier.
- La suppression d’un article du panier doit mettre à jour le sous-total du panier immédiatement.
Voici le prompt structuré que nous utilisons :
« #Rôle et contexte
Tu es mon assistant pour l’écriture de scénarios de test en format Gherkin (Étant donné que / Quand / Alors) à partir d’une User Story donnée et de critères d’acceptation. Une capture d’écran correspondant à la page testée est aussi fournie.
#Instructions, format et contraintes
En analysant ces éléments, réalise les tâches suivantes :
– Détermine de manière exhaustive les classes d’équivalence à tester, en donnant quelques exemples de valeurs typiques et aux limites pour les classes valides et invalides. Explique ton raisonnement.
– Crée les scénarios de test au format Gherkin dans un fichier <nom_feature>.feature. Couvre l’ensemble des critères d’acceptation donné, et utilise la capture écran pour déterminer les données de test.
#Auto-vérification du résultat
Vérifie que les différents critères d’acceptation sont totalement couverts et complète si cela n’est pas le cas.
#Données
<Insérer la User Story et les critères d’acceptation.>
Télécharger la capture d’écran.«
Voici les résultats obtenus avec le LLM Claude-3.5-Sonnet (daté Juillet 2024) :
Pour cette User Story « Gestion des articles du panier », voici l’analyse des classes d’équivalence et les scénarios de test correspondants :
Classes d’équivalence :
- Quantité d’articles :
- Valide : entiers positifs (1, 2, 3, …)
- Invalide : 0 ou négatif (non visible dans l’interface, mais à considérer)
- Limite : très grand nombre (ex: 9999)
- Prix unitaire :
- Valide : nombres positifs avec deux décimales (53.99, 36.99, …)
- Invalide : négatif ou trop de décimales (non visible dans l’interface, mais à considérer)
- Nombre d’articles dans le panier :
- Valide : 1 à n articles
- Cas limite : panier vide (0 article)
- Actions sur les articles :
- Augmenter la quantité
- Diminuer la quantité
- Supprimer l’article
Voici le contenu du fichier gestion_panier.feature :
# gestion_panier.feature
# language: fr
Fonctionnalité: Gestion des articles du panier
Contexte:
Etant donné que je suis sur la page du panier
Et que mon panier contient les articles suivants :
| Produit | Prix unitaire | Quantité | Total |
| Checked Shirt | 53.99 | 1 | 53.99 |
| Polo T Shirt | 36.99 | 2 | 73.98 |
Scénario: Augmenter la quantité d’un article
Quand j’augmente la quantité du « Checked Shirt » de 1
Alors la quantité du « Checked Shirt » doit être 2
Et le total pour le « Checked Shirt » doit être 107.98
Et le sous-total du panier doit être 181.96
Scénario: Diminuer la quantité d’un article
Quand je diminue la quantité du « Polo T Shirt » de 1
Alors la quantité du « Polo T Shirt » doit être 1
Et le total pour le « Polo T Shirt » doit être 36.99
Et le sous-total du panier doit être 90.98
Scénario: Tenter de diminuer la quantité d’un article à zéro
Quand je diminue la quantité du « Checked Shirt » de 1
Alors la quantité du « Checked Shirt » doit rester à 1
Et le sous-total du panier doit rester inchangé
Scénario: Supprimer un article du panier
Quand je clique sur l’icône de suppression du « Checked Shirt »
Alors le « Checked Shirt » doit être retiré du panier
Et le sous-total du panier doit être 73.98
Scénario: Vérifier la mise à jour immédiate après modification de quantité
Quand j’augmente la quantité du « Polo T Shirt » de 1
Alors le total pour le « Polo T Shirt » doit être immédiatement mis à jour à 110.97
Et le sous-total du panier doit être immédiatement mis à jour à 164.96
Scénario: Ajouter une grande quantité d’un article
Quand j’augmente la quantité du « Checked Shirt » de 98
Alors la quantité du « Checked Shirt » doit être 99
Et le total pour le « Checked Shirt » doit être 5345.01
Et le sous-total du panier doit être 5418.99
Scénario: Vérifier que tous les articles ont une icône de suppression
Alors chaque ligne d’article doit avoir une icône de poubelle visible
Auto-vérification :
Les scénarios couvrent tous les critères d’acceptation mentionnés :
- Modification de la quantité avec les boutons « + » et « -«
- Mise à jour immédiate de la quantité
- MAJ immédiate du total par article
- Mise à jour immédiate du sous-total du panier
- Présence de l’icône de poubelle pour chaque article
- Mise à jour du sous-total après suppression d’un article
Les scénarios incluent également des cas limites comme la tentative de diminuer la quantité à zéro et l’ajout d’une grande quantité. Tous les scénarios utilisent les données visibles dans la capture d’écran fournie.
Analyse des résultats obtenus par l’IA
Plusieurs constats ressortent des résultats obtenus à partir du Prompt structuré est des données fournies. Nous proposons une analyse sur différents aspects de la qualité des tests.
Données de test et variabilité des scénarios
On constate que l’ajout de la capture d’écran de la page à tester (le panier), capturée en environnement de test, permet au modèle de déterminer des données de test précises, faisant référence à celles visualisées sur le scénario. C’est très pertinent, et cela permet de gérer cette variabilité de façon dynamique car il suffira de changer la capture d’écran, faisant apparaître d’autres articles dans le panier pour obtenir des scénarios Gherkin avec une variabilité différente.
Rédaction des scénarios en Gherkin et complétude de la couverture des critères d’acceptation
Voici quelques constats à l’analyse des scénarios Gherkin générés par le LLM :
- Couverture des critères d’acceptation : la couverture des critères d’acceptation est bonne, et conforme à ce qui est demandé dans le Prompt. Le découpage des instructions en deux parties, l’une pour les classes d’équivalence et l’autre pour la génération des
- Calcul des résultats attendus : lorsque l’on vérifie manuellement ce résultat, on constate que les calculs des résultats attendus sont corrects pour la totalité des scénarios de test : le calcul des champs “Total” et “Sous-total” pour l’établissement du verdict est juste.
- Utilisation de la clause “Contexte” : le « Contexte » dans Gherkin définit les conditions initiales communes à tous les scénarios d’une fonctionnalité, évitant la répétition et améliorant la lisibilité. Il établit l’environnement de test de base, permettant aux scénarios individuels de se concentrer uniquement sur leurs actions et vérifications spécifiques. Le contexte généré par le LLM s’appuie totalement sur la capture écran. Cela permettrait une mise à jour dynamique en fournissant une autre capture d’écran à analyser au LLM dans les données du Prompt.
Le bilan est donc de 7 scénarios corrects, précis et directement alignés sur les données fournies (User Story avec ses critères d’acceptation, Capture d’écran).
Ce bilan est positif vis-à -vis de nos attentes de productivité et de vélocité : le prompt proposé est générique et les données de la User Story et de la capture d’écran sont faciles à obtenir. Le résultat est obtenu en quelques secondes avec un LLM et la vérification prend quelques minutes. Ce résultat permet d’itérer avec le LLM, par exemple pour demander des scénarios complémentaires et d’élargir la couverture des critères d’acceptation si souhaité.
Méta-requêtage : amélioration du prompt par le LLM
Le méta-requêtage consiste à demander au LLM des améliorations sur un prompt initial. Cette technique apporte un gain de temps grâce à des suggestions qui facilitent la mise au point du prompt par essais successifs. Les suggestions du LLM aident à clarifier et préciser les instructions, réduisant les ambiguïtés et optimisant les résultats en identifiant et corrigeant les lacunes pour des résultats plus pertinents.
Voici un prompt de méta-requêtage pour notre prompt de génération de scénarios Gherkin vu précédemment :
#Instructions
Voici un prompt pour générer des scénarios de test au format Gherkin. Analyse ce prompt et propose des améliorations éventuelles.
#Prompt à analyser
<Copier-coller le prompt à analyser et à améliorer>
Avec Claude-3.5-Sonnet, voici le résultat de cette méta-requête :
Votre prompt pour générer des scénarios de test au format Gherkin est déjà bien structuré et couvre les éléments essentiels. Cependant, je peux suggérer quelques améliorations potentielles pour le rendre encore plus efficace :
1. Clarification du contexte :
– Ajoutez une brève explication du format Gherkin pour s’assurer que l’assistant comprend bien la structure « Étant donné que / Quand / Alors ».
– Précisez si des connaissances spécifiques du domaine métier sont nécessaires.
2. Détail des instructions :
– Ajoutez une étape pour identifier les préconditions communes à plusieurs scénarios.
– Demandez explicitement de varier les cas de test (cas nominaux, limites, erreurs).
– Suggérez d’utiliser des tables d’exemples pour les scénarios similaires avec des données différentes.
3. Format de sortie :
– Précisez la structure exacte attendue pour le fichier .feature (en-tête, description, etc.).
– Demandez d’inclure des tags pour catégoriser les scénarios (ex: @smoke, @regression).
4. Amélioration de l’auto-vérification :
– Ajoutez une vérification de la couverture des classes d’équivalence identifiées.
– Demandez une estimation de la couverture globale des tests (en pourcentage).
5. Gestion des données de test :
– Précisez comment gérer les données sensibles ou confidentielles.
– Demandez de proposer des données de test réalistes mais fictives.
6. Considérations supplémentaires :
– Ajoutez une demande de suggestions pour des tests non-fonctionnels pertinents (performance, sécurité, etc.).
– Demandez d’identifier les potentielles dépendances ou prérequis pour l’exécution des tests.
Voici une version améliorée du prompt :
# Rôle et contexte
Tu es mon assistant pour l’écriture de scénarios de test en format Gherkin à partir d’une User Story donnée et de critères d’acceptation. Une capture d’écran correspondant à la page testée est aussi fournie.
Le format Gherkin utilise les mots-clés « Étant donné que » (Given), « Quand » (When), et « Alors » (Then) pour structurer les scénarios de test de manière compréhensible.
# Instructions, format et contraintes
En analysant ces éléments, réalise les tâches suivantes :
1. Détermine de manière exhaustive les classes d’équivalence à tester :
– Donne des exemples de valeurs typiques et aux limites pour les classes valides et invalides.
– Explique ton raisonnement pour chaque classe identifiée.
2. Identifie les préconditions communes à plusieurs scénarios.
3. Crée les scénarios de test au format Gherkin dans un fichier <nom_feature>.feature :
– Couvre l’ensemble des critères d’acceptation donnés.
– Utilise la capture d’écran pour déterminer les données de test réalistes mais fictives.
– Varie les cas de test (nominaux, limites, erreurs).
– Utilise des tables d’exemples pour les scénarios similaires avec des données différentes.
– Inclus des tags pertinents pour catégoriser les scénarios (ex: @smoke, @regression).
4. Structure le fichier .feature comme suit :
– En-tête avec le nom et la description de la fonctionnalité
– Tags au niveau de la fonctionnalité si nécessaire
– Scénarios avec leurs tags respectifs
5. Propose des suggestions pour des tests non-fonctionnels pertinents (performance, sécurité, etc.).
6. Identifie les potentielles dépendances ou prérequis pour l’exécution des tests.
# Auto-vérification du résultat
– Vérifie que les différents critères d’acceptation sont totalement couverts et complète si nécessaire.
– Assure-toi que toutes les classes d’équivalence identifiées sont testées.
– Estime le pourcentage de couverture globale des tests.
# Gestion des données de test
– Utilise des données de test réalistes mais fictives.
– Évite d’inclure des données sensibles ou confidentielles.
# Données
<Insertion ici de la User Story et des critères d’acceptation>
<Téléchargement de la capture d’écran à analyser pour générer les scénarios Gherkin>
Cette version améliorée du prompt devrait permettre de générer des scénarios de test plus complets, structurés et adaptés à vos besoins.
Note explicative sur le choix du LLM et sur les expériences réalisées
Le choix du LLM s’est porté sur Claude-3.5-Sonnet car il s’agit d’un modèle d’IA générative qui permet de bonnes performances pour les activités de test en combinant texte et capture d’écran dans la requête. La version utilisée est celle du 20 juin 2024. Nous avons utilisé le portail LLM de Smartesting pour les différentes requêtes réalisées. Ce portail interne à Smartesting à une vocation pédagogique et est utilisé pour l’apprentissage des techniques de prompting. Le portail donne accès à plus de 12 LLM, les plus pertinents pour automatiser des activités de test.
Conclusion
Dans cet article, nous avons illustré l’importance d’apprendre à prompter pour obtenir des bons résultats avec une IA générative pour les activités de tests logiciels. L’exemple que nous avons utilisé est une activité courante de conception et de rédaction de scénarios de test au format Gherkin. Sur d’autres tâches de test, tels que l’analyse de User Stories, l’optimisation de cas de tests existants, la génération de scripts de tests automatisés, l’analyse de rapports d’anomalies, le même constat sera réalisé : pour obtenir de bons résultats et utiliser efficacement l’IA générative, il faut maîtriser les techniques du prompting.
Maîtriser les techniques du Prompting est accessible à tous les testeurs, et sera de plus en plus utilisé au fur et à mesure que les Chatbot IA seront accessibles dans les entreprises et que leur usage rentrera dans le quotidien des testeurs pour gagner en productivité et en vélocité.
Il s’agit d’un savoir-faire qui s’acquiert par la formation et par la pratique. Apprendre à prompter est l’un des objectifs de la formation “Accélérer vos processus de test grâce à l’IA générative”. Notre formation propose 8 ateliers sur des cas d’usage des tests logiciels, donne accès pour pratiquer à 12 LLM différents, sous licence open-source ou licence commerciale, et présente les différentes techniques de prompting utiles pour les tests logiciels, étudiées et expérimentées lors des ateliers. Près des 2/3 de la formation est consacré à la pratique guidée, permettant d’acquérir ce savoir-faire nécessaire au bon usage de l’IA générative pour les tests logiciels.