test-plan
Playwright Test Plan
The strategy document that sits above the rest of the toolkit: not what to test (that's scenario-mapper) or how a single run went (that's report-generator), but when each kind of check should run, what has to be true before something ships, and how test data/environments are handled consistently instead of improvised per-run.
Core principles (and why)
Ground it in the actual site — don't write a generic template. A test plan that could apply to any website ("browser compatibility matters," "test your forms") isn't useful to anyone. Base scope and risk-based priorities on what scenario-mapper actually found about this site, and reuse its P0/P1/P2 scheme directly rather than inventing a new one — a second priority scale just adds a translation step nobody asked for.
If nothing's been discovered yet, discover first. Risk-based prioritization is only as good as what's actually known about the site's structure. If no scenario-mapper output exists, either run it before writing the plan, or write the plan but mark it explicitly as provisional until that's done — don't present confident-sounding priorities that are actually guesswork.
Cadence should match cost, not habit. The other skills in this toolkit already have real cost differences worth reusing here: a full cross-browser grid is expensive, a viewport-only check is cheap; comprehensive scenario discovery is a bigger lift than sanity; codifying a flow into a permanent test is worth doing once it's stable, not every run. Don't default everything to "run before every deploy" because that sounds thorough — that's the same "comprehensive isn't infinite" instinct from scenario-mapper, applied to scheduling instead of scenario count.
Exit criteria have to be specific enough to actually gate a decision. "The site should work well" isn't a criterion. "No failing P0 flow-runner scenario, no critical/serious accessibility finding, no unresolved critical bug-triage finding" is — someone can check it and get a yes/no answer. If a criterion can't be checked against something concrete, rewrite it until it can.
This is a living document — revise it, don't regenerate it from scratch. If a test plan already exists, update it in place: note what changed (a new risk area discovered, a cadence that turned out wrong, tightened or loosened criteria) in a changelog, rather than producing a disconnected fresh copy that loses the history of why things are set up the way they are.
The coverage ledger should be honest, not flattering. Which scenarios have a permanent e2e-codegen test versus which are still conversational/manual-only is real information the plan should track plainly. "Manual-only" isn't a failure to hide — it's just where automation hasn't been invested yet, and hiding it defeats the point of tracking coverage at all.