Prompt Engineering pour les Ingénieurs QA: Obtenez de Meilleurs Résultats des Outils IA

La qualité des prompts détermine si les outils IA comme Claude et Copilot produisent du code de test utile ou du boilerplate générique.

Pourquoi la qualité des résultats IA dépend surtout de vous

Claude, ChatGPT et GitHub Copilot ne sont pas des moteurs de recherche. Ils génèrent la continuation la plus probable de votre entrée. Si votre entrée est vague, la continuation est générique. Si elle est précise et bien structurée, le résultat est utile.

Le modèle ne sait pas :

Quel framework vous utilisez
À quoi ressemble votre base de code
Le niveau de détail que vous voulez
Ce que vous avez déjà essayé
Sous quelles contraintes vous travaillez

Quand vous obtenez un mauvais résultat, la première question n'est pas "ce modèle est-il mauvais ?" C'est "mon prompt a-t-il donné au modèle ce dont il avait besoin pour bien faire ça ?"

La structure de prompt en quatre parties

Un prompt qui fonctionne pour les tâches QA comporte généralement quatre composantes. Vous n'en avez pas toujours besoin des quatre, mais quand le résultat est mauvais, l'une d'elles manque généralement.

Rôle : dites au modèle quel expert il doit incarner. "Tu es un ingénieur QA automation senior" ou "Tu es un expert TypeScript spécialisé en architecture de tests Playwright" change le registre et la profondeur du résultat. Contexte : décrivez la situation. Quel framework, quel langage, quel type d'application, sous quelle contrainte vous travaillez. Plus c'est précis, mieux c'est. Tâche : la demande réelle, formulée précisément. Pas "écris un test" mais "écris un test Playwright en TypeScript qui se connecte via storageState et vérifie que l'en-tête du tableau de bord affiche le nom d'utilisateur". Format : comment vous voulez le résultat. Juste le code ? Le code avec des commentaires ? Avec une brève explication d'abord ? Un tableau ? Précisez-le ou vous obtiendrez ce que le modèle produit par défaut.

Exemple de mauvais prompt :

"Écris un test Playwright pour la connexion"

Le même prompt avec les quatre composantes :

"Tu es un ingénieur QA automation senior. Je travaille sur un projet Playwright TypeScript utilisant le pattern Page Object Model. La page de connexion est à https://lab.becomeqa.com, utilise un formulaire e-mail/mot de passe, et redirige vers /dashboard en cas de succès. Écris un test qui : se connecte avec des identifiants de test depuis des variables d'environnement, vérifie que l'URL change vers /dashboard, et vérifie qu'un titre avec le texte 'My Travel Items' est visible. N'utilise que les locators getByRole et getByLabel. Pas de commentaires dans le code."

Le deuxième prompt donne du code qu'on peut coller directement. Le premier donne un squelette avec des placeholders.

Prompts pour la génération de tests

Pour générer des tests Playwright, les problèmes les plus courants sont les suivants.

Locators génériques. L'IA utilise par défaut ce qu'elle a le plus vu à l'entraînement, c'est-à-dire beaucoup de sélecteurs CSS. Écartez-les explicitement.

"N'utilise que des locators getByRole, getByLabel, getByPlaceholder ou getByTestId. Pas de sélecteurs CSS ni XPath."

Assertions manquantes. Les tests générés n'ont souvent qu'une assertion à la fin. Les vrais tests en ont besoin de plus.

"Inclus des assertions à chaque étape significative, pas seulement sur l'état final. Vérifie les états intermédiaires quand ils comptent."

Absence de contexte sur les cas d'erreur. Si vous testez un scénario d'erreur, dites-le explicitement.

"Écris un test pour le cas où l'utilisateur soumet le formulaire avec un e-mail vide. Vérifie que le message d'erreur 'L'e-mail est requis' apparaît sous le champ e-mail."

Données de test codées en dur. Prévenez ça dès le départ.

"Utilise process.env pour les identifiants. Ne code en dur aucun nom d'utilisateur, mot de passe ou URL. Utilise des références à des variables d'environnement à la place."

Générer des tests depuis une user story

Ce pattern de prompt est particulièrement utile. Collez une user story directement et demandez des tests :

"Tu es un ingénieur QA automation. Voici une user story :

'En tant qu'utilisateur connecté, je veux ajouter un nouvel article à ma liste de voyage afin de pouvoir suivre ce que je dois emballer.'

L'application est à https://lab.becomeqa.com. Écris des tests Playwright TypeScript qui couvrent : le chemin nominal (l'article est ajouté et apparaît dans la liste), l'ajout d'un article en double, et l'ajout d'un article dont le nom dépasse la limite de caractères. Utilise des locators getByRole. Inclus une assertion par test qui vérifie le résultat spécifique. Retourne uniquement le code de test."

Générer des données de test

Pour la génération de données de test, la syntaxe de Faker.js change entre les versions et les modèles IA hallucinent parfois des noms de méthodes. Ancrez votre demande :

"Génère une fonction factory TypeScript qui crée un objet utilisateur aléatoire avec les champs : email (format valide), firstName, lastName, password (au moins 8 caractères, une majuscule, un chiffre). Utilise uniquement la syntaxe @faker-js/faker v8. Retourne juste la fonction."

Prompts pour la révision de code

La révision de code par IA est sous-utilisée par les ingénieurs QA. Elle est particulièrement efficace pour repérer ce qui est facile à rater à la première lecture.

Révision pour la qualité des tests :

"Révise ce test Playwright pour : les attentes codées en dur (page.waitForTimeout), les sélecteurs CSS, les assertions manquantes, les tests qui dépendent de l'ordre d'exécution, et les pratiques qui réduisent la stabilité des tests. Liste chaque problème avec le numéro de ligne et explique pourquoi c'est un problème."

Révision pour la cohérence du Page Object Model :

"Je construis un Page Object Model en TypeScript. Voici ma classe de base et un page object. Vérifie si : tous les sélecteurs sont dans la classe page (pas dans les tests), les méthodes d'action retournent correctement des promesses, le constructeur suit le pattern, et si la classe manque des méthodes utiles basées sur ce qui est importé. Suggère des ajouts spécifiques."

Vérification de la qualité des locators :

"Regarde ces locators de mes tests Playwright. Pour chacun, dis-moi : est-il fragile (susceptible de se casser lors d'une refonte UI) ? Si oui, suggère une alternative plus stable avec des locators sémantiques."

Prompts pour le débogage

Quand un test échoue et que vous ne savez pas pourquoi, l'IA peut aider, mais vous devez lui donner le message d'échec, pas seulement le code.

Template pour l'aide au débogage :

"Ce test Playwright échoue. Voici :

1. Le code du test

2. Le message d'erreur complet et la stack trace

3. Ce que l'application est censée faire

[collez chacun]

Quelles sont les causes les plus probables de cet échec ? Listez-les par ordre de probabilité, et pour chacune, expliquez ce que je devrais vérifier."

Le message d'erreur est critique. Sans lui, le modèle fait des suppositions. Avec lui, il peut souvent identifier le problème précis : un await manquant, un locator qui ne correspond pas, un problème de timing.

Diagnostic de test flaky :

"Ce test passe environ 70% du temps et échoue 30% avec cette erreur : [erreur]. Le test fait : [décrivez le flux]. Quelles sont les causes probables de cet échec intermittent dans Playwright ? Que vérifieriez-vous en premier ?"

Prompts pour la documentation

Générer de la documentation pour du code de test existant est l'un des usages les plus rentables de l'IA en QA. Personne n'aime l'écrire, ça prend du temps, et l'IA le fait raisonnablement bien.

Générer un README pour une suite de tests :

"Écris une section README pour ce répertoire de suite de tests Playwright. Inclus : ce que la suite couvre, les prérequis (variables d'environnement requises, étapes de setup), comment exécuter tous les tests, comment exécuter un fichier spécifique, et comment exécuter en mode debug. Base-toi sur ce playwright.config.ts et ce fichier de test d'exemple : [collez les deux]"

Résumer la couverture de tests :

"Voici mes fichiers de tests Playwright. Pour chaque fichier, écris une phrase décrivant ce qu'il teste. Puis écris un paragraphe récapitulatif de ce qui est couvert et de ce qui manque en fonction des flux typiques d'une application web avec connexion, gestion de données et fonctionnalités d'export."

Générer un rapport de bug depuis un test en échec :

"Ce test Playwright échoue et je dois écrire un rapport de bug. Voici le test, l'erreur et les screenshots. Écris un rapport de bug dans ce format : Titre, Environnement, Étapes de reproduction, Résultat attendu, Résultat réel, Sévérité."

Prompts pour apprendre

Quand vous apprenez une nouvelle fonctionnalité de Playwright, ne demandez pas des exemples génériques. Demandez des exemples spécifiques à votre type de projet :

"Explique comment fonctionne le storageState de Playwright, avec un exemple concret où une suite de tests a des rôles admin et utilisateur standard. Montre le fichier de setup qui génère les états et un test qui utilise chaque rôle. Utilise TypeScript."

"Je comprends comment fonctionne page.route() pour le mocking simple. Explique comment utiliser route.fallback() pour simuler partiellement une API, en laissant passer certaines requêtes vers le vrai backend tout en n'interceptant que des requêtes spécifiques. Montre un exemple concret."

La contrainte concrète force le modèle à dépasser l'explication introductive pour aller dans la partie réellement utile.

Quand itérer et quand recommencer

Après avoir obtenu un résultat de l'IA, deux options s'offrent à vous : itérer dessus ou recommencer avec un meilleur prompt.

Itérez quand la structure est correcte mais que quelque chose de précis est faux. Posez des questions ciblées : demandez de changer un locator spécifique, d'ajouter une assertion manquante, ou de refactoriser une fonction utilitaire. Recommencez quand l'approche globale est incorrecte : le modèle a généré du JavaScript au lieu de TypeScript, a produit des tests sans Page Object, ou a mal compris le scénario. Dans ce cas, un meilleur prompt initial est plus rapide que de tenter de le réorienter.

Une bonne heuristique : si vous avez itéré trois fois et corrigez encore des problèmes structurels, recommencez avec un prompt plus détaillé.

Fenêtres de contexte et conversations longues

Les outils IA perdent le contexte au fil de longues conversations. Après 20 échanges ou plus, le modèle peut commencer à "oublier" des éléments que vous avez établis au début. La convention de locators spécifiée ou la structure de classe demandée en sont des exemples.

Trois pratiques aident.

Gardez un document de templates de prompts. Pour les tâches courantes (générer un test, réviser un page object, écrire un rapport de bug), sauvegardez vos meilleurs prompts. Ne les retapez pas. Copiez et ajustez. Démarrez une nouvelle conversation pour chaque tâche. Un contexte réutilisable dans une conversation crée de la confusion dans une autre. Les conversations courtes et ciblées produisent de meilleurs résultats que les sessions tentaculaires. Réaffirmez les contraintes clés si le résultat dérive. Si le modèle commence à utiliser des sélecteurs CSS après que vous lui ayez dit de ne pas le faire, rappelez-le explicitement : "Rappel : uniquement getByRole, getByLabel, getByPlaceholder, getByTestId. Pas de sélecteurs CSS."

Ce que les outils IA ne peuvent pas faire pour les QA

Comprendre les limites évite la frustration et aide à savoir quand arrêter d'essayer.

Ils ne peuvent pas exécuter vos tests. Le modèle n'a pas accès à votre navigateur, votre application, ni votre test runner. Il peut écrire du code qu'il croit fonctionnel, mais ne peut pas le vérifier. Ils ne peuvent pas inspecter votre application en direct. Sans Playwright MCP configuré, le modèle ignore à quoi ressemble votre UI. Il écrit des tests contre une version imaginaire de votre application basée sur ce que vous décrivez. Si votre description est incomplète, les locators générés seront faux. Ils hallucinent des détails d'API. Les outils IA génèrent parfois des appels de méthodes Playwright inexistants, ou utilisent de vraies méthodes avec de mauvaises signatures de paramètres. Vérifiez toujours le code généré contre la documentation Playwright avant de le committer. Ils ne connaissent pas les conventions de votre équipe. Sans que vous ne colliez votre code réel pour contexte, le modèle ne sait pas si votre équipe utilise des factories ou des fixtures pour les données de test. Il ignore aussi comment votre classe de base fonctionne, ou à quoi ressemble votre structure d'imports. Donnez-lui des exemples. Ils ne peuvent pas prendre des décisions sur la couverture. "Que dois-je tester ?" nécessite de comprendre le risque de la fonctionnalité, la vélocité de l'équipe, ce qui a échoué en production, et le niveau de risque acceptable. L'IA peut suggérer des choses à tester, mais les décisions de couverture vous appartiennent.

Construire une bibliothèque personnelle de prompts

Au fil du temps, collectez les prompts qui fonctionnent. Gardez-les dans un fichier markdown, une page Notion, ou un dossier .claude de commandes dans votre projet.

Catégories utiles à développer :

Générer un nouveau test depuis une description
Réviser un fichier de test pour des problèmes de qualité
Générer des données de test avec Faker
Écrire une classe Page Object depuis la description d'une page
Déboguer une erreur Playwright
Générer un rapport de bug depuis un test en échec
Résumer les lacunes de couverture de tests
Générer du YAML de workflow CI pour Playwright

Chaque prompt est un petit investissement dans une qualité consistante. Vous n'avez pas à réinventer l'approche chaque fois que vous vous asseyez avec un outil IA.