Un prompt pour cas de test s'attaque à l'étape la plus lente après la revue des besoins : tout le monde comprend la fonctionnalité, mais dès qu'il faut écrire les cas, le parcours normal coule tout seul tandis que les valeurs limites et les situations d'erreur passent discrètement à la trappe, pour réapparaître en fiches d'anomalie après la livraison. Le prompt ci-dessous fixe les familles de cas, les colonnes du tableau et la façon d'écrire les résultats attendus avant même de coller quoi que ce soit, de sorte que la réponse est un tableau exécutable tel quel ou importable dans un outil de gestion des tests.
Quand utiliser ce prompt
Il sert à préparer les cas avant la recette d'une nouvelle fonctionnalité, à reconstruire une liste de régression après une refonte, ou à vérifier soi-même les critères d'acceptation côté produit. Il lui faut un passage de besoin écrit clairement : une note de prototype, un extrait de spécification ou une histoire utilisateur conviennent. Si vous ne disposez que d'une demande orale d'une phrase, transformez-la d'abord en un court paragraphe couvrant le contexte, le point d'entrée, les règles et les limites ; la qualité de la sortie en dépend largement.
Le prompt, prêt à copier
Tu es un ingénieur de test logiciel avec 8 ans d'expérience. À partir du besoin ci-dessous, conçois un ensemble de cas de test exécutables tels quels.
Besoin : {{besoin}}
Contexte complémentaire : {{contexte complémentaire, par exemple les écrans ou les API concernés, les rôles de compte, les limites de données ; écrire « aucun » s'il n'y en a pas}}
Règles de sortie :
1. Produis un tableau avec ces colonnes dans cet ordre : numéro du cas, titre du cas, préconditions, étapes, données de test, résultat attendu, priorité, type de cas.
2. Les types de cas doivent couvrir quatre familles : parcours normal, valeurs limites, erreurs et saisies invalides, droits et rôles, avec au moins 3 cas par famille.
3. Les cas limites doivent indiquer des nombres concrets, par exemple une longueur maximale, un montant maximal ou un nombre maximal d'envois ; n'écris pas simplement « saisir la valeur maximale ».
4. Les résultats attendus doivent être vérifiables : précise le message affiché, la modification de données ou le changement d'état ; évite les formules vides comme « fonctionne normalement ».
5. Après le tableau, ajoute une section distincte intitulée « Points que le besoin laisse ouverts » et liste chaque ambiguïté une par une ; n'invente pas de règles pour combler les vides.
Affiche d'abord le tableau, puis les points ouverts, sans longue introduction avant le tableau.Comment remplir les deux variables
- {{besoin}} : collez le texte du besoin en entier, règles métier, limites des champs et transitions d'état comprises. Plus c'est précis, mieux c'est. Si vous écrivez seulement « créer une fonction de coupons », le modèle ne peut que deviner à partir de règles génériques d'e-commerce, et les cas devinés ne correspondront pas à vos règles réelles.
- {{contexte complémentaire}} : indiquez ce dont le test dispose réellement, par exemple les rôles de compte existants, la présence de données de test toutes prêtes, et si la fonctionnalité tourne dans une application ou un navigateur. L'information sur les rôles est la plus importante, car tous les cas de droits en découlent.
À quoi ressemble un passage rempli
Remplacez le besoin par un court passage, « l'utilisateur peut modifier son adresse de livraison ; le texte de l'adresse est limité à 100 caractères ; la région, la ville et le quartier sont obligatoires ; la nouvelle adresse prend effet dès l'enregistrement », et le tableau renvoyé contient des lignes comme celles-ci :
| N° | Titre | Données de test | Résultat attendu | Type |
|---|---|---|---|---|
| TC-04 | Enregistrer une adresse de exactement 100 caractères | Une adresse de 100 caractères exactement | L'enregistrement réussit et la liste affiche l'adresse complète | Limite |
| TC-05 | Enregistrer une adresse de 101 caractères | Une adresse de 101 caractères | L'enregistrement est bloqué avec un message de limite de longueur | Limite |
| TC-09 | Enregistrer sans choisir le quartier | Région et ville choisies, quartier vide | Le focus va au champ quartier avec un message de champ obligatoire | Erreur |
Des lignes portant des nombres concrets comme celles-ci montrent que le prompt fonctionne. Si tous les titres ressemblent à « vérifier l'enregistrement », répétez les règles 3 et 4 avec insistance et relancez.
Relances quand le résultat déçoit
- Cas trop superficiels : demandez « ne garde que les cas de priorité haute et ajoute à chacun une vérification inverse : comment le système doit bloquer une saisie volontairement fausse ».
- Envois répétés absents : ajoutez au contexte « le même utilisateur peut cliquer plusieurs fois de suite sur enregistrer », puis demandez une famille « actions répétées ».
- Vous voulez automatiser : demandez « réécris les cas de priorité haute en étapes de test Playwright, avec les localisateurs et les assertions pour chacun ».
Un dernier point : les cas générés par une IA conviennent bien comme premier jet et comme liste de manques. Les cas touchant aux paiements, aux droits ou à la suppression de données doivent quand même être exécutés un par un par un testeur humain dans l'environnement réel avant la mise en production, et les ambiguïtés listées dans les points ouverts sont souvent exactement celles que personne n'avait tranchées pendant la revue.
