Test plan
A written agreement on what QA will cover, the biggest risks, where tests run, and what must be true before release.
What it is
A test plan records what will be tested, what will not, the risks that set the priorities, the environments and data required, and the evidence needed to call testing complete. It turns 'QA this feature' into a shared agreement rather than a last-minute tour through whatever screens come to mind. IEEE 829 wrote down the heavyweight version of this document; most teams now keep a one-page descendant of it.
Reach for one before a risky release, migration, payment change, or cross-team feature. Start from user and business risks, then map each risk to automated checks, exploratory sessions, compatibility coverage, and an owner. Concrete exit criteria might require all critical cases green, no open severity-one defects, and sign-off on named browsers.
Gotcha: a test plan is not a catalog of every possible test. If it does not rank risks or name an exit condition, it cannot guide a tradeoff when the deadline moves. Keep it short, update it when scope changes, and link results back to the plan so completion is evidence rather than a checkbox.
Ask AI for it
Write a test plan for <feature> from these acceptance criteria. Include in-scope and out-of-scope behavior, a likelihood-by-impact risk table, test data and environment needs, owners, entry criteria, and measurable exit criteria. Map each high risk to a unit, integration, Playwright, or exploratory check; define Playwright projects for Chromium, Firefox, and WebKit where browser coverage matters; and specify the GitHub Actions evidence attached to the release.