Étude de cas · QA Automation Engineer
Industrialiser l'automatisation des tests dans une ETI éditrice de logiciels
Un éditeur de logiciels de taille intermédiaire disposait d'un framework d'automatisation et d'un référentiel de cas de test, mais les deux vivaient séparément et l'exécution des suites restait lente et fragile. Le freelance que nous avons présenté a relié le référentiel au framework, fiabilisé l'exécution en intégration continue et diffusé les pratiques auprès des équipes produit, développement et qualité.
Par L'équipe Top Profil · Mis à jour le · 6 min de lecture
01
La situation de départ
Le client est un éditeur de logiciels de taille intermédiaire qui maintient plusieurs produits et un portail client, avec des équipes produit, développement et qualité réparties par produit. Un framework d'automatisation fondé sur Playwright existait déjà, de même qu'un référentiel de cas de test dans Squash TM. Mais les deux n'étaient pas reliés : tests manuels et automatisés partageaient les mêmes jeux de données, les conventions variaient d'un dossier à l'autre, les suites échouaient sans raison fonctionnelle et un test en attente pouvait bloquer l'exécution pendant plusieurs minutes.
La commande portait sur cinq livrables : un référentiel de tests structuré, avec traçabilité entre user stories, règles de gestion et scénarios automatisables ; une stratégie de test orientée automatisation, avec matrice de priorisation ; un kit de cas de test data-driven prêt à intégrer dans le framework ; un reporting QA automatisé ; et des sessions de partage avec les équipes produit, développement et qualité. Le poste était volontairement transverse, au service de tous les produits.
Le besoin nous est parvenu en début d'année. Nous avons présenté un profil senior de QA automation engineer, évalué sur Playwright, sur l'intégration continue et sur sa pratique de l'IA, et la mission a démarré à temps plein, dans un cadre contractuel sécurisé avec un seul interlocuteur.
02
Les enjeux
Relier le référentiel et le framework
Les cas de test documentés dans Squash TM et les scénarios Playwright évoluaient chacun de leur côté. Sans lien, impossible de savoir quelle exigence était réellement couverte, ni de rendre compte des résultats d'exécution dans le référentiel.
Rendre l'exécution rapide et fiable
Les délais d'attente par défaut, les mécanismes de relance et l'installation des dépendances à chaque lancement allongeaient les exécutions. Des tests échouaient pour des raisons d'environnement et non de produit, ce qui érodait la confiance des équipes dans les résultats.
Couvrir plusieurs produits, environnements et versions
Le même framework devait exécuter des tests sur plusieurs produits, sur des environnements aux contraintes d'accès différentes et sur plusieurs versions du produit, sans dupliquer le code ni les jeux de données.
Diffuser les pratiques au-delà de la mission
Un poste transverse n'a de sens que si les équipes s'approprient le référentiel et le framework. La documentation, les revues de code et les conventions comptaient autant que les tests écrits.
03
La démarche, mois après mois
Les étapes vont d'une prise en main outillée à la transmission des travaux.
- 01
Prendre en main et tracer une feuille de route
Le premier mois a été consacré à la prise en main du portail client et du framework, puis à une feuille de route de l'automatisation. Les premières optimisations ont porté sur l'harmonisation du code et l'intégration d'une correction automatique du code. Les jeux de données ont été séparés entre tests manuels et automatisés, condition préalable à toute exécution parallèle.
- 02
Relier Squash TM à Playwright et accélérer les suites
Le freelance a développé une intégration entre Squash TM et Playwright pour exécuter des tests data-driven à partir des cas du référentiel, et conçu des helpers d'API qui préparent les prérequis d'un test sans passer par l'interface. Les délais d'attente et les relances ont été revus : le délai d'attente par défaut est passé de huit minutes à trente secondes. Une documentation de bonnes pratiques a été rédigée sur Confluence.
- 03
Industrialiser l'exécution en intégration continue
Les mois suivants ont porté sur la chaîne d'intégration continue : installation optimisée des dépendances, pool d'agents pour paralléliser les pipelines, environnements supplémentaires. Les tests ont été organisés par type, smoke ou régression, avec lancement planifié ou manuel, et le framework a appris à gérer plusieurs versions du produit à l'exécution. Les tests en échec ont été corrigés et les scénarios réécrits par étape pour s'aligner sur les cas de Squash TM.
- 04
Étendre et homogénéiser la couverture
Sur ce socle, le freelance a automatisé les scénarios prioritaires à partir des jeux de données de Squash TM, créé des opérations de création, lecture, mise à jour et suppression via API pour préparer les prérequis, et adapté le dépôt pour homogénéiser la couverture entre produits. Des tickets techniques ont cadré les améliorations, une convention de nommage a été appliquée au dépôt et l'équipe a été accompagnée dans sa montée en compétences.
- 05
Boucler la traçabilité entre exécution et référentiel
L'import automatique des résultats d'exécution dans Squash TM a fermé la boucle : chaque test automatisé est relié à un cas du référentiel et y rapporte son état. Des fixtures reposant sur des comptes utilisateurs dédiés ont rendu l'exécution parallèle sûre, et l'injection par API des données de référence nécessaires aux tests a remplacé une préparation manuelle. Un POC de tests visuels a préparé de nouveaux scénarios.
- 06
Exploiter, remonter les anomalies et transmettre
Les derniers mois ont suivi le rythme des livraisons : adaptation des tests aux nouvelles versions, remontée des anomalies détectées par l'automatisation, puis liaison automatique entre les bugs ouverts dans Azure DevOps et le framework. Le freelance a finalisé les travaux en cours et produit une documentation couvrant la majorité des réalisations de l'année.
04 · IA
La place de l'IA dans la mission
Avant la mission, nous avons évalué la pratique de l'IA du freelance, critère éliminatoire pour chaque profil que nous présentons. En entretien, en partage d'écran, nous avons regardé comment il produit un test Playwright à partir d'un parcours avec un assistant de code, puis comment il relit ce qui est généré : assertions utiles, sélecteurs robustes, données isolées, absence de faux positifs. Le socle livré pendant la mission, helpers d'API, fixtures, convention de nommage et documentation, est précisément ce qui rend une génération assistée de tests exploitable.
05
Ce que l'équipe a obtenu
- Un référentiel Squash TM relié au framework Playwright dans les deux sens : les tests s'exécutent à partir des cas et des jeux de données du référentiel, et les résultats y sont importés automatiquement.
- Des suites plus rapides et plus fiables en intégration continue : délai d'attente par défaut ramené de huit minutes à trente secondes, pipelines parallélisés, tests en échec corrigés.
- Un framework commun à plusieurs produits, environnements et versions, avec des tests organisés par type, smoke ou régression.
- Une documentation de bonnes pratiques sur Confluence, une convention de nommage appliquée au dépôt et une documentation de fin d'année couvrant la majorité des réalisations.
- Des anomalies détectées par l'automatisation après chaque livraison de version, avec les bugs d'Azure DevOps reliés au framework.
FAQ
Vos questions sur cette mission
Un éditeur qui maintient plusieurs produits avec un même framework a intérêt à confier l'outillage commun à une seule personne : conventions, helpers d'API, configuration de la CI, lien avec le référentiel. Le poste transverse ne remplace pas les QA de chaque produit, il leur donne un cadre commun.
Dans cette mission, la première intégration data-driven entre Squash TM et Playwright a été livrée dès le deuxième mois. La boucle complète, avec l'import automatique des résultats, a demandé environ six mois, parce qu'elle supposait d'abord des données isolées, une CI fiable et des conventions communes.
Un QA automation engineer senior, à l'aise avec Playwright, mais surtout capable de travailler sur la chaîne d'intégration continue, sur les API du produit et sur la documentation. Une bonne part du travail a porté sur l'outillage et la diffusion des pratiques, pas sur l'écriture de scénarios.
Par un entretien technique et comportemental mené par un ingénieur, en partie en partage d'écran. Nous avons regardé comment il structure un framework Playwright, comment il diagnostique un test instable en CI et comment il utilise un assistant de code pour produire puis relire un test. Sans pratique de l'IA démontrée, nous ne donnons pas suite. Le profil a été présenté en moins de 48h.
Étude rédigée par L'équipe Top Profil.
Publiée le , mise à jour le .
Un besoin proche de cette mission ?
Précisez votre contexte. Un expert Top Profil vous rappelle sous 1 jour ouvré.