Visual Regression Testing avec VisualQ : complétez Playwright en TypeScript sans changer de stack

Pourquoi vos tests Playwright ne suffisent pas seuls

Vous avez une suite Playwright solide. Les flux critiques sont couverts, les assertions sont précises, le CI est vert. Et pourtant, une régression visuelle — au sens du visual regression testing — passe en production : un composant qui déborde, un contraste cassé après une mise à jour de design token, un événement de tracking qui disparaît silencieusement. Playwright n'a rien vu — parce que personne n'avait écrit l'assertion correspondante.

C'est la limite structurelle des tests fonctionnels : ils vérifient exactement ce que vous avez pensé à asserter, ni plus ni moins. Les régressions visuelles, les violations d'accessibilité et les dérives de plan de tracking appartiennent à une autre catégorie de problèmes — des problèmes qui exigent une couche d'outillage dédiée, pas une centième assertion `expect(locator).toBeVisible()`.

La question n'est donc pas "Playwright ou autre chose ?" mais "qu'est-ce que Playwright ne peut structurellement pas voir, et comment le couvrir sans repartir de zéro ?"

Ce que VisualQ ajoute à votre workflow TypeScript

VisualQ s'articule autour de trois couches orthogonales à votre suite existante. La première est le Visual Regression Testing (VRT) : capture de screenshots, stockage de baselines, comparaison avec détection de dérives visuelles (approche layout-aware pour réduire les faux positifs) et review des diffs dans une interface dédiée. La deuxième est le Functional Regression Testing (FRT) : description de scénarios en Gherkin, génération automatique du code Playwright TypeScript par IA, exécution sur un worker managé avec timeline, trace, vidéo et HAR. La troisième regroupe les audits qualité — accessibilité axe-core, Web Vitals, SEO et audit de plan de tracking — directement intégrés comme `Then` steps dans vos scénarios Gherkin (ex. : `Then the page should pass accessibility (axe) with score >= 90`).

Ces trois couches ne remplacent pas vos tests Playwright. Elles couvrent le périmètre que vos tests ne peuvent pas voir : l'apparence rendue, les violations d'accessibilité non assertées, les événements analytics qui n'atteignent jamais le serveur. L'idée est d'ajouter de la surface de détection, pas de migrer une stack.

Concrètement, vous continuez à écrire vos tests Playwright comme avant. VisualQ s'installe à côté, sur vos URLs de staging ou de production, et surveille ce que votre suite ignore par construction.

Visual Regression Testing : baseline pixel-perfect et infrastructure CI managée

La friction habituelle du VRT, c'est l'infrastructure : stocker les baselines quelque part, configurer les seuils de diff dans un YAML, héberger les artefacts de screenshots, gérer les faux positifs liés aux animations ou aux polices. Tout ça avant même d'avoir écrit le premier test.

VisualQ prend en charge l'intégralité de cette infrastructure. Le stockage des baselines, la comparaison des diffs visuels, la review et la validation des changements intentionnels se font dans l'interface — sans bucket S3 à provisionner, sans artefact à héberger dans votre CI. Vous définissez un scénario sur une URL, vous capturez la baseline, et VisualQ détecte les dérives à chaque run suivant.

Pour un développeur TypeScript habitué à gérer lui-même chaque couche de son pipeline de test, c'est un changement de posture notable : la plateforme gère l'opérationnel, vous gardez le contrôle sur ce qui est testé et sur la validation des diffs.

Functional Regression Testing : du Gherkin au Playwright généré par IA

Le FRT de VisualQ part d'un constat simple : les scénarios Gherkin sont lisibles par tout le monde — PMs, QA, développeurs — mais leur maintenance en step definitions TypeScript est coûteuse et reste l'apanage des développeurs. VisualQ court-circuite cette friction en générant automatiquement le code Playwright à partir de vos fichiers `.feature`.

Vous écrivez un scénario `Given/When/Then`, vous sauvegardez, et VisualQ compile le TypeScript Playwright correspondant, l'exécute sur un worker managé (Chromium, Firefox ou WebKit), puis restitue une timeline step-by-step avec screenshots, trace Playwright, vidéo et HAR. Le résultat est consultable dans l'interface ou partageable via une URL de living document publique (opt-in).

Comment la compilation AI fonctionne concrètement

Le pipeline de compilation est déterministe et auditable. Il parse d'abord le Gherkin en AST, puis tente de matcher chaque step contre les step definitions existantes — d'abord au niveau du projet, puis de l'organisation, puis du catalogue système. Seuls les steps non résolus sont envoyés au LLM (Claude Sonnet via OpenRouter), ce qui minimise les appels et garantit la cohérence avec le style de votre projet.

Le code généré n'est pas persisté directement : il passe d'abord une whitelist AST qui autorise uniquement `page.*`, `expect`, `request`, `console` et les helpers injectés `ctx` / `pillar` — `import`, `require`, `process`, `eval` et les `fetch` arbitraires sont rejetés. Ensuite, un typecheck TypeScript valide que le corps généré compile effectivement. Ce n'est qu'après ces deux validations que la step definition est stockée en base avec son hash de déduplication et son entrée dans l'audit log.

En tant que développeur TypeScript, ce pipeline vous est familier : c'est essentiellement un compilateur avec une étape de génération AI au milieu, pas une boîte noire.

Workers managés : Chromium, Firefox, WebKit sans configuration

Faire tourner Playwright en CI avec plusieurs navigateurs demande du travail d'ingénierie : configurer les runners GitHub Actions, gérer les fixtures, paralléliser les runs, stocker les traces et les vidéos. Ce coût est réel et souvent sous-estimé.

Avec VisualQ FRT, les workers sont managés par la plateforme. Chromium, Firefox et WebKit sont disponibles sans configuration de votre côté — pas de Dockerfile à maintenir, pas de matrice de navigateurs dans votre YAML CI. Les artefacts (trace, vidéo, HAR, screenshots) sont stockés et accessibles via des URLs signées directement dans l'interface.

C'est du temps d'ingénierie récupéré sur la plomberie, réinvesti sur les scénarios qui ont de la valeur métier.

Qualité intégrée : accessibilité axe-core directement dans vos scénarios

L'accessibilité est souvent traitée comme un outil séparé — un script axe-core lancé en dehors de la suite de tests, dont les résultats ne sont pas corrélés aux scénarios fonctionnels. VisualQ intègre les audits axe-core directement comme steps Gherkin.

Un step `Then the page should pass accessibility (axe) with score >= 90` suffit pour déclencher l'audit sur la page courante et faire échouer le scénario si le score est en dessous du seuil. Pas d'outil séparé, pas de script maison, pas de corrélation manuelle entre les résultats d'accessibilité et les scénarios fonctionnels.

Pour un développeur qui veut couvrir l'accessibilité sans changer de workflow, c'est la voie la plus directe : l'audit s'exécute dans le même contexte que le reste du scénario, avec les mêmes artefacts de debug.

Intégrations dans votre chaîne outillage existante

Si votre équipe QA travaille déjà avec Xray pour la traçabilité des tests dans Jira, VisualQ FRT s'y connecte directement. Les résultats des runs FRT sont poussés dans Xray Cloud comme Test Executions structurées, avec statut pass/fail et screenshots en pièce jointe — sans export manuel ni script de conversion.

Pour le partage des scénarios avec des parties prenantes qui n'ont pas accès à la plateforme, VisualQ génère une URL de living document publique (opt-in) pour chaque scénario FRT. C'est une alternative concrète aux exports PDF ou aux captures d'écran partagées en Slack : le document est vivant, il reflète le dernier run.

Ces deux intégrations — Xray et living doc — couvrent les deux cas d'usage les plus fréquents : la traçabilité formelle pour les équipes QA structurées, et le partage informel pour les équipes produit qui veulent de la visibilité sans friction.

Ce que VisualQ ne fait pas (et pourquoi c'est intentionnel)

VisualQ ne remplace pas vos tests Playwright unitaires ou d'intégration. Il ne génère pas de tests pour vos composants React isolés, il ne mocke pas vos APIs, il ne s'intègre pas dans votre pipeline de tests unitaires Jest. Ce n'est pas un oubli de roadmap — c'est un choix de périmètre.

Les tests unitaires et d'intégration Playwright que vous écrivez aujourd'hui couvrent la logique applicative, les états de composants, les interactions utilisateur que vous avez modélisées. VisualQ couvre ce que ces tests ne peuvent structurellement pas voir : l'apparence rendue dans un vrai navigateur, les violations d'accessibilité sur la page assemblée, les événements de tracking qui n'atteignent pas le serveur.

Ces deux périmètres sont orthogonaux. Les maintenir séparés, avec des outils dédiés à chacun, est plus robuste que de chercher un outil unique qui ferait tout — et ferait tout moins bien.

Par où commencer en tant que dev TypeScript

Le chemin le plus court vers de la valeur concrète tient en deux étapes, sans migration de stack.

Étape 1 : créez un premier scénario VRT sur une URL existante. Prenez une page critique de votre application — la homepage, une page de checkout, un composant de navigation — et configurez un scénario VRT sur son URL de staging. Capturez la baseline. Vous avez maintenant un filet de sécurité visuel sur cette page, qui s'exécute à chaque run et vous alerte sur toute dérive pixel.

Étape 2 : écrivez un scénario FRT Gherkin pour un flux critique. Choisissez un flux que vous testez déjà en Playwright — connexion, ajout au panier, soumission de formulaire — et réécrivez-le en `Given/When/Then`. VisualQ compile le TypeScript, l'exécute sur un worker managé et vous restitue la timeline complète avec trace et vidéo. Vous obtenez un scénario lisible par votre PM, exécutable sans configuration CI, et extensible avec un step d'accessibilité axe-core en une ligne.

Ces deux actions donnent de la valeur immédiatement, sans toucher à votre suite Playwright existante, sans changer de stack, sans coût d'ingénierie sur l'infrastructure de test.

FAQ

VisualQ remplace-t-il Playwright ?

Non. VisualQ s'ajoute à votre suite Playwright existante. Il couvre le périmètre que Playwright ne peut pas voir par construction : l'apparence rendue (VRT), les violations d'accessibilité non assertées, et les événements analytics qui n'atteignent jamais le serveur.

Faut-il maintenir des step definitions TypeScript avec VisualQ FRT ?

Non. Le pipeline de compilation VisualQ génère automatiquement le code Playwright TypeScript à partir de vos fichiers `.feature` Gherkin. Seuls les steps non résolus sont envoyés au LLM ; les steps déjà connus sont réutilisés depuis le catalogue projet ou organisation.

Quels navigateurs sont supportés sur les workers managés VisualQ ?

Chromium, Firefox et WebKit sont disponibles sans configuration de votre côté — pas de Dockerfile ni de matrice CI à maintenir.

VisualQ s'intègre-t-il avec Jira et Xray ?

Oui. L'intégration Xray (plan Business) importe les résultats de tests visuels directement dans Xray for Jira Cloud sous forme de Test Executions structurées, avec captures d'écran et explications Smart Diff AI.