QA Panel - Quand les DevTools ne suffisent plus

Le constat

Le workflow QA classique : reproduire un bug, ouvrir les DevTools, faire une capture d’écran, copier l’URL, noter l’environnement technique, rédiger un ticket Jira avec toutes ces infos. Chaque étape est une micro-friction. Cumulées sur une journée de test, elles mangent un temps considérable.

Le pire, c’est le ticket qui arrive côté dev : « Ça marche pas sur la page X ». Pas de contexte technique, pas de capture, pas de version de l’app, pas de requêtes réseau. Le développeur passe 30 minutes à reproduire ce que le testeur a déjà reproduit.

L’idée : un panneau directement dans les DevTools qui fusionne tout, enregistrement des actions, capture de contexte, inspection d’éléments, monitoring réseau, et qui génère un ticket structuré en un clic.

Ce que ça fait

On ouvre les DevTools, on va dans le panneau QA Panel. On clique sur « Enregistrer ». L’extension capture les interactions : clics, navigations, saisies. En parallèle, elle surveille les requêtes réseau (XHR, fetch) et note celles qui échouent.

On peut à tout moment capturer l’écran, CDP (Chrome DevTools Protocol) sur Chrome, fallback captureVisibleTab sur Firefox, et annoter la capture directement dans le canvas intégré. On peut inspecter un élément avec un sélecteur CSS intelligent qui identifie le composant concerné.

Quand le bug est reproduit, on clique sur « Générer le rapport ». L’extension produit un bloc Markdown structuré avec :

• Les actions enregistrées (séquence de reproduction)
• Les captures d’écran annotées
• Les requêtes réseau en erreur avec le status et le body décodé
• L’environnement technique (user agent, viewport, version de l’app)
• Un timestamp de chaque étape

Le testeur copie, colle dans Jira, c’est fini. Le développeur reçoit un ticket avec la séquence exacte de reproduction et le contexte technique complet.

Le bonus Playwright

La fonctionnalité qui a surpris : l’export en code Playwright. Les actions enregistrées sont transformées en scénario de test E2E. Le testeur reproduit le bug manuellement, l’extension génère le test automatisé correspondant. Le développeur peut le lancer directement pour vérifier sa correction.

C’est le pont entre QA manuelle et QA automatisée. Le testeur fait son travail normalement, l’extension produit le test en arrière-plan.

WXT, ou comment écrire une extension sans souffrir

WXT est un framework pour extensions navigateur. Il gère la complexité du manifest (Chrome MV3, Firefox MV2), le hot reload, et fournit une abstraction propre des différentes zones : popup, background, devtools panel, content script.

Le devtools panel est une mini-app Vue 3.5 complète avec son propre DOM, ses propres styles (Totem en Soft Minimal), son propre state (Pinia 3, 5 stores). Le content script intercepte les interactions utilisateur et les pousse au panel via chrome.runtime.sendMessage. Le background service worker gère le monitoring réseau.

extension/
├── devtools/     → enregistrement du panneau
├── panel/        → UI principale (Vue 3.5)
├── popup/        → création rapide de tickets
├── background.ts → service worker (réseau)
└── content.ts    → sélection d’éléments, actions

20 composants Vue, 14 composables, ~8 000 lignes de code. Validation des données avec Zod 4 pour les schemas (issue, action, network, context, scenario).

L’état du projet

QA Panel est en phase de prototypage intensif. ~8 000 lignes de code, 0 commits git, tout le code existe mais n’est pas encore versionné. Le project-context.md est marqué « phase-0-complete ». Le projet attend son premier commit et ses premiers vrais testeurs.

Ce que j’en retiens

Les meilleurs outils naissent de la friction quotidienne. Le gap entre « le testeur a reproduit le bug » et « le développeur comprend le bug » est un gouffre que chaque équipe traverse des dizaines de fois par jour. QA Panel ne fait rien de magique, il capture ce qui existe déjà et le met en forme. Mais c’est exactement ce qui manquait.