Accueil / Étude de cas : migration d'une recette
Migrer 1 300 tests manuels vers une recette automatisée
Une migration d'une recette manuelle à une recette automatisée, en cours, sur l'application de gestion de référentiels d'un groupe agro-industriel. Le nom du client reste confidentiel.
1 · ContextePrésentation du contexte
L'application gère les données de référence d'un groupe agro-industriel : une trentaine d'entités liées entre elles, chacune avec ses champs obligatoires, ses règles de saisie et ses dépendances. J'interviens en freelance, comme QA Automation.
2 · ProblèmeProblème initial
- La recette reposait sur des vérifications faites à la main, à refaire entièrement à chaque livraison.
- Avec 30 entités liées, une seule donnée incohérente peut fausser plusieurs écrans.
- Les équipes métier qui valident la recette ne lisent pas de code de test.
3 · PérimètrePérimètre de la mission
- Migration des 1 300 tests manuels de validité et de cohérence des données vers Playwright.
- Parcours utilisateurs automatisés de bout en bout.
- Cahiers de recette par entité.
- Diagnostic des tests instables et suivi des lancements.
4 · TechnologiesTechnologies
- Playwright et TypeScript pour l'ensemble des tests.
- Azure DevOps dans l'environnement du projet.
- Rapports d'exécution Playwright, exploités par un outil de suivi développé pour la mission.
5 · MéthodeMéthode utilisée
- Migration de la recette manuelle existante vers une recette automatisée, entité par entité.
- Tests construits sur un socle commun, pour qu'une nouvelle entité se branche sans repartir de zéro.
- Scénarios de bout en bout qui passent par l'interface, puis remettent les données dans leur état d'origine.
- Un cahier de recette par entité, rédigé à partir des cas de test : objectif, étapes, résultat attendu.
6 · DifficultésProblèmes techniques rencontrés
Un clic absorbé par un widget
Le clic sur une ligne entière de tableau tombait parfois sur un widget qui absorbait l'événement. Le bouton Éditer ne s'activait pas et le test échouait sans raison visible.
Une recherche qui ramenait la mauvaise ligne
La recherche globale fonctionnait par mots-clés : chercher « Mantem 2 » remontait aussi « Mantem 1 », et le test vérifiait une autre fiche que celle attendue.
Des rapports isolés
Chaque lancement produisait un rapport JSON séparé, sans vue d'ensemble de l'évolution des durées et des échecs.
Des échecs difficiles à interpréter
Il fallait distinguer les vrais bugs de l'application des tests fragiles avant de corriger quoi que ce soit.
7 · SolutionsSolutions mises en œuvre
- Clic ciblé sur la cellule Code, puis attente explicite de l'état du bouton avant d'agir.
- Recherche par Code, identifiant unique, pour la vérification comme pour la restauration des données.
- Un outil qui importe les rapports Playwright et suit, sur les 10 derniers lancements, durées, réussites et échecs, avec un historique partagé.
- Un diagnostic des échecs assisté par l'IA pour isoler les vrais bugs, puis une correction à la racine.
8 · RésultatsRésultats constatés
- Une recette automatisée de 1 300 tests Playwright/TypeScript, lançable à chaque déploiement.
- Des tests stabilisés : le correctif du clic ciblé a été réutilisé sur les autres écrans.
- Plus de faux négatifs liés à la recherche, et un jeu de données restauré à l'identique.
- Les dérives de durée des lancements sont visibles dans le tableau de bord.
- Un cahier de recette par entité, que le métier peut dérouler.
9 · EnseignementsCe que je retiens
- Sélectionner par identifiant unique plutôt que par libellé : moins d'ambiguïté, des données restaurables.
- Attendre un état explicite de l'interface plutôt qu'un délai fixe.
- Séparer les vrais bugs des tests fragiles avant de corriger.
- Écrire la recette dans la langue du métier, alignée sur ce que vérifient les tests.
Automatisation de tests Playwright : la prestation en détail →
Un référentiel ou une application à fiabiliser ?
Décrivez votre contexte. Je vous réponds par email sous 48 heures ouvrées.