---
name: test-plan-template
description: Template for integration test planning
user-invocable: false
---

# Test Plan: [Project/Feature Name]

## Your Task

Use this test plan template to define the testing strategy for your project or feature. Fill in each section with your test levels, environments, schedules, and acceptance criteria.

**Version**: 1.0
**Date**: YYYY-MM-DD
**Author(s)**: [Your Name]
**Reviewers**: [Reviewer Names]

---

## 1. Introduction

### 1.1 Purpose
Brief description of what this test plan covers.

### 1.2 Scope

**In Scope:**
- Feature/module being tested
- Test types to be performed (unit, integration, E2E)
- Platforms and environments

**Out of Scope:**
- What will NOT be tested
- Known limitations

### 1.3 Objectives
- Objective 1: Ensure core functionality works correctly
- Objective 2: Validate performance requirements are met
- Objective 3: Verify security controls are effective

---

## 2. Test Strategy

### 2.1 Test Levels

#### Static Analysis
- **Tools**: ESLint, TypeScript, Prettier
- **Coverage**: 100% of codebase
- **Execution**: Pre-commit hooks + CI pipeline

#### Unit Tests
- **Tools**: Jest/Vitest
- **Coverage Target**: 90% for business logic
- **Focus**: Pure functions, utility methods, business rules
- **Execution**: Every commit, < 30 seconds

#### Integration Tests
- **Tools**: Supertest, Testing Library
- **Coverage Target**: 80% of API endpoints and component interactions
- **Focus**: API contracts, database operations, service integrations
- **Execution**: Every commit, < 2 minutes

#### End-to-End Tests
- **Tools**: Playwright
- **Coverage Target**: 10 critical user journeys
- **Focus**: Business-critical workflows
- **Execution**: Every PR, < 10 minutes

#### Performance Tests
- **Tools**: k6
- **Coverage Target**: All performance-critical endpoints
- **Benchmarks**:
  - API response time: p95 < 500ms
  - Throughput: 1000 req/s sustained
- **Execution**: On main branch, before release

### 2.2 Risk-Based Testing

| Risk Level | Coverage | Examples |
|------------|----------|----------|
| **Critical** | 100% | Payment processing, authentication, data deletion |
| **High** | 90% | User registration, order creation, inventory updates |
| **Medium** | 80% | Profile updates, search functionality, notifications |
| **Low** | 60% | UI styling, static content, non-critical features |

### 2.3 Entry and Exit Criteria

**Entry Criteria:**
- [ ] Code review completed and approved
- [ ] Feature branch merged to develop
- [ ] Test environment available and stable
- [ ] Test data prepared

**Exit Criteria:**
- [ ] All planned tests executed
- [ ] Code coverage targets met
- [ ] No critical or high-priority bugs open
- [ ] Performance benchmarks passed
- [ ] Test report generated and reviewed

---

## 3. Test Environment

### 3.1 Environments

| Environment | Purpose | URL | Database |
|-------------|---------|-----|----------|
| **Local** | Development testing | localhost:3000 | SQLite |
| **CI** | Automated testing | N/A | PostgreSQL (Docker) |
| **Staging** | Pre-production validation | staging.example.com | PostgreSQL (AWS RDS) |
| **Production** | Smoke tests only | example.com | PostgreSQL (AWS RDS) |

### 3.2 Test Data

**Strategy**: Use test data factories and fixtures

**Sources:**
- `tests/fixtures/` - Static test data (JSON/YAML)
- `tests/factories/` - Programmatic data generation
- Seeder scripts for test database population

**Data Privacy:**
- No production data used in tests
- Anonymized data for realistic scenarios
- Faker library for generating realistic test data

---

## 4. Test Cases

### 4.1 Critical User Journeys (E2E Tests)

| ID | Journey | Priority | Status |
|----|---------|----------|--------|
| E2E-001 | User signup and email verification | Critical | Pending |
| E2E-002 | User login and session management | Critical | Pending |
| E2E-003 | Add item to cart and checkout | Critical | Pending |
| E2E-004 | Payment processing (success scenario) | Critical | Pending |
| E2E-005 | Payment processing (failure handling) | Critical | Pending |
| E2E-006 | Order history and status tracking | High | Pending |
| E2E-007 | User profile update | Medium | Pending |
| E2E-008 | Password reset flow | High | Pending |

### 4.2 API Integration Tests

| Endpoint | Method | Test Cases | Priority |
|----------|--------|------------|----------|
| `/api/users` | POST | Create user, validation errors, duplicate email | Critical |
| `/api/users/:id` | GET | Retrieve user, not found, unauthorized | High |
| `/api/users/:id` | PUT | Update user, validation, permissions | High |
| `/api/users/:id` | DELETE | Delete user, cascade effects, permissions | Critical |
| `/api/orders` | POST | Create order, inventory check, payment integration | Critical |
| `/api/orders/:id` | GET | Retrieve order, not found, permissions | Medium |

### 4.3 Unit Tests

**Focus Areas:**
- Business logic in `/src/services/`
- Utility functions in `/src/utils/`
- Data validation and transformation
- Error handling

**Coverage Target**: 90% line coverage, 85% branch coverage

---

## 5. Test Schedule

| Phase | Activities | Duration | Dates |
|-------|-----------|----------|-------|
| **Planning** | Write test plan, define strategy | 2 days | Nov 1-2 |
| **Setup** | Configure tools, create fixtures | 3 days | Nov 3-5 |
| **Unit Tests** | Implement unit tests | 5 days | Nov 6-10 |
| **Integration Tests** | Implement integration tests | 5 days | Nov 11-15 |
| **E2E Tests** | Implement E2E tests | 3 days | Nov 16-18 |
| **Performance Tests** | Implement load tests | 2 days | Nov 19-20 |
| **Execution** | Run full test suite, fix bugs | 3 days | Nov 21-23 |
| **Reporting** | Generate reports, document findings | 1 day | Nov 24 |

**Total Estimated Effort**: 24 days (across sprint cycles)

---

## 6. Defect Management

### 6.1 Bug Severity Levels

| Severity | Description | Response Time | Example |
|----------|-------------|---------------|---------|
| **Critical** | Blocks release, data loss, security | Immediate | Payment processing fails |
| **High** | Major feature broken, workaround exists | 24 hours | Login intermittently fails |
| **Medium** | Minor feature issue, usability problem | 3 days | Form validation message unclear |
| **Low** | Cosmetic, typo, minor UI issue | 1 week | Button alignment off by 2px |

### 6.2 Bug Lifecycle

1. **New** → Bug reported with reproduction steps
2. **Confirmed** → Developer verifies and reproduces
3. **In Progress** → Developer working on fix
4. **Fixed** → Fix implemented, awaiting test verification
5. **Verified** → Tester confirms fix works
6. **Closed** → Bug resolved and documented

### 6.3 Tracking

**Tool**: GitHub Issues / Jira
**Labels**: `bug`, `critical`, `high`, `medium`, `low`, `test-failure`
**Required Info**: Reproduction steps, expected vs actual behavior, environment, logs

---

## 7. Test Deliverables

- [ ] Test plan document (this document)
- [ ] Test case specifications (see `/scripts/test-case-template.md`)
- [ ] Test scripts (automated tests in `/tests/`)
- [ ] Coverage reports (generated by Jest/Vitest)
- [ ] Performance test results (k6 reports)
- [ ] Bug reports (GitHub Issues)
- [ ] Final test summary report

---

## 8. Roles and Responsibilities

| Role | Name | Responsibilities |
|------|------|------------------|
| **Test Lead** | [Name] | Test strategy, planning, reporting |
| **Backend Tester** | [Name] | API integration tests, unit tests for services |
| **Frontend Tester** | [Name] | Component tests, E2E tests, UI validation |
| **Performance Engineer** | [Name] | Load tests, performance benchmarks, optimization |
| **Developer** | [Name] | Unit tests for new code, bug fixes |

---

## 9. Risks and Mitigation

| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| Test environment instability | High | Medium | Use Docker for consistent environments |
| Insufficient test data | Medium | High | Develop comprehensive fixtures and factories |
| Flaky E2E tests | High | High | Use explicit waits, retry logic, isolated test data |
| Performance test infrastructure cost | Low | Low | Run perf tests only on main branch |
| Team lacks testing expertise | High | Medium | Training sessions, pair testing, code review |

---

## 10. Test Metrics

### 10.1 Coverage Metrics

- **Line Coverage**: Target 80%+
- **Branch Coverage**: Target 75%+
- **Function Coverage**: Target 85%+

### 10.2 Quality Metrics

- **Pass Rate**: Target 98%+
- **Bug Density**: < 5 bugs per 1000 lines of code
- **Test Execution Time**: Full suite < 15 minutes

### 10.3 Velocity Metrics

- **Test Cases Written**: Track per week
- **Test Automation Rate**: Target 90% of regression tests automated
- **Bug Fix Time**: Average time from report to verified fix

---

## 11. Approvals

| Role | Name | Signature | Date |
|------|------|-----------|------|
| **QA Lead** | [Name] | | |
| **Engineering Manager** | [Name] | | |
| **Product Manager** | [Name] | | |

---

**Version History:**
- v1.0 (YYYY-MM-DD): Initial test plan created
