Des prompts testés pour la QA : cas de test, données, bug reports, analyse d'échecs, tests Playwright. Copiez, remplacez la partie entre crochets, collez dans votre assistant IA.
Conception des tests
Cas de test depuis une user story
Transformer une user story en cas de test complets, cas limites compris.
Tu es un ingénieur QA senior. À partir de la user story ci-dessous, écris les cas de test.
Pour chaque cas : un identifiant, un titre, les préconditions, les étapes numérotées, le résultat attendu et une priorité (haute, moyenne, basse).
Couvre le parcours nominal, les cas alternatifs, les cas d'erreur et les cas limites (valeurs vides, maximales, caractères spéciaux, droits insuffisants).
Termine par la liste des questions à poser au product owner sur les points ambigus.
User story :
[colle ta user story et ses critères d'acceptation]
Relisez toujours la liste des questions : c’est souvent là que se cachent les vrais trous de la spécification.
Conception des tests
Critères d'acceptation en Gherkin
Rédiger des scénarios Given / When / Then prêts pour Cucumber ou Playwright-BDD.
Écris les critères d'acceptation de la fonctionnalité ci-dessous en Gherkin, en français (Soit / Quand / Alors).
Règles :
- un scénario par règle métier, avec un titre explicite ;
- utilise un Plan du scénario avec des Exemples quand seules les données changent ;
- pas de détail d'interface (pas de « clique sur le bouton bleu ») : décris le comportement.
Fonctionnalité :
[décris la fonctionnalité]
Données de test
Jeu de données de test
Générer des données réalistes et piégeuses pour un formulaire ou une API.
Génère un jeu de données de test au format JSON pour le schéma ci-dessous.
Inclus :
- 5 enregistrements valides et réalistes (noms, adresses et téléphones français) ;
- 10 enregistrements invalides, chacun avec un champ "raison" qui explique ce qui est faux ;
- des cas limites : longueur maximale, accents, emojis, espaces en début et fin, injection HTML et SQL.
N'utilise aucune donnée personnelle réelle.
Schéma :
[colle le schéma ou la liste des champs]
Les données invalides servent autant que les valides : ce sont elles qui trouvent les bugs de validation.
Bugs et échecs
Bug report structuré
Transformer une description en vrac en ticket de bug clair et reproductible.
Transforme la description ci-dessous en bug report structuré :
- Titre (moins de 80 caractères, qui décrit le symptôme)
- Environnement (navigateur, appareil, version, compte de test)
- Étapes pour reproduire, numérotées
- Résultat obtenu
- Résultat attendu
- Gravité proposée (bloquante, majeure, mineure) avec une justification d'une ligne
- Informations manquantes à demander au rapporteur
Description :
[colle la description, le message ou la capture]
Bugs et échecs
Analyser un échec de CI
Trouver la cause probable d'un test rouge à partir du log.
Voici le log d'un test qui échoue dans la CI. Analyse-le et réponds :
1. La cause la plus probable, en une phrase.
2. S'agit-il d'un vrai bug, d'un test instable ou d'un problème d'environnement ? Explique les indices qui te le font penser.
3. Les 3 vérifications à faire pour confirmer.
4. Une proposition de correction, du test ou du code.
Log :
[colle le log, la stack trace et le nom du test]
Donnez aussi le diff de la merge request si possible : la cause est souvent dans les lignes qui viennent de changer.
Automatisation
Écrire un test Playwright
Passer d'un scénario à un test Playwright lisible et robuste.
Écris un test Playwright en TypeScript pour le scénario ci-dessous.
Contraintes :
- sélecteurs accessibles (getByRole, getByLabel, getByText), jamais de XPath ni de classes CSS ;
- aucune attente fixe (pas de waitForTimeout) : utilise les assertions web-first (expect(...).toBeVisible()) ;
- un test indépendant qui prépare ses propres données ;
- des noms d'étapes clairs avec test.step.
Scénario :
[décris le scénario, l'URL et les données]
Faites lancer le test avant de le relire : un test généré qui n’a jamais tourné n’est qu’un brouillon.
Revue et exploration
Revue d'une suite de tests
Repérer les tests inutiles, fragiles ou qui n'affirment rien.
Tu fais la revue du code de test ci-dessous. Pour chaque test, signale :
- les assertions absentes ou trop faibles (le test passerait même si la fonctionnalité était cassée) ;
- les sources d'instabilité (attentes fixes, ordre d'exécution, données partagées, dépendance au réseau) ;
- les doublons ;
- les cas importants qui ne sont pas couverts.
Classe tes remarques par gravité et propose le code corrigé pour les plus graves.
Code :
[colle les tests]
Revue et exploration
Charte de test exploratoire
Préparer une session exploratoire de 60 minutes ciblée sur les risques.
Prépare une charte de test exploratoire de 60 minutes pour la fonctionnalité ci-dessous.
Donne :
- la mission, en une phrase ;
- les 5 risques principaux à explorer, du plus grave au moins grave ;
- pour chaque risque, 3 idées de tests concrètes (données, gestes, conditions) ;
- les heuristiques utiles (par exemple : interrompre, répéter, aller trop vite, changer de langue) ;
- un modèle de notes de session.
Fonctionnalité :
[décris la fonctionnalité et son contexte]
Le meilleur prompt reste un bon testeur
L'IA va vite, mais elle se trompe avec aplomb. Relisez chaque cas, chaque donnée et chaque test généré avant de vous y fier.