L’équipe de Dokumenterra confie à Claude la rédaction de tests automatisés en cinq heures

Après la mise en production d’une fonctionnalité, il faut à nouveau décrire son comportement à la personne chargée des tests, puis transformer les scénarios en tests automatisés. Chez Dokumenterra, l’équipe a essayé de s’appuyer sur la documentation produit : Claude la lit, élabore des cas de test et rédige les tests. L’exemple de la récupération du mot de passe permet de voir concrètement ce qui est produit et à quels moments une personne doit vérifier les hypothèses du modèle.

Selon le directeur technique de l’entreprise, la préparation des requêtes pour une fonctionnalité prend une heure, puis Claude travaille encore cinq heures. Il s’agit d’une estimation tirée du témoignage de l’équipe. L’article ne fournit ni comparaison avec le développement manuel des tests, ni coût des exécutions, ni statistiques sur les erreurs. Il est donc encore impossible de chiffrer le gain.

D’une procédure à deux tests

Dans l’exemple présenté, l’agent reçoit une procédure de récupération du mot de passe : ouvrir la page de connexion, suivre le lien de récupération, saisir son identifiant ou son adresse e-mail et demander l’envoi d’un message. Il consulte la documentation via MCP, une connexion qui lui donne accès à des outils de recherche et de lecture des pages.

À partir de cette procédure, Claude élabore deux scénarios. Le premier vérifie que le lien figurant sur la page de connexion ouvre le formulaire de récupération. Le second vérifie qu’un identifiant laissé vide déclenche une erreur de validation et que l’utilisateur reste sur la même page. Des tests automatisés sont ensuite produits pour contrôler l’adresse de la page, la visibilité des champs et le message d’erreur.

Le second scénario comporte un détail essentiel : la procédure initiale ne dit rien d’un champ vide. Le modèle a proposé de lui-même le comportement attendu. C’est une base utile pour la personne chargée des tests, mais elle doit être confrontée aux exigences du produit. Une hypothèse plausible ne devient pas une règle simplement parce que l’agent l’a traduite en test.

Le code présenté s’appuie également sur des fixtures existantes et sur l’objet de page ForgotPasswordPage. Cet exemple ne montre donc pas la création de toute l’infrastructure de test à partir de zéro. Par ailleurs, ces deux vérifications ne couvrent pas l’ensemble du parcours de récupération du mot de passe : réception du message, ouverture du lien et définition d’un nouveau mot de passe.

Deux revues restent entre les mains des humains

L’équipe décrit deux étapes manuelles obligatoires. Une personne vérifie d’abord la documentation, puis les cas de test élaborés par le modèle. Elle supervise ensuite la création des tests automatisés.

La première revue protège contre les exigences obsolètes. Si la procédure décrit un comportement que le produit a déjà modifié, l’agent peut reproduire fidèlement cette erreur dans les scénarios. Dans ce cas, une exécution réussie montrera seulement que les tests correspondent à une attente erronée.

La seconde revue sert à vérifier la couverture des tests. Un spécialiste qui connaît les utilisateurs peut repérer des conditions, des rôles ou des exceptions oubliés. Dans l’exemple de récupération du mot de passe, il faut notamment se demander quels scénarios prévoir pour un lien expiré et pour une nouvelle demande d’envoi du message. Ce sont des compléments possibles au plan de test ; l’article ne montre pas que l’équipe les a mis en œuvre.

L’auteur lui-même le précise : l’utilisation du serveur MCP est récente et les résultats sont préliminaires. L’exploitation des informations contenues dans les captures d’écran n’a pas non plus été vérifiée. Le serveur renvoie du Markdown avec des liens vers les images, mais l’équipe n’a pas encore déterminé si l’agent en extrait les informations nécessaires.

Ce que votre équipe peut reprendre

L’intérêt pratique de ce cas réside dans l’organisation du processus. L’agent reçoit la description d’une fonctionnalité, une tâche, une PR et les cas de test existants. Il recherche lui-même la documentation, puis propose un plan de test. La personne chargée des tests dispose ainsi d’une base concrète à examiner.

Des contraintes précises sont particulièrement utiles dans ce processus. Indiquer que le produit prend en charge le téléversement de fichiers ne définit pratiquement aucun résultat attendu. Préciser la taille maximale et l’erreur exacte permet déjà de concevoir des tests aux limites. Si une règle se prête à plusieurs interprétations, il faut d’abord s’accorder sur le comportement, puis le formaliser dans un test.

Dans ce cas, MCP donne accès aux pages actuelles, y compris aux contenus privés lorsque les autorisations le permettent. Le témoignage ne signifie toutefois pas que cette approche serait impossible sans lui : pour une expérimentation limitée, on peut transmettre à l’agent un extrait choisi de la documentation. La connexion ne garantit pas non plus, à elle seule, que le texte est à jour et exact.

On peut commencer par une seule fonctionnalité : vérifier sa description, obtenir les scénarios, valider les résultats attendus, puis seulement lancer la génération du code. Pour évaluer l’intérêt de la démarche, il convient de mesurer le temps de préparation et de revue, le nombre de corrections et la stabilité des tests lors des modifications suivantes. Le cas de Dokumenterra fournit un protocole reproductible pour ce type d’expérimentation, mais ne démontre pas encore des économies pour toutes les équipes.