playwright-qa

Original：🇺🇸 English

Translated

QA engineering workflows on top of Playwright. Use when a QA engineer asks to design test cases from a ticket, PRD or acceptance criteria, decide what to automate, write a bug report from a failing test or trace, convert manual test cases (TestRail, Xray, CSV) into Playwright specs with case-ID traceability, or review Playwright test code and pull requests.

15installs

Sourcetestdino-hq/playwright-skill

Added on2026-10-23

NPX Install

npx skill4agent add testdino-hq/playwright-skill playwright-qa

SKILL.md Content

View Translation Comparison →

Playwright QA Workflows

For QA engineers: the work around the test code. What to test, how to report what broke, how to automate a manual suite, and how to judge a test.

4 guides. They build on the

core/

guides for the Playwright APIs and link to them rather than repeating them.

Guide Index

What you're doing	Guide
Ticket / PRD / acceptance criteria → test cases, risk ranking, test plan for the generator	test-design.md
Failing test → app bug, test bug or flake; bug report; what to do with the test meanwhile	bug-reports.md
Manual test cases or a CSV export → Playwright specs with case IDs	manual-to-automated.md
Review Playwright tests or a PR; lint rules; prove a test can fail	test-review.md

Golden Rules

Boundaries and negative paths first: bugs live at the edges of a rule, not in the happy path.
Lowest layer that proves it: rules at API level, wiring and critical flows in E2E.
Classify before filing: app bug, test bug, flake or environment; the trace usually decides.
Frequency is a number:
```
--repeat-each=20
```
gives N/20, never "sometimes".
Known bug →
test.fail()
with an issue link, never a deleted test or a loosened assertion.
A test that can't fail guards nothing: break the feature once and watch it fail.
Keep case IDs on automated tests so results map back to the manual suite.