Agent de QA parti d’un constat : une spécification écrite en Gherkin décrit déjà les tests à faire. QAIA la lit, fait écrire les tests par Claude et les propose dans une pull request, où la revue humaine décide de ce qui entre.
Le parcours
- Entrée, une feature Gherkin, validée légèrement : le modèle lit le Gherkin nativement, sans parseur lourd.
- Génération, un appel unique à l’API Claude avec une sortie structurée : un test pytest + httpx par scénario, qui vérifie le code de statut et le corps de la réponse, plus une configuration commune qui lit l’adresse de l’API testée dans l’environnement, jamais en dur.
- Écriture, uniquement dans le dossier réservé aux tests générés.
- Pull request, ouverte sur une branche dédiée, jamais sur la branche principale, jamais fusionnée automatiquement : la PR est la barrière de revue humaine, et un modèle de workflow fait tourner les tests générés dans la CI du dépôt cible.
- Mode d’essai, pour générer en local sans ouvrir de PR.
Conception
- Architecture hexagonale (ports et adaptateurs) : la génération et la future exécution ne communiquent que par un type de domaine commun, pour que chaque extension s’ajoute sans réécriture.
- Une génération qui ne fait que produire du texte, sans shell ni outil : une spécification est une donnée d’entrée, pas une instruction.
- Qualité de l’outil lui-même, typage strict, lint et tests en CI, et une revue adverse qui a corrigé cinq vrais bugs.
Et ensuite
Déjà réservés dans l’architecture, pas encore construits : les tests E2E Playwright, les tickets Jira ou Linear comme source via MCP, et une exécution agentique qui lance les tests générés, lit les échecs et les corrige avant d’ouvrir une PR au vert.
A QA agent that starts from a simple observation: a specification written in Gherkin already describes the tests to run. QAIA reads it, has Claude write the tests and proposes them in a pull request, where human review decides what gets in.
The pipeline
- Input, a Gherkin feature, lightly validated: the model reads Gherkin natively, no heavy parser needed.
- Generation, a single call to the Claude API with structured output: one pytest + httpx test per scenario, checking the status code and the response body, plus a shared configuration that reads the address of the API under test from the environment, never hard-coded.
- Writing, only into the folder reserved for generated tests.
- Pull request, opened on a dedicated branch, never on the main branch, never merged automatically: the PR is the human review gate, and a workflow template runs the generated tests in the target repository’s CI.
- Dry-run mode, to generate locally without opening a PR.
Design
- Hexagonal architecture (ports and adapters): generation and the future execution only talk through a shared domain type, so each extension is added without a rewrite.
- Generation that only produces text, with no shell and no tools: a specification is input data, not an instruction.
- Quality of the tool itself, strict typing, lint and tests in CI, and an adversarial review that fixed five real bugs.
What’s next
Already reserved in the architecture, not built yet: Playwright E2E tests, Jira or Linear tickets as a source through MCP, and an agentic execution step that runs the generated tests, reads the failures and fixes them before opening a green PR.