What this prompt does
This prompt produces a written test strategy document for a feature before you build it. You give it [feature_name], the [tech_stack], and a [feature_description], and the AI returns a structured plan: a test-pyramid breakdown (how many unit, integration, and E2E tests), a prioritised risk analysis, test data and environment needs, a performance plan targeting [load_target], a WCAG [wcag_level] accessibility checklist, regression impact, an automation-versus-manual split, acceptance criteria mapped to test cases, and a timeline.
The structure works because it forces alignment up front. Instead of discovering scope gaps once the feature is half-built, the prompt makes you decide what gets tested and why, with justification for each split. The variables anchor the abstract advice — [load_target] and [wcag_level] scale the performance and accessibility sections to the product's real requirements, and the [feature_description] keeps risk analysis specific to what this feature can actually break.
When to use it
- You are about to build a high-stakes feature like billing and want consensus on test scope first.
- You need a test-pyramid breakdown to plan effort across unit, integration, and E2E layers.
- You want a documented risk analysis prioritising what can go wrong.
- You need an accessibility checklist tied to a specific WCAG
[wcag_level]. - You want acceptance criteria explicitly mapped to test cases.
- You are estimating testing timeline and execution order for a sprint plan.
Example output
You get a multi-section Markdown document: a test pyramid with counts per layer, a ranked risk table, test data and environment requirements, a performance section with baseline metrics and the [load_target], a WCAG [wcag_level] checklist, a regression impact list, an automation/manual split with reasoning, an acceptance-criteria-to-test mapping, and a timeline with execution order.
Pro tips
- Write a detailed
[feature_description]— the risk analysis is only as sharp as the behaviour you describe. - Set
[load_target]to a realistic concurrency number; an inflated figure produces a performance plan you will never execute. - Match
[wcag_level]to your actual compliance obligation rather than defaulting to the strictest level. - Use the test-pyramid counts as a starting ratio, not a contract — adjust once you see the real code.
- Keep the document living: revisit the risk table after the feature is built and tests are written.
- Pair this with an actual test-generation prompt so the strategy turns into concrete test code.
