Jak używać
- Skopiuj polecenie instalacji i sprawdź źródła przed instalacją we własnym środowisku agenta.
- W oryginale sprawdź wymagane narzędzia, dane dostępowe i obsługiwane środowiska.
- Opisz dane wejściowe i oczekiwany rezultat; porównaj wynik ze źródłami.
npx skills add https://github.com/testdino-hq/playwright-skill --skill playwright-qaPrzed rozpoczęciem
- Instalacja nie obejmuje subskrypcji modelu, limitu API ani uprawnień do plików.
- Gwiazdki i instalacje pokazują aktywność, a nie niezależny test jakości lub bezpieczeństwa.
Oryginalny dokument Skill
Treść z repozytorium z zachowaniem nagłówków, przykładów, kodu, tabel, linków i obrazów.
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.
