report

Présentation de report skill

Ce que fait report skill

Le skill report est un workflow de reporting de tests centré sur Playwright, conçu pour transformer des résultats bruts en un rapport d’état clair. Il est utile lorsqu’un utilisateur demande un « rapport de tests », un « résumé des résultats », un « état des tests », à « afficher les résultats », un « tableau de bord de tests » ou à savoir « comment se sont passés les tests ». Plutôt que de se limiter à résumer un log de terminal, report skill guide l’agent pour vérifier les sorties Playwright existantes, relancer les tests si nécessaire, analyser les résultats JSON et produire un rapport exploitable dans le contexte de livraison en cours.

Cas d’usage idéal pour les équipes de Test Automation

report skill convient surtout aux ingénieurs Test Automation, aux QA leads, aux développeurs qui utilisent Playwright et aux agents qui travaillent dans des dépôts où les résultats de tests doivent être synthétisés rapidement. Il s’intègre particulièrement bien aux équipes qui utilisent déjà test-results/, playwright-report/, GitHub Actions, des webhooks Slack ou un reporting de type TestRail. Son rôle principal n’est pas de générer des tests, mais d’interpréter les résultats après exécution et de transmettre l’état des tests.

Pourquoi report skill est plus utile qu’un prompt générique

Un prompt générique du type « résume mes tests » passe souvent à côté de points importants : où Playwright stocke les résultats, s’il faut relancer les tests, et où le rapport final doit être envoyé. report skill ajoute des décisions de workflow : inspecter les artefacts existants, exécuter Playwright avec les reporters JSON/HTML/list si les résultats manquent, extraire les nombres de tests réussis/échoués/ignorés/flaky, identifier les tests en échec et leurs messages, puis choisir une destination comme Markdown, un rapport HTML, un artefact CI, Slack ou TestRail lorsque l’environnement le permet.

Points importants avant l’adoption

Le skill amont est léger : le chemin visible dans le dépôt contient uniquement SKILL.md, sans scripts d’assistance, règles, références ni ressources incluses. Cela le rend facile à inspecter et à adapter, mais cela signifie aussi que votre agent doit s’appuyer sur la configuration Playwright locale et sur les variables d’environnement disponibles. Avant de l’installer, vérifiez que votre projet utilise Playwright ou que vous êtes prêt à adapter le workflow à un autre test runner JavaScript.

Comment utiliser report skill

Contexte d’installation de report

Installez le skill depuis le chemin de dépôt utilisé par le répertoire :

npx skills add alirezarezvani/claude-skills --skill report

Après l’installation, commencez par inspecter la source du skill :

engineering-team/playwright-pro/skills/report/SKILL.md

Aucun dossier de support supplémentaire n’apparaît dans l’aperçu publié du skill ; SKILL.md est donc le guide opérationnel principal. Dans votre propre dépôt, vérifiez playwright.config.*, package.json, .github/workflows/, test-results/ et playwright-report/ pour comprendre comment les sorties de tests sont produites et vers où les rapports doivent être acheminés.

Entrées dont le skill a besoin

Pour utiliser report de manière fiable, donnez à l’agent assez de contexte pour éviter les suppositions :

• Si les tests ont déjà été exécutés ou non
• La commande habituellement utilisée pour les tests Playwright
• L’emplacement des artefacts de résultats, s’il n’est pas standard
• Si les retries sont activés, car les tests flaky sont déduits du comportement de retry
• Le format de sortie souhaité : Markdown, commentaire de PR, résumé Slack, envoi vers TestRail ou rapport HTML local
• Les contraintes d’environnement, par exemple « ne pas relancer les tests » ou « CI uniquement »

Prompt faible :

Make a test report.

Prompt plus solide :

Use the report skill for this Playwright project. Do not rerun tests unless no recent results exist. Check test-results/ and playwright-report/, parse JSON output if available, summarize passed/failed/skipped/flaky counts, list failed tests with error messages, and produce a Markdown report for the release channel.

Workflow pratique avec report

Un bon workflow guidé par report consiste à :

1. Vérifier les artefacts existants avec ls -la test-results/ playwright-report/ 2>/dev/null.
2. Si aucun résultat exploitable n’existe et que la relance est autorisée, exécuter :

   npx playwright test --reporter=json,html,list 2>&1 | tee test-output.log
   

3. Analyser la sortie JSON pour récupérer les totaux, la durée, les échecs, les tests ignorés et les retries.
4. Détecter les destinations possibles :
   • TESTRAIL_URL indique qu’une publication TestRail peut être disponible.
   • SLACK_WEBHOOK_URL indique qu’un résumé Slack peut être publié.
   • .github/workflows/ indique qu’un reporting CI/PR peut être pertinent.
   • playwright-report/ indique que le rapport HTML peut être ouvert ou servi.
5. Toujours générer un résumé Markdown, sauf si l’utilisateur demande explicitement une seule destination.

Conseils pour obtenir une meilleure qualité de sortie

Indiquez à l’agent quelle décision le rapport doit aider à prendre. Un release manager a besoin des risques et des blocages ; un développeur a besoin des specs en échec, des stack traces et des commandes de reproduction ; un QA lead peut avoir besoin du nombre de tests flaky et des tendances de durée. Si le rapport doit être collé dans une PR, demandez un résumé compact. S’il sert à une revue d’incident, demandez un regroupement des échecs par suite, navigateur ou motif d’erreur.

FAQ de report skill

report est-il réservé à Playwright ?

Le skill est rédigé autour des commandes, dossiers et reporters Playwright ; il est donc le plus précis pour la Test Automation avec Playwright. Vous pouvez adapter sa structure à Jest, Cypress ou d’autres runners, mais les commandes, les chemins d’artefacts et la détection des tests flaky devront être ajustés. Si votre dépôt ne contient aucun artefact de test et aucune configuration Playwright, un prompt classique peut être tout aussi efficace.

report relance-t-il les tests automatiquement ?

Il peut guider l’agent pour exécuter les tests si aucun résultat récent n’est trouvé, avec npx playwright test --reporter=json,html,list. En revanche, vous devez préciser si les relances sont autorisées. Dans de grosses suites, relancer les tests peut être lent, coûteux ou inadapté après un échec CI, lorsque l’environnement d’origine compte.

Que génère report skill ?

La sortie par défaut est un rapport de tests en Markdown avec le nombre de tests réussis, échoués, ignorés et flaky, la durée totale et le détail des tests en échec. Selon votre environnement, le workflow peut aussi orienter les résultats vers TestRail, Slack, des artefacts GitHub Actions ou des commentaires de PR, ou encore vers le rapport HTML Playwright.

Quand vaut-il mieux ne pas installer report ?

Évitez ou reportez l’installation si votre équipe n’utilise pas Playwright, dispose déjà d’une plateforme de reporting dédiée avec des API strictes, ou a besoin d’analyses historiques au-delà d’une seule exécution de tests. Ce skill est un prompt de workflow concis, pas un service de reporting complet, une base de données, un tableau de bord ni un système de gestion des tests flaky.

Comment améliorer report skill

Améliorer les entrées de report avant de demander un rapport

Le moyen le plus rapide d’améliorer les résultats de report est de fournir des limites d’exécution claires. Incluez la commande de test, les chemins d’artefacts, la destination, l’audience et la politique de relance. Par exemple :

Generate a report for the CI Playwright run. Use existing artifacts only. Look in test-results/ and playwright-report/. Output a PR-ready Markdown summary with top failures, flaky tests, and whether the build should block merge.

Cela évite à l’agent de perdre du temps à relancer les tests ou de produire un niveau de détail inadapté.

Gérer les modes d’échec fréquents

Les problèmes courants incluent l’absence de sortie JSON, des artefacts obsolètes, des logs très volumineux et des retries ambigus. Si le JSON n’est pas disponible, demandez à l’agent de se rabattre sur test-output.log et sur les métadonnées du rapport HTML. Si les artefacts risquent d’être obsolètes, exigez une vérification des horodatages. Si les logs sont trop gros, demandez un regroupement par titre de test en échec et premier message d’erreur significatif, plutôt que de coller des stack traces complètes.

Adapter report au workflow de votre équipe

Comme le skill n’inclut aucun script, les améliorations propres à une équipe passent généralement par l’ajout de conventions locales. Documentez votre modèle de rapport préféré, les règles de publication dans Slack, le mapping de projet TestRail, le format des URL d’artefacts CI et les libellés de sévérité. Référencez ensuite ces conventions dans le prompt afin que report skill produise une sortie alignée sur votre processus de release.

Itérer après le premier rapport

Considérez le premier rapport comme une version de travail. Posez des questions de suivi comme :

• « Group failures by root cause. »
• « Separate product defects from test infrastructure failures. »
• « Add rerun recommendations for flaky tests. »
• « Make this suitable for a non-technical release update. »
• « Include exact commands to reproduce the failed specs. »

Ainsi, le rapport reste centré sur les décisions à prendre, et pas seulement sur les chiffres.