# Test Plan

# Test Plan

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Test Objectives

<!-- GUIDANCE: State what this specific test plan aims to verify. These should map to acceptance criteria from the requirements doc. -->

This test plan covers testing for **{{RELEASE_NAME}}** ({{VERSION}}) of {{PROJECT_NAME}}.

**Primary objectives:**
1. Verify that {{OBJECTIVE_1}} <!-- e.g., "the new checkout flow handles all payment methods correctly" -->
2. Verify that {{OBJECTIVE_2}}
3. Confirm no regression in {{REGRESSION_AREA}}
4. Validate performance under expected production load

**Out of scope for this plan:** See Section 3 (Scope).

---

## 2. Features Under Test

<!-- GUIDANCE: List all features/user stories that must be tested in this release. -->

| Feature / Story | Priority | Test Types | Owner |
|-----------------|----------|------------|-------|
| {{FEATURE_1}} | Critical | Unit, Integration, E2E | {{OWNER}} |
| {{FEATURE_2}} | High | Unit, Integration | {{OWNER}} |
| {{FEATURE_3}} | Medium | Unit | {{OWNER}} |
| Regression — {{AREA}} | High | E2E, Manual | {{OWNER}} |

<!-- TODO: Complete feature list from sprint board / release notes -->

---

## 3. Scope

### In Scope

<!-- GUIDANCE: Be specific. "Feature X including edge cases Y and Z." -->

- {{IN_SCOPE_1}}
- {{IN_SCOPE_2}}
- Regression testing of {{REGRESSION_MODULES}}
- Performance testing of {{PERF_SCOPE}} endpoints
- Security testing of new authentication changes

### Out of Scope

<!-- GUIDANCE: Explicitly stating out-of-scope prevents scope creep and misalignment. Always include justification. -->

| Item | Justification |
|------|---------------|
| {{OUT_1}} | {{REASON_1}} <!-- e.g., "No changes in this release" --> |
| {{OUT_2}} | {{REASON_2}} <!-- e.g., "Covered by separate security audit" --> |
| Third-party integrations ({{SERVICE}}) | Tested in integration test suite; provider responsible for own reliability |

---

## 4. Test Schedule & Milestones

<!-- GUIDANCE: Align test schedule with sprint/release milestones. Buffer for bug fixing. -->

| Milestone | Date | Responsible |
|-----------|------|-------------|
| Test plan approved | {{DATE}} | QA Lead |
| Test environment ready | {{DATE}} | Platform team |
| Test data seeded | {{DATE}} | QA team |
| Unit + integration tests complete | {{DATE}} | Dev team |
| E2E test authoring complete | {{DATE}} | QA team |
| Regression testing complete | {{DATE}} | QA team |
| UAT start | {{DATE}} | QA + Product |
| UAT sign-off | {{DATE}} | Product Owner |
| Performance testing complete | {{DATE}} | DevOps + QA |
| Go/no-go decision | {{DATE}} | Eng manager |
| Production release | {{DATE}} | Release manager |

---

## 5. Resource Allocation

<!-- GUIDANCE: Who is responsible for what testing activity? -->

| Resource | Role | Testing Activities | Availability |
|----------|------|-------------------|-------------|
| {{PERSON_1}} | QA Lead | E2E authoring, regression | 100% |
| {{PERSON_2}} | Developer | Unit + integration tests | 30% of sprint |
| {{PERSON_3}} | Developer | Unit + integration tests | 30% of sprint |
| {{PERSON_4}} | DevOps | Performance, infrastructure | 20% |
| {{PERSON_5}} | Product Owner | UAT review and sign-off | As needed |

---

## 6. Entry Criteria

<!-- GUIDANCE: Testing should not start until these conditions are met. Prevents wasted testing effort on unstable builds. -->

Testing may begin when:
- [ ] Feature development is code-complete (all tickets in "Ready for QA")
- [ ] Unit tests passing (≥ {{UNIT_PASS_RATE}}% pass rate)
- [ ] Integration tests passing
- [ ] Build artifact deployed to test environment
- [ ] Test environment is stable (health checks passing)
- [ ] Test data is seeded and verified
- [ ] Test cases for new features reviewed and approved
- [ ] Previous known blocking bugs resolved (see bug tracker)

---

## 7. Exit Criteria

<!-- GUIDANCE: Define "done" for testing. These conditions must be met before releasing. -->

Testing is complete when:
- [ ] All test cases executed
- [ ] ≥ {{PASS_RATE}}% of test cases pass
- [ ] All Critical and High defects resolved or accepted with justification
- [ ] Medium defects reviewed — plan in place for outstanding items
- [ ] Code coverage ≥ {{COVERAGE_GATE}}%
- [ ] E2E tests passing on staging
- [ ] Performance tests meeting SLA targets
- [ ] UAT sign-off obtained from Product Owner
- [ ] Go/no-go checklist complete (see Section 14)
- [ ] Release notes updated with test summary

**Exceptional circumstances:** If exit criteria cannot be met, a documented risk acceptance from {{ACCEPTANCE_AUTHORITY}} is required.

---

## 8. Test Strategy Summary Per Type

<!-- GUIDANCE: Brief summary for each test type being executed. Reference test strategy doc for full detail. -->

| Type | Approach | Tool | Owner | Gate |
|------|----------|------|-------|------|
| Unit | White-box, TDD where applicable | {{UNIT_TOOL}} | Developers | Blocks merge |
| Integration | Real dependencies via TestContainers | {{INT_TOOL}} | Developers | Blocks merge |
| E2E | Critical user journeys, automated | {{E2E_TOOL}} | QA | Blocks release |
| Regression | Automated suite + targeted manual | {{E2E_TOOL}} + manual | QA | Blocks release |
| Performance | Load test at {{LOAD_PROFILE}} | {{PERF_TOOL}} | DevOps | Blocks release |
| Security | SAST + SCA + manual review | {{SAST_TOOL}} | DevOps | Blocks merge |
| UAT | Business scenario validation | Manual | Product Owner | Blocks release |
| Accessibility | Automated + manual audit | {{A11Y_TOOL}} | Developer + QA | Warning |

---

## 9. Test Environment Requirements

<!-- GUIDANCE: Specify what is needed for testing. Platform team should provision before testing starts. -->

| Environment | Purpose | URL | Access Needed |
|-------------|---------|-----|---------------|
| Dev | Unit/integration | `dev.{{DOMAIN}}` | All team members |
| Staging | E2E, regression, UAT | `staging.{{DOMAIN}}` | Team + PM + stakeholders |
| Performance | Load testing | Isolated (production-sized) | DevOps + QA |

**Environment requirements:**
- Staging must have production-equivalent configuration
- Test database seeded with {{DATA_VOLUME}} records
- Third-party integrations in sandbox/test mode
- Monitoring enabled (same as production)

---

## 10. Test Data Requirements

<!-- GUIDANCE: What data must exist before testing can begin? -->

| Data Category | Volume | Creation Method | Responsible |
|---------------|--------|----------------|-------------|
| Test user accounts | {{USER_COUNT}} | `scripts/seed-users.sh` | QA team |
| {{DATA_TYPE_1}} | {{VOLUME}} | Factory / fixtures | QA team |
| {{DATA_TYPE_2}} | {{VOLUME}} | Anonymized from production | DevOps |
| Edge case data (empty states, max values) | Defined per test | Manual / fixtures | QA team |

**Data cleanup:** All test data removed after test run via `scripts/cleanup.sh`

---

## 11. Risk-Based Test Prioritization

<!-- GUIDANCE: Focus testing effort on high-impact / high-probability risk areas. -->

| Risk Area | Likelihood | Impact | Priority | Mitigation |
|-----------|------------|--------|----------|------------|
| Payment processing failure | Medium | Critical | P1 | Full regression + manual testing |
| Data migration errors | High | Critical | P1 | Staged migration + rollback plan |
| Performance degradation | Medium | High | P2 | Load test at 2x expected peak |
| Third-party API downtime | Low | Medium | P3 | Stub in tests, circuit breaker in code |
| Authentication edge cases | Low | Critical | P1 | Full auth test suite |

---

## 12. Dependencies & Assumptions

<!-- GUIDANCE: Document what must be true for testing to proceed as planned. -->

**Dependencies:**
- Platform team provisions staging environment by {{DATE}}
- {{THIRD_PARTY}} sandbox environment available
- Security team approves SAST configuration by {{DATE}}

**Assumptions:**
- Feature requirements will not change during the testing phase
- All developers will respond to bugs within {{BUG_RESPONSE_SLA}} hours
- UAT participants are available per the schedule in Section 4

---

## 13. Defect Management Process

<!-- GUIDANCE: How are bugs tracked, prioritized, and resolved? -->

**Bug tracker:** {{BUG_TRACKER}} <!-- Jira / Linear / GitHub Issues -->
**Severity levels:**

| Severity | Definition | Resolution SLA |
|----------|------------|----------------|
| Critical | System unusable, data loss, security issue | Fix before release |
| High | Major feature broken, no workaround | Fix before release |
| Medium | Feature degraded, workaround exists | Fix in next sprint |
| Low | Minor issue, cosmetic | Backlog |

**Bug lifecycle:** Open → Assigned → In Progress → Fixed → Verified → Closed
**Triage cadence:** Daily during active testing phase

---

## 14. Test Deliverables

<!-- GUIDANCE: List everything that will be produced by the testing effort. -->

| Deliverable | Format | Due Date | Owner |
|-------------|--------|----------|-------|
| Test plan (this document) | Markdown | {{DATE}} | QA Lead |
| Test cases | {{BUG_TRACKER}} / Markdown | {{DATE}} | QA team |
| Test execution results | Automated CI reports + summary | {{DATE}} | QA team |
| Defect report | {{BUG_TRACKER}} | Ongoing | QA team |
| Performance test report | Markdown + charts | {{DATE}} | DevOps |
| UAT sign-off | Signed [uat-signoff.md](../RELEASE/uat-signoff.md) | {{DATE}} | Product Owner |
| Test summary report | Markdown | {{DATE}} | QA Lead |

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Test Case Template](./test-case-template.md)
- [E2E Test Plan](./e2e-test-plan.md)
- [Performance Test Plan](./performance-test-plan.md)
- [Definition of Done](./definition-of-done.md)
- [UAT Sign-off](../RELEASE/uat-signoff.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Approver | | | |