Un QA de Cloud.ru a ramené une tâche d'autotests d'une demi-journée à 1 à 1,5 heure grâce à OpenSpec

L'agent a écrit les tests, le code est propre, pytest affiche du vert. Peut-on clore la tâche ? Pas si sûr. Un ingénieur QA de Cloud.ru raconte comment, après plusieurs cas de ce genre, il a mis en place un processus à quatre agents fondé sur des spécifications. Il passe désormais plus de temps sur les exigences et les risques que sur le code lui-même.

Un test vert qui ne prouve rien

Le projet comporte une fonctionnalité de publication de la structure de documentation dans Git. Si, lors d'une nouvelle publication, une section disparaît de la structure, le fichier correspondant doit être supprimé du dépôt. L'agent a écrit le test test_update_structure_removes_orphan_doc_file. Il publie la structure avec les sections overview et setup, puis la republie sans setup, clone le dépôt et vérifie que le fichier setup n'existe pas.

Cela semble raisonnable : on vérifie l'état réel de Git, et pas seulement la réponse de l'API. Mais avant la suppression, l'agent ne s'est jamais assuré que le fichier existait. La présence du document était confirmée via get_repowiki_docs(), or cette méthode peut renvoyer des métadonnées sans consulter le dépôt lui-même. Si le fichier n'est pas apparu lors de la première publication, le test passe quand même : après la seconde publication, il est également absent. Le test vérifie l'état final, mais pas la transition « le fichier était là — il n'y est plus ».

L'auto-vérification de l'agent développeur ne l'a pas détecté : il a analysé la logique du test, mais n'a pas mené d'expériences. Le problème a été trouvé par un autre agent, le relecteur. Ensuite, une étape avec repowiki_repo_clone() as clone_before a été ajoutée au test, afin de vérifier la présence du fichier avant la republication. La même classe d'erreurs se rencontre dans des cas simples : l'agent vérifie le code HTTP 400, mais ne regarde pas la structure du corps de l'erreur.

Comment fonctionne le processus

L'auteur ouvre Claude Code et transmet à l'agent principal, l'orchestrateur, le numéro d'une tâche Jira. Les règles sont décrites dans le fichier CLAUDE.md du dépôt : quels agents existent, de quoi ils sont responsables, comment passer d'une étape à l'autre et quand la confirmation humaine est nécessaire. Il y a actuellement quatre agents :

• test-planner étudie la tâche et les tests existants et crée un OpenSpec change. On y trouve proposal.md (pourquoi), design.md (approche et contraintes) et tasks.md (étapes concrètes). Le plan passe ensuite par openspec validate --strict.
• test-qa-writer implémente les tests selon tasks.md et coche les points réalisés.
• test-reviewer confronte l'implémentation à la spécification et aux conventions d'architecture. Il n'exécute pas lui-même les tests : il travaille uniquement sur le code et les artefacts.
• docs-writer met à jour la documentation.

L'humain intervient à deux moments. Le premier, après le plan : il vérifie que l'agent a bien compris la tâche, qu'aucun cas n'a été oublié et que la solution s'intègre à l'architecture du projet de tests. Les points litigieux de logique métier, il les clarifie auprès des développeurs. Le second, après la relecture : l'orchestrateur présente sa conclusion, et c'est l'humain qui décide de retravailler ou d'archiver.

Dans le change restent qa-report.md et review.md. La tâche conserve ainsi son historique : ce qui était prévu, ce qui a été fait et quelles remarques ont été soulevées.

Un contrôle anti-« n'importe quoi »

En plus de la relecture, l'auteur effectue de vraies exécutions et vérifie la sensibilité des tests. Par exemple, il modifie volontairement la valeur attendue dans l'assert et regarde si le test échoue. Ce n'est pas du véritable test de mutation du service, mais un moyen peu coûteux de s'assurer que les assertions vérifient réellement quelque chose.

Il y a aussi une réserve honnête. Le développeur et le relecteur peuvent fonctionner sur le même modèle. La séparation des rôles ne rend pas la vérification totalement indépendante, mais elle modifie le point de vue et les critères d'évaluation. C'est précisément ce schéma qui a détecté le problème du fichier setup.

Ce qu'on peut en retenir

L'auteur évalue le gain ainsi : au lieu d'une demi-journée de travail, la tâche prend environ une heure à une heure et demie, et les agents effectuent une partie du travail pendant qu'il s'occupe d'autre chose. L'estimation est approximative, et il s'agit de l'expérience d'une seule personne sur un seul projet. Pour les petites tâches, il admet lui-même une simplification du processus.

Conclusions pratiques pour les équipes qui délèguent les tests à des agents :

• Incluez dans les critères d'acceptation la vérification de l'état initial, et pas seulement de l'état final. Pour tout test du type « après l'action X, quelque chose a changé », il faut une étape confirmant que cela n'existait pas avant X.
• Ne prenez pas l'auto-vérification de l'exécutant pour une relecture. Une passe distincte, avec un autre rôle et un autre prompt, détecte ce que l'auteur du code ne voit pas.
• Conservez les spécifications et les conclusions de relecture dans le dépôt, à côté du code.
• Gardez l'humain à deux carrefours : la validation du plan et la recette du résultat.

L'article original analyse ensuite un cas de CRUD pour les tags Git : il y avait trois tests sur GET /tags qui ne vérifiaient que le champ name, et aucune couverture pour POST et DELETE. Mais la conclusion principale ressort déjà de la description du processus. Les agents prennent en charge l'implémentation, mais l'humain reste responsable des exigences et de la qualité finale.