agentic-team-templates 0.8.3 → 0.9.1

package/templates/qa-engineering/.cursorrules/test-strategy.md

@@ -0,0 +1,218 @@
+# Test Strategy
+
+Guidelines for creating and maintaining effective test strategies.
+
+## Strategy Components
+
+### 1. Scope Definition
+
+Clearly define what is and isn't being tested:
+
+```markdown
+## In Scope
+- [Feature/Component]: [Coverage level]
+- [Feature/Component]: [Coverage level]
+
+## Out of Scope
+- [Item]: [Reason]
+- [Item]: [Reason]
+
+## Assumptions
+- [Assumption 1]
+- [Assumption 2]
+
+## Constraints
+- [Constraint 1]
+- [Constraint 2]
+```
+
+### 2. Risk Assessment
+
+Prioritize testing based on risk:
+
+```markdown
+## Risk Register
+
+| Risk Area | Impact | Likelihood | Priority | Testing Approach |
+|-----------|--------|------------|----------|------------------|
+| Payment processing | Critical | Medium | P0 | Extensive automated + manual |
+| User authentication | Critical | Low | P1 | Comprehensive automated |
+| Dashboard reporting | Medium | Medium | P2 | Standard coverage |
+| Admin settings | Low | Low | P3 | Basic smoke tests |
+```
+
+**Risk Factors:**
+
+| Factor | High | Medium | Low |
+|--------|------|--------|-----|
+| Business Impact | Revenue, compliance | User experience | Cosmetic |
+| User Impact | Many users, critical flow | Some users, secondary flow | Few users, edge case |
+| Technical Risk | New tech, complex logic | Moderate complexity | Simple, well-understood |
+| Change Frequency | Frequently modified | Occasional changes | Stable |
+
+### 3. Test Levels
+
+Define approach for each test level:
+
+```markdown
+## Test Level Matrix
+
+| Level | Scope | Automation | Responsibility | When |
+|-------|-------|------------|----------------|------|
+| Unit | Functions, classes | 100% | Developers | Every commit |
+| Integration | APIs, services | 90%+ | Dev + QA | Every PR |
+| E2E | User workflows | 70%+ | QA | Daily + release |
+| Performance | Load, stress | 100% | QA + DevOps | Weekly + release |
+| Security | Vulnerabilities | 100% | Security + QA | Daily + release |
+| Exploratory | Risk areas | 0% | QA | Per feature |
+```
+
+### 4. Environment Strategy
+
+```markdown
+## Environment Matrix
+
+| Environment | Purpose | Data | Refresh | Access |
+|-------------|---------|------|---------|--------|
+| Local | Development | Mocked | On demand | Developers |
+| Dev | Integration | Synthetic | Daily | Team |
+| Staging | Pre-prod | Sanitized prod | Weekly | Team + stakeholders |
+| Production | Smoke only | Live | N/A | Restricted |
+
+## Environment Parity Checklist
+- [ ] Same OS/runtime versions
+- [ ] Same database schema
+- [ ] Same third-party service configs
+- [ ] Same feature flags
+- [ ] Same infrastructure topology
+```
+
+### 5. Entry/Exit Criteria
+
+```markdown
+## Entry Criteria (Ready for Testing)
+
+- [ ] Code complete and merged to test branch
+- [ ] Unit tests passing (80%+ coverage)
+- [ ] Code review approved
+- [ ] Build deployed to test environment
+- [ ] Test data available
+- [ ] Requirements/stories linked
+
+## Exit Criteria (Ready for Release)
+
+### Must Have
+- [ ] All P0 test cases executed and passed
+- [ ] All P1 test cases executed and passed
+- [ ] No open P0 defects
+- [ ] No open P1 defects (or approved exceptions)
+- [ ] Regression suite > 95% pass rate
+- [ ] Security scan: 0 critical, 0 high vulnerabilities
+- [ ] Performance thresholds met
+
+### Should Have
+- [ ] P2 defects < 5 open
+- [ ] All new features have automation
+- [ ] Documentation updated
+
+### Approval
+- [ ] QA Lead sign-off
+- [ ] Dev Lead sign-off
+- [ ] Product Owner sign-off
+```
+
+## Test Type Definitions
+
+### Smoke Tests
+
+**Purpose:** Verify basic functionality works after deployment
+
+**Characteristics:**
+- Fast (< 5 minutes)
+- Critical path only
+- Run on every deployment
+- Block release if failing
+
+**Example Coverage:**
+- Application loads
+- User can log in
+- Core feature accessible
+- Database connectivity
+
+### Regression Tests
+
+**Purpose:** Ensure existing functionality still works after changes
+
+**Characteristics:**
+- Comprehensive coverage
+- Run before every release
+- Automated where possible
+- Prioritized by risk
+
+**Maintenance:**
+- Review quarterly
+- Remove obsolete tests
+- Update for product changes
+- Fix flaky tests immediately
+
+### Integration Tests
+
+**Purpose:** Verify components work together correctly
+
+**Characteristics:**
+- Test API contracts
+- Test database interactions
+- Test service communication
+- Mock external dependencies
+
+### End-to-End Tests
+
+**Purpose:** Validate complete user workflows
+
+**Characteristics:**
+- Test realistic scenarios
+- Include multiple systems
+- Slower and more fragile
+- Limited to critical paths
+
+### Performance Tests
+
+**Purpose:** Validate system meets performance requirements
+
+**Types:**
+| Type | Purpose | When |
+|------|---------|------|
+| Load | Normal expected load | Every release |
+| Stress | Beyond normal capacity | Quarterly |
+| Spike | Sudden load increase | Before events |
+| Soak | Extended duration | Monthly |
+
+### Security Tests
+
+**Purpose:** Identify vulnerabilities before attackers do
+
+**Types:**
+- Static Analysis (SAST): Code scanning
+- Dynamic Analysis (DAST): Runtime scanning
+- Dependency Scanning: Third-party vulnerabilities
+- Penetration Testing: Manual security assessment
+
+## Strategy Maintenance
+
+### Review Cadence
+
+| Review | Frequency | Focus |
+|--------|-----------|-------|
+| Daily | Every day | Execution status, blockers |
+| Sprint | Every sprint | Coverage, defect trends |
+| Release | Every release | Quality gate, metrics |
+| Quarterly | Every quarter | Strategy effectiveness |
+
+### Strategy Updates
+
+Trigger strategy review when:
+- Major product changes
+- New technology adoption
+- Significant defect trends
+- Team structure changes
+- Customer feedback patterns