À propos de ces exemples
Les maquettes, les règles de gestion et les réponses générées sont construites pour l'exercice. Elles sont volontairement fictives.
Les vrais échanges avec l'IA, surtout en fonction du modèle, varient beaucoup.
01 — Avant de commencer
Comment lire ces exemples
Chaque cas commence par le contexte, la maquette de l'écran concerné et ses règles de gestion, puis montre deux échanges complets pour une même activité de test.
Les maquettes, les règles de gestion et les réponses présentées ici sont fictives et construites pour l'exercice. Elles illustrent un comportement typique observé avec les IA génératives actuelles.
02 — Cas par cas
Sept échanges commentés
Plusieurs exemples, deux façons de le prompter.
01 Analyse des exigences
Prompt système et prompt utilisateur
Analyse des exigences
Paiement de votre commande
La personne testeuse dispose de la maquette de l'écran de paiement et des règles de gestion rédigées par l'analyse métier. Deux de ces règles ne disent pas la même chose.
- RG-01Section 2. La personne dispose de trois tentatives de paiement. Au troisième refus consécutif, le compte est temporairement bloqué.
- RG-02Section 2. Le cryptogramme n'est jamais conservé, même lorsque la carte est enregistrée.
- RG-03Section 4, tableau des messages. Le message "Compte temporairement bloqué" s'affiche dès la deuxième tentative échouée.
- RG-04Section 4. Une carte expirée déclenche le message "Carte refusée", sans décompte de tentative.
Prompt sans prompt système ▼
Cette spécification semble globalement claire. Le parcours décrit la saisie de la carte, la validation puis la confirmation du paiement.
Quelques points d'attention classiques méritent d'être vérifiés.
- La gestion des erreurs de paiement
- La sécurité des données bancaires
- L'expérience utilisateur sur mobile
- Les performances lors des pics de commandes
Dans l'ensemble, le document paraît bien structuré et prêt à être testé.
La réponse s'appliquerait à n'importe quelle spécification de paiement. Elle ne relève aucune des quatre règles fournies et passe complètement à côté de la contradiction entre RG-01 et RG-03.
Prompt système et prompt utilisateur ▼
Afficher la réponse obtenue
Trois problèmes bloquants ressortent de la comparaison des règles fournies.
| Constat | Règles concernées | Conséquence pour les tests |
|---|---|---|
| Le seuil de blocage diffère, trois tentatives contre deux | RG-01 et RG-03 | Le comportement attendu à la deuxième tentative échouée est ambigu. |
| La durée du blocage temporaire n'est jamais donnée | RG-01 | Impossible de tester la fin du blocage ni de savoir si une nouvelle tentative doit être acceptée au bout de quinze minutes ou de vingt-quatre heures. |
| Le sort du compteur de tentatives après un paiement réussi n'est pas précisé | RG-01 | Le scénario deux échecs puis une réussite puis un échec ne peut pas être testé. |
RG-04 ne présente pas de contradiction et lève même une ambiguïté utile, puisqu'une carte expirée ne doit pas incrémenter le compteur de RG-01. RG-02 relève d'un contrôle en base de données plutôt que d'un test fonctionnel. La façon de le vérifier reste à définir avec l'équipe.
Question à poser à l'analyse métier avant de figer les cas de test. Le blocage survient il au deuxième ou au troisième refus consécutif, et pour quelle durée ?
Le prompt système comporte le cadrage, rôle, format et données interdites. Le prompt utilisateur ne comporte que les données du jour. La séparation évite de répéter les mêmes contraintes à chaque demande et rend les résultats plus homogènes dans l'équipe.
Ce qui a changé dans le prompt
- TechniqueLe cadrage passe dans un prompt système séparé. Le rôle et les interdits sont posés une fois, indépendamment du cas traité.
- ContexteLes quatre règles sont désignées par leur identifiant.
- FormatLe tableau devient la seule forme de sortie acceptée, et la réponse doit se terminer par les questions à poser à l'analyse métier.
02 Conception de cas de test
One shot
Conception de cas de test
Créer votre compte
L'écran à vérifier est le formulaire d'inscription ci-contre, accompagné de ses règles de validation. Les dates de naissance des cas de test se lisent par rapport au 16 août 2026, retenu comme date du jour pour cet exemple.
- RG-01Le mot de passe doit avoir entre 8 et 20 caractères et contenir au moins un chiffre.
- RG-02L'adresse email doit respecter le format standard et ne pas être déjà utilisée par un autre compte.
- RG-03L'âge minimum est de 16 ans le jour de l'inscription.
- RG-04La case des conditions générales est obligatoire, le bouton reste inactif tant qu'elle n'est pas cochée.
- RG-05Le champ de confirmation doit être strictly identique au mot de passe saisi.
Prompt zero shot ▼
Voici quelques cas de test pour ce formulaire.
- Vérifier que l'inscription fonctionne avec des données valides
- Vérifier que les champs obligatoires sont bien requis
- Vérifier que le mot de passe respecte les règles de sécurité
- Vérifier que l'email de confirmation est bien envoyé
Ces quatre cas sont nominaux, non chiffrés et déjà évidents pour n'importe quelle personne testeuse. Aucune borne n'est couverte, alors que RG-01 et RG-03 en contiennent trois à elles deux, 8 caractères, 20 caractères et 16 ans. Le dernier cas invente même un email de confirmation dont aucune règle ne parle.
Prompt one shot ▼
Afficher la réponse obtenue
Voici les cas limites et cas d'erreur dérivés des cinq règles fournies.
| ID | Règle | Donnée saisie | Résultat attendu |
|---|---|---|---|
| CT-01 | RG-01 | Mot de passe de 7 caractères avec un chiffre | Refus, message sur la longueur minimale |
| CT-02 | RG-01 | Mot de passe de 8 caractères avec un chiffre | Accepté, borne basse valide |
| CT-03 | RG-01 | Mot de passe de 20 caractères avec un chiffre | Accepté, borne haute valide |
| CT-04 | RG-01 | Mot de passe de 21 caractères avec un chiffre | Refus, message sur la longueur maximale |
| CT-05 | RG-01 | Mot de passe de 12 caractères sans aucun chiffre | Refus, message sur le chiffre obligatoire |
| CT-06 | RG-02 | Adresse sans arobase, prenom.nom.exemple.fr | Refus, message sur le format attendu |
| CT-07 | RG-02 | Adresse déjà rattachée à un compte existant | Refus, message indiquant que le compte existe déjà |
| CT-08 | RG-03 | Date de naissance du 16 août 2010, soit 16 ans jour pour jour | Accepté, borne valide |
| CT-09 | RG-03 | Date de naissance du 17 août 2010, soit 15 ans et 364 jours | Refus, message sur l'âge minimum |
| CT-10 | RG-04 | Formulaire complet et valide, case des conditions non cochée | Bouton inactif, aucune création de compte |
| CT-11 | RG-05 | Mot de passe MotDePasse1 et confirmation MotDePasse2 | Refus, message sur la confirmation différente |
| CT-12 | RG-05 | Mot de passe valide et champ de confirmation laissé vide | Refus, message sur la confirmation obligatoire |
Deux points restent à confirmer avec l'équipe. Le message de CT-07 doit il révéler que l'adresse est déjà utilisée ? Cette information renseigne aussi une personne malveillante sur les comptes existants. De plus, le refus de CT-09 s'appuie t il sur la date du serveur ou sur celle du poste de la personne utilisatrice ?
Un exemple unique de cas de test suffit à transmettre le format attendu. C'est du one shot, pas du few shot, qui suppose plusieurs exemples.
Ce qui a changé dans le prompt
- TechniqueUn exemple de cas de test du projet est montré avant la demande. Un seul exemple, c'est du one shot. Il suffit ici parce que le format est simple et régulier.
- ContexteLes règles visées sont nommées, RG-01 à RG-05, et la date de référence est donnée pour que les calculs d'âge soient vérifiables.
- FormatLes quatre champs de l'exemple deviennent les quatre colonnes attendues, et les cas nominaux évidents sont explicitement exclus.
03 Génération de données de test
Les gabarits réutilisables
Génération de données de test
Nouvelle fiche client
Le jeu de données doit alimenter l'écran de création de fiche client de l'outil interne. L'équipe a défini le gabarit de prompt suivant : "Génère [nombre] profils clients pour le formulaire fourni, en respectant les règles [règles à couvrir] en couvrant les cas aux limites et en prenant le [date souhaitée] comme date du jour. Le reste en profils nominaux. Ajoute une colonne indiquant ce que chaque profil couvre comme règle."
- RG-01Le nom complet accepte de 2 à 60 caractères, accents, tirets et apostrophes compris.
- RG-02L'adresse de livraison est limitée à 80 caractères, le code postal français fait 5 chiffres.
- RG-03La fiche est refusée si la personne a moins de 18 ans le jour de la saisie.
Prompt sans gabarit ▼
Voici vingt profils clients.
| Nom | Âge | Ville |
|---|---|---|
| Jean Dupont | 35 | Paris |
| Marie Martin | 28 | Lyon |
| Pierre Bernard | 42 | Marseille |
| Sophie Petit | 31 | Toulouse |
| et ainsi de suite | 25 à 45 | grandes villes |
Les vingt profils partagent le même format de nom, la même tranche d'âge et des adresses réduites à un nom de ville. Aucune borne de RG-01 à RG-03 n'est couverte. Ces jeux de données ne révéleront ni troncature, ni refus de caractère spécial, ni refus d'âge.
Prompt avec gabarit ▼
Afficher la réponse obtenue
Voici un extrait représentatif des vingt profils, tous fictifs. Les âges sont calculés au 16 août 2026, la date du jour que vous avez indiquée.
| Nom complet | Adresse | Date de naissance | RG couverte |
|---|---|---|---|
| Élise de Vasconcelos | 4 impasse du Pré-Vert, 15100 Saint-Flour | 02/11/1990 | RG-01, accent dans le nom |
| François-Xavier N'Diaye | 7 bis avenue Foch, 33000 Bordeaux | 18/05/1984 | RG-01, tiret et apostrophe |
| Li | 3 rue Neuve, 59000 Lille | 30/01/1979 | RG-01, borne basse à 2 caractères, fiche acceptée |
| Marie-Charlotte Grandveaubourg-Delaunay-Ferrat de Kervasdoué | Au lieu-dit Les Quatre Chemins, route de la Chapelle-aux-Bois, 88240 Les Voivres | 12/09/1972 | RG-01 et RG-02, bornes hautes à 60 et 80 caractères, fiche acceptée |
| Marie-Charlotte Grandveaubourg-Delaunay-Ferratt de Kervasdoué | 3 rue Neuve, 59000 Lille | 12/09/1972 | RG-01, 61 caractères, un de trop, refus attendu |
| Paul Nerrand | Au lieu-dit Les Quatre Chemins, route de la Chapelle-aux-Bois, 88240 Xertigny-Bas | 03/04/1988 | RG-02, 81 caractères, un de trop, refus attendu |
| Sarah Oueslati | 8 rue des Écoles, 7500 Paris | 22/07/1991 | RG-02, code postal à 4 chiffres, refus attendu |
| Théo Rambert | 9 rue du Port, 44000 Nantes | 17/08/2008 | RG-03, 17 ans et 364 jours, refus attendu |
| Inès Fauvel | 21 rue Basse, 51100 Reims | 16/08/2008 | RG-03, 18 ans jour pour jour, fiche acceptée |
| Nadia Belkacem | 5 allée des Tilleuls, 67000 Strasbourg | 15/08/2008 | RG-03, 18 ans et un jour, fiche acceptée |
| Hugo Vasseur | 2 place du Marché, 21000 Dijon | 20/06/1994 | RG-03, personne largement majeure, cas de contrôle |
Les neuf profils restants sont nominaux, avec des villes variées.
Point à vérifier de votre côté. Les longueurs annoncées à 60, 61, 80 et 81 caractères sont à recompter avant usage car un caractère spécial peut être compté différemment selon la base de données.
Le gabarit fourni dans le matériel est ici instancié avec les valeurs du projet. L'équipe stabilise ainsi la structure de ses demandes de jeux de données. Le fait de couvrir les bornes des deux côtés, acceptée et refusée, est porté par le gabarit lui même, qui contient déjà la consigne sur les cas aux limites. Chaque conversation en hérite sans que personne ait à y repenser.
Ce qui a changé dans le prompt
- TechniqueLe gabarit de l'équipe est hérité tel quel. Seuls les blancs changent, le nombre, les règles visées et la date du jour. La structure de la demande reste identique d'une fois sur l'autre.
- ContexteLes règles à couvrir sont désignées et la date du jour est fixée permettant de rendre chaque calcul d'âge vérifiable. Dans cet exemple, l'IA a accès aux régles de gestion et n'a pas besoin qu'on lui fournisse dans la conversation.
- FormatLe gabarit impose lui même la colonne indiquant la règle couverte par chaque profil.
04 Priorisation d'une campagne de test
Le raisonnement guidé
Priorisation d'une campagne de test
La campagne lancée au cours de la nuit a produit quatorze échecs. Le•la testeur•se dispose du récapitulatif d'exécution et du journal des incidents ouverts sur l'environnement de recette.
Extrait du récapitulatif d'exécution du 16 août 2026
| Suite | Échecs | Message dominant |
|---|---|---|
| Paiement | 3 | Le bouton Payer reste inactif après saisie de la carte |
| Connexion | 2 | Délai dépassé sur l'appel d'authentification |
| Notifications | 5 | Timeout après 30 secondes sur le service de notification |
| Recherche produit | 3 | Ordre des résultats différent de l'attendu |
| Fiche produit | 1 | Écart de rendu sur la vignette en 320 px de large |
Journal des incidents en cours sur la recette
- INC-482, ouvert le 15 août à 6 h 10, service de notification indisponible par intermittence, correctif en cours.
- INC-479, ouvert le 14 août, lenteurs générales de la base de recette en heures de nuit.
Prompt sans raisonnement guidé ▼
Voici un classement possible par criticité fonctionnelle.
- Les échecs de paiement en premier, car ils touchent au revenu
- Les échecs de connexion ensuite, car ils bloquent l'accès
- Les échecs de notification en troisième position
- Les échecs d'affichage en dernier, moins critiques
Le classement reprend une hiérarchie générique, la même quelle que soit la campagne. Les cinq échecs de notification sont traités comme de vrais défauts alors que l'incident INC-482 les explique très probablement, ce qui enverrait l'équipe de développement chercher un défaut inexistant.
Prompt avec raisonnement guidé ▼
Afficher la réponse obtenue
Étape 1. Je confronte chaque suite en échec au journal des incidents. Les notifications échouent toutes sur un timeout du service de notification, exactement le symptôme d'INC-482. Les échecs de connexion sont des délais dépassés survenus de nuit, ce que décrit INC-479. Sept des quatorze échecs se rattachent donc à un incident connu et ne sont pas des défauts à déclarer en l'état.
| Suite | Échecs | Rattachement | Action |
|---|---|---|---|
| Notifications | 5 | INC-482, timeout sur le service concerné | Rejouer la suite une fois le correctif déployé, sans ouvrir d'anomalie pour l'instant |
| Connexion | 2 | INC-479, délai dépassé cohérent avec les lenteurs de la base | Rejouer en heures pleines avant toute déclaration de nouvelle anomalie |
Étape 2. Je retire ces sept échecs. Il reste le paiement avec trois échecs, la recherche produit avec trois échecs et la fiche produit avec un échec. Aucun incident ouvert ne décrit ces symptômes, ce sont donc de vrais candidats au statut de défaut.
Étape 3. Je les classe par impact sur le parcours d'achat. Le paiement interrompt la vente, la recherche la dégrade, l'écart de vignette reste cosmétique.
| Priorité | Suite | Constat | Action attendue |
|---|---|---|---|
| 1 | Paiement | Le bouton Payer reste inactif après une saisie valide, le parcours d'achat est interrompu | Reproduire manuellement puis ouvrir une anomalie bloquante |
| 2 | Recherche produit | L'ordre des résultats ne correspond plus à l'attendu sur trois requêtes | Vérifier si une règle de tri a changé récemment avant de déclarer une anomalie |
| 3 | Fiche produit | Écart de rendu de la vignette en 320 px | Comparer avant et après, gravité mineure |
Réserve à garder en tête : le rattachement des deux échecs de connexion à INC-479 reste une hypothèse, un vrai défaut d'authentification pourrait produire le même message. La réexécution en heures pleines tranchera.
Les trois étapes affichées sont le cœur de la technique. Elles rendent le raisonnement relisible, donc contestable. Une personne testeuse peut refuser l'étape 1 sans jeter le reste. Le raisonnement guidé aide sur ce type de tâche à plusieurs déductions, mais il ne garantit pas la justesse, comme le montre la réserve finale.
Ce qui a changé dans le prompt
- TechniqueLe prompt impose trois étapes de raisonnement avant la conclusion, et demande que ces étapes soient visibles dans la réponse.
- ContexteLe journal des incidents ouverts sur la recette est fourni en plus du récapitulatif d'exécution.
- FormatDeux tableaux distincts sont demandés, un pour les échecs rattachés à un incident, un pour les défauts à traiter.
05 Rédaction d'un rapport d'anomalie
Le prompting par rôle
Rédaction d'un rapport d'anomalie
Connexion à votre espace
Le défaut a été trouvé en session exploratoire sur l'écran de connexion. Les notes prises pendant la session sont fournies telles quelles.
- RG-01Au troisième mot de passe erroné consécutif, le compte est bloqué pendant 15 minutes.
- RG-02Pendant le blocage, le message doit indiquer que le compte est temporairement bloqué et rappeler le délai restant.
Notes de session, non retravaillées.
- 16 août, recette, Chrome 138, poste Windows
- compte client.test, mot de passe volontairement faux trois fois de suite
- 3e essai, message identique au 1er, "Identifiant ou mot de passe incorrect."
- la 4e tentative avec le bon mot de passe est bien refusée, donc le blocage existe côté serveur
- reproduit deux fois, aussi sur Firefox
Prompt sans rôle ▼
Titre : Blocage de compte lors de la connexion.
Description : Sur l'environnement de recette, le compte client.test se retrouve bloqué lors de la connexion après avoir saisi trois fois de suite un mauvais mot de passe.
Étapes de reproduction : Saisir l'identifiant client.test, taper trois fois de suite un mauvais mot de passe.
Gravité : Moyenne.
Le rapport comble les blancs avec des formulations vagues au lieu de signaler ce qui manque. Personne ne pourra reproduire le défaut à partir de ces étapes, et rien n'indique que le blocage fonctionne bien côté serveur, ce qui est pourtant l'information qui oriente la correction.
Prompt avec rôle et structure imposée ▼
Afficher la réponse obtenue
| Rubrique | Contenu |
|---|---|
| Titre | Le message de blocage temporaire ne s'affiche pas après trois mots de passe erronés, seul le message d'identifiants incorrects apparaît. |
| Environnement | Recette, Chrome 138 sous Windows, reproduit deux fois, également reproduit sous Firefox dont la version n'est pas notée |
| Préconditions | Compte client.test@exemple.fr actif et non bloqué au début du scénario |
| Étapes de reproduction | 1. Ouvrir la page de connexion de la recette 2. Saisir l'identifiant client.test@exemple.fr et un mot de passe volontairement erroné 3. Valider trois fois de suite avec le même mot de passe erroné 4. Observer le message affiché au troisième échec 5. Saisir le mot de passe correct et valider |
| Résultat observé | Au troisième échec, le message reste "Identifiant ou mot de passe incorrect.". La quatrième tentative avec le bon mot de passe est refusée, le blocage est donc bien appliqué côté serveur mais n'est pas restitué à l'écran |
| Résultat attendu | Conformément à RG-02, le message doit indiquer que le compte est temporairement bloqué et rappeler le délai restant de 15 minutes prévu par RG-01 |
| Gravité proposée | Majeure sur l'aspect fonctionnel du message, le blocage lui même fonctionne |
| Priorité proposée | Haute, la personne utilisatrice croit s'être trompée de mot de passe et enchaîne des tentatives inutiles pendant 15 minutes |
Informations absentes de vos notes, à compléter avant transmission.
- L'heure exacte de la reproduction, utile pour retrouver les traces serveur
- Le comportement observé après les 15 minutes de blocage, non testé pendant la session
- La version de Firefox utilisée lors de la seconde reproduction
- La présence ou non d'un message équivalent sur l'application mobile
Le rôle de testeur senior explique le ton et la prudence de la réponse, notamment le refus de combler les blancs. La structure du rapport, elle, vient de la liste de rubriques imposée dans le prompt. Un rôle seul ne l'aurait pas produite.
Ce qui a changé dans le prompt
- TechniqueUn rôle est assigné au modèle, testeur Web senior et rigoureux. Il oriente le vocabulaire et le niveau d'exigence, pas la structure du rapport.
- ContexteLes notes brutes de session et les deux règles de l'écran sont fournies, avec l'interdiction de s'appuyer sur autre chose.
- FormatLes rubriques attendues sont énumérées dans l'ordre, et la liste des informations manquantes est demandée à part.
06 Analyse progressive d'une user story
Enchaînement de prompts
Analyse progressive d'une user story
La user story arrive en affinage. Elle est courte, et c'est justement le problème.
User story fournie telle quelle.
- US-214. En tant que client•e fidèle, je veux utiliser mes points de fidélité lors du paiement afin de réduire le montant à payer.
- Critère d'acceptation unique noté par l'équipe. Les points sont déduits du total.
Prompt sans enchaînement ▼
Voici une analyse complète de la user story US-214.
Critères d'acceptation proposés.
- Le client peut utiliser ses points de fidélité
- Le montant est correctement réduit
- Le solde de points est mis à jour
Cas de test proposés.
- Vérifier l'utilisation des points de fidélité
- Vérifier le calcul du montant réduit
- Vérifier la mise à jour du solde
Risques identifiés. Erreur de calcul, problème de performance, mauvaise expérience utilisateur.
Trois tâches demandées en une seule fois donnent un survol de chacune. Les critères reformulent la user story sans rien ajouter. Les cas de test paraphrasent les critères. Aucune des vraies questions n'est posée. Que se passe-t-il si les points ne couvrent qu'une partie du montant, ou si le paiement échoue après déduction ?
Prompt avec enchaînement ▼
Afficher la réponse de l'échange 1
Sept questions bloquantes, classées par ce qu'elles empêchent d'écrire.
| Question au métier | Ce que la réponse débloque |
|---|---|
| Quelle est la règle de conversion entre points et euros, et est-elle arrondie ? | Tout cas de test portant sur un montant, donc la majorité de la story |
| Un paiement peut-il être réglé intégralement en points, ou un reste à payer minimum est-il imposé ? | Le scénario limite le plus probable, et le comportement du moyen de paiement associé |
| Que deviennent les points si le paiement échoue après leur déduction ? | Le cas d'erreur le plus coûteux, et la question de la réversibilité |
| Les points utilisés sont-ils remboursés en cas de retour produit ? | Le périmètre réel de la story, qui déborde peut-être sur le parcours de retour |
| Existe-t-il un plafond de points utilisables par commande ? | Les valeurs limites à tester sur le champ de saisie |
| Le solde affiché est-il celui avant ou après commandes en cours ? | La cohérence entre l'écran de paiement et l'espace fidélité |
| Que voit un client dont le solde est de zéro point ? | Le cas nominal négatif, souvent oublié en affinage |
Ces réponses sont nécessaires avant de rédiger le moindre critère d'acceptation.
Afficher la réponse de l'échange 2
Six critères d'acceptation, chacun rattaché à la question qui l'a débloqué.
| ID | Critère d'acceptation | Question source |
|---|---|---|
| CA-01 | 100 points utilisés réduisent le montant de 1 euro, la remise étant arrondie à l'euro inférieur. | Règle de conversion |
| CA-02 | Au-delà de 5000 points saisis sur une commande, la saisie est refusée avec un message sur le plafond. | Plafond par commande |
| CA-03 | Lorsque les points couvrent la totalité du montant, le reste à payer affiché est de 0 euro et la commande se valide sans moyen de paiement complémentaire. | Paiement intégral en points |
| CA-04 | En cas d'échec du paiement après déduction, le solde de points est restitué dans les 24 heures. | Réversibilité |
| CA-05 | Le solde affiché sur l'écran de paiement est celui restant après déduction des commandes en cours. | Solde affiché |
| CA-06 | Avec un solde de zéro point, le bloc fidélité reste visible mais grisé et aucune saisie n'est possible. | Solde nul |
Le remboursement des points après un retour produit a été écarté du périmètre. Il mérite une story distincte, sans quoi le sujet disparaîtra.
Afficher la réponse de l'échange 3
| ID | Critère | Donnée saisie | Résultat attendu |
|---|---|---|---|
| CT-01 | CA-01 | 1250 points sur une commande de 89,90 euros | Remise de 12 euros, reste à payer 77,90 euros |
| CT-02 | CA-01 | 99 points | Remise de 0 euro, montant inchangé, les points ne sont pas débités |
| CT-03 | CA-02 | 5000 points, borne haute du plafond | Saisie acceptée, remise de 50 euros |
| CT-04 | CA-02 | 5001 points | Saisie refusée, message sur le plafond par commande |
| CT-05 | CA-03 | 8990 points sur une commande de 89,90 euros | Remise de 89 euros, reste à payer 0,90 euro |
| CT-06 | CA-04 | Refus bancaire après déduction de 1250 points | Solde restauré sous 24 heures, commande non enregistrée |
| CT-07 | CA-06 | Compte avec un solde de zéro point | Bloc fidélité visible et grisé, champ de saisie inactif |
CT-05 fait apparaître une contradiction entre CA-01 et CA-03. L'arrondi à l'euro inférieur laisse toujours un reste de quelques centimes sur un montant qui n'est pas rond. Un paiement intégralement réglé en points devient donc impossible dès qu'il y a des centimes. La question doit repartir au métier avant d'écrire ce cas.
CA-05 n'apparaît pas ici. Il demande un jeu de données avec une commande en cours non livrée, à préparer avant de pouvoir être testé.
Chaque étape interdit de produire ce que la suivante traitera. Le modèle fait donc l'analyse au lieu de la sauter. L'étape 2 ne part pas d'une supposition mais des réponses réelles du métier, obtenues grâce à l'étape 1. Et l'erreur reste rattrapable à chaque palier, au lieu d'être découverte à la toute fin.
Ce qui a changé dans le prompt
- TechniqueLa demande est découpée en trois échanges successifs. Chaque étape interdit explicitement de produire ce que l'étape suivante traitera.
- ContexteL'étape 2 est nourrie des réponses réelles du métier, obtenues entre les deux échanges.
- FormatL'étape 1 impose un classement des questions par ce qu'elles bloquent. L'étape 3 impose ses trois colonnes, le critère couvert, la donnée d'entrée et le résultat attendu.
07 Script de régression dirigé par les mots-clés
Few shot
Script de régression dirigé par les mots-clés
L'équipe maintient sa suite de régression en test dirigé par les mots-clés. Le vocabulaire d'actions a été défini une fois pour toutes. Aucune documentation ne le décrit. Il vit uniquement dans les scripts existants.
Premier script existant fourni comme exemple.
# TC_CONNEXION_001 | Connexion nominale OuvrirPage | /connexion SaisirChamp | identifiant | client.test@exemple.fr SaisirChamp | motDePasse | MotDePasse1 CliquerBouton | seConnecter VerifierTexte | Bonjour client.test VerifierUrl | /mon-compte
Second script existant fourni comme exemple.
# TC_RECHERCHE_002 | Recherche sans aucun résultat OuvrirPage | /recherche SaisirChamp | motCle | zzzzzz CliquerBouton | lancerRecherche VerifierTexte | Aucun résultat pour votre recherche VerifierUrl | /recherche
Cas de test à automatiser, rédigé en langage naturel.
- TC_PANIER_004. Depuis la fiche du produit "Casque audio sans fil", accessible à l'adresse /produit/casque-audio-sans-fil, ajouter l'article au panier. Vérifier ensuite que le compteur du panier passe à 1, puis que le nom de l'article apparaît dans le récapitulatif du panier, à l'adresse /panier.
Prompt zero shot ▼
from selenium import webdriver
driver = webdriver.Chrome()
driver.get("https://boutique.exemple.fr/produit/123")
driver.find_element(By.ID, "add-to-cart").click()
assert driver.find_element(By.CLASS_NAME, "cart-count").text == "1"Ce script utilise Selenium avec Python. Pensez à adapter les sélecteurs à votre application.
Le modèle a choisi seul une technologie, une syntaxe et des sélecteurs inventés. Cette équipe n'écrit pas ses tests ainsi, le résultat est donc inutilisable. Et la phrase finale renvoie tout le travail réel à la personne qui a posé la question.
Prompt few shot ▼
Afficher la réponse obtenue
# TC_PANIER_004 | Ajout d'un article au panier depuis la fiche produit OuvrirPage | /produit/casque-audio-sans-fil CliquerBouton | ajouterAuPanier VerifierTexte | 1 OuvrirPage | /panier VerifierUrl | /panier VerifierTexte | Casque audio sans fil
Action manquante dans le vocabulaire des exemples.
- Aucune action ne vérifie la valeur d'un compteur précis. VerifierTexte cherche un texte présent n'importe où sur la page. Avec la valeur 1, c'est ambigu, le chiffre 1 pouvant apparaître ailleurs. Une action du type VerifierCompteur serait à ajouter au vocabulaire.
Le libellé du bouton d'ajout au panier, ajouterAuPanier, suit la convention des deux exemples mais reste une supposition. Il est à confirmer avec l'équipe avant la première exécution.
Deux exemples suffisent à transmettre quatre conventions que personne n'a écrites. La syntaxe en colonnes séparées par des barres verticales, leur alignement, la façon de nommer les identifiants en TC_DOMAINE_NNN et la ligne de commentaire qui reprend l'identifiant puis le libellé. C'est ce que le few shot permet. La contrainte de ne rien inventer transforme en plus une limite du vocabulaire en information utile pour l'équipe.
Ce qui a changé dans le prompt
- TechniqueDeux scripts existants sont fournis avant la demande. Deux exemples, c'est du few shot. Le modèle peut en déduire ce qui est constant d'un script à l'autre, et non plus seulement recopier une forme.
- ContexteLe cas de test à automatiser porte l'adresse de la page et le nom exact de l'article, pour que rien ne reste à deviner.
- FormatLe prompt exige le même vocabulaire, la même mise en forme et la même façon de nommer, et interdit d'inventer une action absente.
03 — Ce qui se répète
Ce qui distingue une bonne réponse
Les sept cas ci-dessus partagent les mêmes constats, quelle que soit l'activité de test concernée.
Le contexte fourni change tout
Les réponses s'appuient sur des suppositions génériques, faute de contexte dans le prompt. Dès que les règles de gestion, les scripts existants ou le journal des incidents sont donnés, la réponse devient exploitable.
La technique seule n'explique pas le gain
Dans chaque cas, le prompt affiné change trois choses en même temps, la technique, le contexte et le format attendu. Le bloc "ce qui a changé" les sépare pour éviter de créditer la technique du travail fait par les deux autres.
Une règle numérotée rend la réponse traçable
Quand les règles portent un identifiant, chaque cas de test, chaque profil et chaque écart peut être rattaché à la règle qu'il couvre. La revue de la réponse en devient beaucoup plus rapide.
Les cas limites ne viennent jamais par défaut
Sans consigne explicite, un modèle propose en priorité les cas nominaux les plus évidents. Les bornes, les cas d'erreur et les scénarios de refus doivent être demandés.
Demander le format de sortie fait gagner du temps
Un tableau avec identifiant, règle couverte, donnée et résultat attendu s'importe dans un outil de gestion. Un paragraphe libre demande une réécriture complète avant d'être utilisable.
Une bonne réponse signale ce qui lui manque
Les réponses affinées se terminent par une question ou une réserve plutôt que par une invention. C'est le signe que le prompt a laissé au modèle la possibilité de dire qu'il ne sait pas.
Une demande large donne un survol
Trois tâches posées en une fois produisent une réponse superficielle sur chacune. Découpées en échanges successifs, elles laissent le temps de corriger le tir dès la première étape, avant que l'erreur ne se propage aux suivantes.
Une bonne réponse reste vérifiable
Même une réponse bien formulée mérite d'être challengée avec la documentation ou le comportement réel du système avant d'être considérée comme fiable, un réflexe déjà vu dans la page Ingénierie du prompting.
A retenir
Ce qu'il faut retenir
Un prompt imprécis produit une réponse générique
Sans règles de gestion ni angle précis, l'IA comble les blancs avec des suppositions qui semblent plausibles mais restent peu exploitables pour une campagne de test réelle.
Le contexte du projet ne se devine jamais
Règles de validation, convention de nommage, pile technique ou incidents en cours doivent être donnés explicitement, sans quoi le modèle s'appuie sur des habitudes génériques.
Les cas limites se demandent explicitement
Livrée à elle même, une IA générative propose d'abord les cas nominaux les plus évidents.
Le format de sortie fait partie du prompt
Demander un tableau avec identifiant, règle couverte, donnée et résultat attendu évite une réécriture complète avant de pouvoir utiliser la réponse.
Chaque réponse reste à vérifier avant usage
Une réponse bien formulée peut malgré tout contenir une erreur ou une donnée inventée. La recouper avec la documentation ou le comportement réel du système reste le dernier filet de sécurité.
À savoir
La Minute QA est une aide à la compréhension, pas une formation professionnelle : certains points ne peuvent pas être couverts ici. Pensez à suivre une formation certifiante et à consulter le syllabus officiel ISTQB pour une préparation complète.
Pour aller plus loin