beginner

Generate a Full QA Test Plan Document

Produce a professional test plan covering scope, strategy, environments, entry/exit criteria, schedule, risk register, defect management, and metrics — ready to share with stakeholders.

Who this is for

QA leads, test managers, and senior QA engineers who need to produce a structured test plan for a new feature, release, or project — especially under time pressure. Also useful for SDETs who want to document their test strategy for stakeholders.

Prompt Template

You are a QA lead writing a formal test plan for {{projectName}} version {{version}}.

Sprint/release duration: {{sprintDuration}}
In-scope features: {{inScopeFeatures}}
Out of scope: {{outOfScope}}
Environments available: {{environments}}

Generate a complete Markdown test plan:

---

## Executive Summary
One paragraph: what is being tested, why, key risks, and expected outcomes.

## 1. Scope
- In-scope features with traceability to requirements/tickets
- Explicitly out-of-scope items with justification
- Assumptions and dependencies (e.g. "assumes staging has production parity data")

## 2. Test Strategy
- **Test levels**: unit / integration / E2E / exploratory — percentage split with justification
- **Test types**: functional, regression, smoke, performance, security, accessibility
- **Automation strategy**: decision matrix of what to automate vs keep manual
- **Tools**: list per test type with versions

## 3. Test Environment
- Environment list with purpose (dev / staging / UAT / prod-like)
- Test data: seeding strategy, PII handling, data reset approach
- Third-party services: mocked vs live, with risk note

## 4. Entry and Exit Criteria
| Criteria | Entry | Exit |
|---|---|---|
| Code | Feature branch merged to main | All P1/P2 tests passed |
| Environment | Staging deployed with correct build | No open Critical/High defects |
| Data | Test data seeded | Metrics targets hit |

## 5. Test Schedule
Timeline across {{sprintDuration}} with milestones: test case authoring, execution, bug fixing, regression, sign-off.

## 6. Risk and Mitigation
Top 5 risks with probability, impact, and mitigation plan.

## 7. Defect Management
- Severity/priority matrix with definitions
- Defect lifecycle: New → Assigned → In Progress → Fixed → Retest → Closed
- Escalation path for Critical defects
- Target resolution SLAs per severity

## 8. Metrics and Reporting
- KPIs: pass rate target, test coverage %, escaped defect rate
- Reporting cadence and stakeholder distribution

How to use this prompt

1Copy the prompt and fill in the context: project name, feature being tested, tech stack, team size, timeline, and any known risks.
2Paste into your AI assistant and specify any regulatory, performance, or accessibility requirements.
3Review the generated test plan sections: scope, out of scope, test approach, entry/exit criteria, risks, environments, and schedule.
4Tailor the plan to your team's process — remove sections that don't apply and add your specific test management tool references.
5Share the plan with your team and stakeholders for sign-off.

Example output

For a new payments feature with Stripe integration, the prompt generates a test plan covering: scope (checkout, refund, subscription flows), out of scope (fraud detection, Stripe-side processing), test approach (manual + Playwright E2E + Postman API), entry criteria (staging environment with Stripe test mode), exit criteria (zero P1/P2 defects, >95% coverage of acceptance criteria), risks (Stripe webhook reliability, cross-browser date/currency formatting), and a 5-day execution schedule.

Limitations

The generated plan is a starting template — review it with your QA team and development lead to ensure it reflects your actual delivery process.
The prompt does not have access to your project backlog or Jira — reference specific ticket numbers and acceptance criteria manually.
Risk assessments are generic by default — supplement with domain-specific risks you know from your project context.

Requirement-to-Scenario Mapper

istqb foundation essentials

Frequently asked questions

How long should a test plan be?v

For a standard feature, 1–3 pages covering scope, approach, risks, and criteria is usually sufficient. Avoid over-engineering — a plan that gets read and followed is more valuable than a comprehensive document that gets ignored.

Can I use this for an ISTQB-style test plan?v

Yes — specify 'ISTQB test plan structure' in your input and the prompt adapts the output to the ISTQB template with sections aligned to the standard.

Should the test plan include automation strategy?v

Yes — include your automation framework, which scenarios will be automated vs manual, and your CI/CD integration approach. The prompt will include an automation section if you mention your framework in the input.