Comment utiliser Claude Code pour automatiser l’assurance qualité

Ce que Claude Code peut faire dans un processus d’assurance qualité

• Générer des tests unitaires pour un module, en respectant le style et le framework existants du projet.
• Transformer un rapport de bug en test de non-régression qui échoue, puis corriger le code jusqu’à ce que le test réussisse.
• Ajouter les cas limites manquants à une suite existante (entrée vide, Unicode, délais d’attente, concurrence).
• Écrire des tests de bout en bout pour Playwright ou Cypress et, avec un serveur MCP de navigateur, les exécuter sur une application en fonctionnement.
• Analyser une exécution CI en échec : lire le journal, trouver la cause, proposer ou appliquer la correction.
• Examiner une pull request pour repérer les chemins d’exécution non testés et publier les résultats.

En revanche, il ne peut pas décider de ce qui compte. Il atteindra volontiers 100 % de couverture des lignes avec des tests qui ne vérifient rien d’utile. La qualité du résultat dépend de celle des instructions, c’est pourquoi la configuration ci-dessous commence par le fichier de mémoire plutôt que par le prompt.

Configuration : expliquez-lui comment exécuter les tests

# CLAUDE.md
## Testing
- Unit tests: `npm test` (vitest). Files live next to the source as `*.test.ts`.
- E2E: `npx playwright test`, specs in `e2e/`. Needs the dev server: `npm run dev`.
- Always run the relevant test file after editing it. Do not mark a test `.skip` to make the suite pass.
- Prefer table-driven tests; one behaviour per `it()`; no snapshot tests for logic.

Ce bloc fait la différence entre un agent qui devine et un agent qui se comporte comme un collègue ayant lu le guide de contribution. Ajoutez le style d’assertion souhaité et les pratiques que vous voulez toujours éviter (simuler la base de données, ignorer des tests, modifier les fixtures pour qu’elles correspondent à une sortie incorrecte).

Générer des tests à partir d’une spécification ou d’un rapport de bug

> Read src/billing/prorate.ts. Write vitest tests covering the documented behaviour in
  docs/billing.md, including month boundaries, leap years and a zero-day period.
  Run them; if any fail, tell me whether the code or the doc is wrong before changing code.

> Bug #412: uploading a 0-byte file returns 500 instead of 400. Write a failing test that
  reproduces it, then fix the handler so the test passes. Do not touch other tests.

La dernière phrase de chaque prompt compte. « Dis-moi si c’est le code ou la documentation qui est incorrect » l’empêche de modifier silencieusement le comportement pour satisfaire un test qu’il vient d’inventer ; « ne touche pas aux autres tests » évite le problème classique où il modifie une assertion sans rapport pour faire passer les tests.

La boucle exécution-correction

Demandez-lui d’exécuter le test après l’avoir écrit. Il lit la sortie d’échec, ajuste et relance, généralement en deux ou trois itérations. Surveillez les demandes d’autorisation : autorisez Bash(npm test*) et Bash(npx playwright test*) une fois avec /permissions pour que la boucle ne soit pas interrompue, et conservez une demande d’autorisation pour les commandes destructrices. S’il boucle plus de quatre ou cinq fois sur un même test, arrêtez-le ; le test vérifie probablement la mauvaise chose et une personne devrait l’examiner.

Sans interface graphique en CI

# generate regression tests for whatever changed, non-interactively
git diff --name-only origin/main...HEAD | grep -E 'src/.*\.ts$' > changed.txt
claude -p "For each file in changed.txt, add or extend tests for the changed behaviour. Run them." \
  --allowedTools "Read,Edit,Write,Bash(npm test*),Bash(git diff*)" \
  --max-turns 25 --output-format json > claude-qa.json

Le mode d’affichage ne pose jamais de question : toutes les actions qu’il peut effectuer doivent donc être autorisées à l’avance avec --allowedTools, ainsi que --max-turns limite la boucle. Définissez ANTHROPIC_BASE_URL=https://aiprimetech.io et une clé de passerelle comme secrets CI ; l’exécution sera facturée sur votre solde de passerelle ou votre forfait illimité. Enregistrez le résultat dans un commit sur une branche et faites-le examiner par une personne : ne fusionnez pas automatiquement les tests générés.

Sur chaque pull request : la GitHub Action

La GitHub Action de Claude Code exécute la même boucle lorsque quelqu’un publie un commentaire @claude sur une pull request, ou automatiquement à son ouverture. Une instruction axée sur l’assurance qualité dans le workflow — « examine cette PR pour repérer les branches non testées et ajoute des tests pour celles-ci » — permet un premier examen de chaque PR avant qu’un réviseur ne s’en charge. Le guide GitHub couvre l’installation de l’application, le fichier de workflow et les coûts.

Tests de bout en bout avec Playwright

Deux niveaux. Sans navigateur, il écrit des spécifications de test Playwright à partir de la structure de la page et de votre description, puis vous les exécutez. Avec un serveur MCP Playwright connecté (/mcp), il peut ouvrir l’application, parcourir le scénario en cliquant, lire le DOM et écrire un test qui correspond à ce qu’il a observé — avec des sélecteurs beaucoup plus fiables, au prix d’une session plus longue. Limitez chaque session de navigateur à un seul scénario et /clear entre les sessions ; les captures d’écran et les extractions du DOM sont volumineuses et sont renvoyées à chaque tour.

Limiter le coût des exécutions de tests

• Utilisez la gamme Sonnet ; la génération de tests nécessite rarement Opus. La gamme Haiku convient pour le tri des journaux.
• Ciblez un seul module ou un seul bug à la fois. « Ajoute des tests pour tout le dépôt » est le prompt le plus coûteux qui soit.
• /compact après l’ajout de chaque fichier de test ; les journaux d’échec qu’il a lus ne sont plus utiles.
• En CI, fixez une limite avec --max-turns et exécutez uniquement sur les fichiers modifiés.
• Pour une équipe qui l’utilise quotidiennement, un forfait illimité à prix fixe élimine entièrement la question du coût par token.

Tous les forfaits illimités →

export ANTHROPIC_BASE_URL=https://aiprimetech.io
export ANTHROPIC_API_KEY=your_key

Questions fréquentes

AI Prime Tech est une passerelle API indépendante et n’est ni affiliée à Anthropic, ni approuvée ou parrainée par Anthropic. « Claude » et « Claude Code » sont des marques commerciales d’Anthropic. Les fonctionnalités de Claude Code décrites ici correspondent à la documentation publique d’Anthropic au moment de la rédaction et évoluent fréquemment ; les prix et les listes de modèles de cette page proviennent des paramètres en temps réel de cette passerelle.