Il y a quelques mois, j’ai repris un framework de tests de parité en Playwright/Cucumber.
Son job : valider qu’une plateforme data ClickHouse migrant vers le cloud renvoyait exactement les mêmes résultats que la version on-premise. 55 scénarios couvrant des use cases variés, des payloads complexes avec filtres et agrégations, et pour chaque test une comparaison stricte des réponses.
Le framework a fait son job. La migration a été validée. Et c’est là que ça devient intéressant : que faire de ces 55 tests une fois leur mission terminée ? Les supprimer ? Les laisser tourner pour rien ?
J’ai proposé une transformation : passer du testing fonctionnel à l’observabilité continue. Les mêmes payloads, mais utilisés différemment: non plus pour comparer des résultats, mais pour mesurer les temps de réponse en production, toutes les heures.
Concrètement, ça implique plusieurs changements :
- Sélectionner 15 queries représentatives parmi les 55, avec une méthodo data-driven : poids des payloads, taille des réponses, nombre de lignes. Objectif : 3 tiers (small/medium/large) qui couvrent l’essentiel sans polluer avec des outliers.
- Tester deux cibles en parallèle : l’API publique et ClickHouse en direct. Si une régression arrive, on sait immédiatement si ça vient de la couche API ou de la base.
- Changer de stack : Playwright → k6 + Prometheus + Grafana, déployé en GitOps sur Kubernetes. L’app est conteneurisée (image Docker buildée par GitLab CI), orchestrée par un CronWorkflow Argo Workflows toutes les heures, et les credentials sont gérés en Infrastructure-as-Code (Terragrunt) puis synchronisés depuis Google Secret Manager via External Secrets Operator. Pas du load testing : du monitoring horaire en prod qui alimente des dashboards, avec un check intégré qui passe le workflow en erreur si le sink Prometheus tombe — pas de pourrissement silencieux des données.
- Le plan initial était plus simple — InfluxDB + cron sur une VM — mais l’écosystème de déploiement de l’équipe poussait vers Argo Workflows et Kubernetes. Pivot acté en cours de route.
- Valider avec l’équipe Data avant de coder, pour que la sélection finale ait du sens côté business et pas juste côté QA.
La vraie leçon : un test suite a un cycle de vie. Savoir quand elle a fini sa mission initiale, et comment la faire évoluer, c’est aussi important que savoir l’écrire.