使用方法
- 复制安装命令，在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物，并对照来源检查输出。
npx skills add https://github.com/testdino-hq/playwright-skill --skill playwright-qa开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况，不等于独立质量或安全测试。
仓库原始内容
按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
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=20gives 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.
