playwright-qa

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Chinese

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.

面向 QA 工程师：围绕测试代码开展工作，包括测什么、如何报告故障、如何将手动测试套件自动化，以及如何判断测试。

4 篇指南。这些指南以

core/

中关于 Playwright APIs 的指南为基础，并通过链接引用，而不重复其内容。

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

你正在做什么	指南
工单 / PRD / 验收标准 → 测试用例、风险排序、供生成器使用的测试计划	test-design.md
失败的测试 → 应用缺陷、测试缺陷或 flaky test；缺陷报告；等待修复期间如何处理该测试	bug-reports.md
手动测试用例或 CSV 导出 → 带用例 ID 的 Playwright specs	manual-to-automated.md
审查 Playwright 测试或 PR；lint rules；证明测试能够失败	test-review.md

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.