test-strategy-en（测试策略 zh）

Test Strategy

中文版： 见技能 test-strategy。

Prompts: see prompts/test-strategy_EN.md in this directory.

When to Use

• User mentions test strategy, test plan, quality strategy, or test planning
• Need to develop test strategy or plan for a project
• Trigger: e.g. "Develop test strategy for this project" or "Write test plan document"

Output Format Options

This skill defaults to Markdown output (consistent with Standard-version template). For other formats, specify at the end of your request:

See output-formats.md for detailed specifications and examples.

How to Use

1. Open the relevant file in this directory's prompts/ and copy the content below the dashed line.
2. Append your requirements and context (business flow, environment, constraints, acceptance criteria).
3. If you need non-Markdown output, append the request sentence from output-formats.md at the end.

Reference Files

• prompts/test-strategy_EN.md — Test strategy Standard-version prompts
• output-formats.md — Markdown / Excel / PDF / JSON request instructions

Code Examples

This skill provides the following real code examples:

1. Test Strategy Template Collection - Complete test strategy templates

- Agile project test strategy - Waterfall project test strategy - Mobile app test strategy - API test strategy - Microservices test strategy - Risk assessment matrix - Resource planning templates

1. Strategy Generation Tools (coming soon)
2. Risk Assessment Tools (coming soon)

See Reference templates for practical templates.

Common Pitfalls

• ❌ Strategy too generic → ✅ Develop specific strategy for project characteristics
• ❌ Ignoring risk assessment → ✅ Identify and assess testing risks
• ❌ Insufficient resource planning → ✅ Specify personnel, time, tool requirements
• ❌ Missing metrics → ✅ Define clear quality goals and measurements
• ❌ Strategy never changes → ✅ Adjust strategy based on project progress
• ❌ Only focus on functional testing → ✅ Cover performance, security, compatibility, etc.
• ❌ No exit criteria → ✅ Define clear test completion and release criteria

Best Practices

1. Test Strategy Core Elements

Complete test strategy should include:

# Test Strategy Document

## 1. Project Overview
- Project background
- Project goals
- Project scope

## 2. Test Objectives
- Quality goals
- Coverage goals
- Performance goals

## 3. Test Scope
- Included features
- Excluded features
- Test types

## 4. Test Approach
- Test levels (unit/integration/system/acceptance)
- Test types (functional/performance/security/compatibility)
- Test techniques (black-box/white-box/gray-box)

## 5. Test Environment
- Hardware requirements
- Software requirements
- Network requirements
- Test data

## 6. Test Tools
- Test management tools
- Automation tools
- Performance testing tools
- Defect management tools

## 7. Resource Planning
- Staffing
- Schedule
- Budget estimation

## 8. Risk Management
- Risk identification
- Risk assessment
- Mitigation measures

## 9. Test Deliverables
- Test plan
- Test cases
- Test reports
- Defect reports

## 10. Entry/Exit Criteria
- Test start conditions
- Test completion conditions
- Release criteria

2. Test Pyramid Strategy

        /\
       /  \  E2E Tests (10%)
      /____\
     /      \
    / Integration \ (30%)
   /    Tests     \
  /______________\
 /                \
/  Unit Tests (60%) \
/____________________\

Layered Testing Strategy:

• Unit Tests (60%): Fast, stable, low cost
• Integration Tests (30%): Verify module interactions
• End-to-End Tests (10%): Verify critical business flows

3. Risk-Driven Testing

Risk Assessment Matrix:

Risk Level Calculation:

Risk Level = (Business Impact + Technical Complexity + Change Frequency) / 3

4. Agile Testing Strategy

Sprint Testing Activities:

## Sprint Planning (Day 1)
- [ ] Participate in Sprint Planning
- [ ] Understand user stories
- [ ] Identify testing tasks
- [ ] Estimate testing effort

## Sprint Execution (Day 2-9)
- [ ] Write test cases
- [ ] Execute exploratory testing
- [ ] Automate regression tests
- [ ] Track defects

## Sprint Review (Day 10)
- [ ] Demo test results
- [ ] Collect feedback
- [ ] Update test strategy

## Sprint Retrospective (Day 10)
- [ ] Summarize testing experience
- [ ] Identify improvement points
- [ ] Update best practices

5. Test Type Coverage

Comprehensive Test Types:

6. Automation Strategy

Automation Decision Tree:

Is the test repeatedly executed?
  No → Manual testing
  Yes ↓

Is the test stable?
  No → Manual testing
  Yes ↓

Automation cost < Manual cost?
  No → Manual testing
  Yes → Automated testing

Automation Priority:

1. High Priority: Smoke tests, regression tests, API tests
2. Medium Priority: Functional tests, integration tests
3. Low Priority: Exploratory tests, usability tests

7. Test Metrics

Key Metrics:

## Process Metrics
- Test case count
- Test execution rate
- Automation coverage
- Defect discovery rate

## Quality Metrics
- Defect density (defects/KLOC)
- Defect escape rate
- Defect fix time
- Test pass rate

## Efficiency Metrics
- Test execution time
- Automation time saved
- Test ROI
- Team productivity

Troubleshooting

Issue 1: Don't know how to start developing strategy

Symptom: Facing new project, don't know where to start

Solution:

Use 5W2H Analysis:

## Test Strategy Analysis

### What (What to test)
- Functional requirements
- Non-functional requirements
- Business processes
- User experience

### Why (Why test)
- Quality assurance
- Risk control
- User satisfaction
- Compliance requirements

### Who (Who tests)
- Test team
- Development team
- Business team
- End users

### When (When to test)
- Unit testing: Development phase
- Integration testing: Integration phase
- System testing: Testing phase
- Acceptance testing: Before release

### Where (Where to test)
- Development environment
- Test environment
- Pre-production environment
- Production environment

### How (How to test)
- Manual testing
- Automated testing
- Exploratory testing
- Performance testing

### How Much (How much to invest)
- Personnel: X people
- Time: Y weeks
- Budget: Z dollars
- Tools: List

Issue 2: Test scope unclear

Symptom: Unsure what needs testing and what doesn't

Solution:

Create Test Scope Matrix:

## Test Scope Definition

### In Scope
| Feature Module | Test Types | Priority | Owner |
|---------------|------------|----------|-------|
| User Login | Functional, Security, Performance | P0 | John |
| Product Search | Functional, Performance | P1 | Jane |
| Order Payment | Functional, Security, Integration | P0 | Bob |

### Out of Scope
| Item | Reason | Notes |
|------|--------|-------|
| Third-party payment internal logic | External system | Only test integration points |
| Historical data migration | One-time task | Handled by DBA |
| Admin backend (old version) | Being deprecated | No longer maintained |

### Assumptions & Dependencies
- Test environment ready before Sprint starts
- Test data provided by development team
- Third-party APIs available in test environment

Issue 3: Insufficient resources, cannot complete all testing

Symptom: Limited time, personnel, budget

Solution:

Adopt Risk-Based Testing:

## Risk-Driven Test Priority

### High-Risk Areas (Must Test)
- Payment flow
- User authentication
- Data security
- Core business logic

### Medium-Risk Areas (Should Test)
- Search functionality
- Recommendation algorithm
- Notification system
- Report generation

### Low-Risk Areas (Optional Test)
- UI beautification
- Help documentation
- Statistical analysis
- Logging

### Resource Allocation
- High risk: 60% resources
- Medium risk: 30% resources
- Low risk: 10% resources

Issue 4: Test strategy disconnected from reality

Symptom: Strategy document looks good but cannot be executed

Solution:

Develop Executable Strategy:

## Executable Test Strategy

### Daily Activities
- [ ] 09:00 - Standup sync test progress
- [ ] 09:30 - Execute smoke tests
- [ ] 10:00 - Execute new feature tests
- [ ] 14:00 - Defect verification and regression
- [ ] 17:00 - Update test report

### Weekly Activities
- [ ] Monday: Sprint Planning, identify testing tasks
- [ ] Wednesday: Test progress check
- [ ] Friday: Sprint Review, demo test results

### Per Sprint Activities
- [ ] Sprint start: Create test plan
- [ ] Sprint mid: Execute tests, track defects
- [ ] Sprint end: Test summary, retrospective

### Checkpoints
- [ ] Complete smoke test within 30 min after code commit
- [ ] Complete functional test within 2 hours after user story completion
- [ ] Complete regression test 1 day before Sprint end

Issue 5: Test strategy for different environments

Symptom: Don't know what testing to do in different environments

Solution:

Environment Testing Matrix:

## Environment Testing Strategy

### Development Environment (Dev)
- **Purpose**: Quick verification of code changes
- **Test Types**: Unit tests, smoke tests
- **Frequency**: Every code commit
- **Automation**: 100%

### Test Environment (QA)
- **Purpose**: Comprehensive functional testing
- **Test Types**: Functional, integration, regression
- **Frequency**: Daily build
- **Automation**: 80%

### Pre-production Environment (Staging)
- **Purpose**: Production environment simulation
- **Test Types**: End-to-end, performance, security
- **Frequency**: Before release
- **Automation**: 60%

### Production Environment (Production)
- **Purpose**: Monitoring and verification
- **Test Types**: Smoke tests, monitoring
- **Frequency**: After release, continuous monitoring
- **Automation**: 100%

Issue 6: How to develop strategy in agile projects

Symptom: Agile projects change fast, strategy hard to develop

Solution:

Adopt Lightweight Agile Testing Strategy:

## Agile Testing Strategy

### Testing Quadrants

**Quadrant 1: Technology-facing, Supporting the Team**
- Unit tests
- Component tests
- Automation first

**Quadrant 2: Business-facing, Supporting the Team**
- Functional tests
- User story tests
- Example-driven

**Quadrant 3: Business-facing, Critique Product**
- Exploratory testing
- Usability testing
- User acceptance testing

**Quadrant 4: Technology-facing, Critique Product**
- Performance testing
- Security testing
- Maintainability testing

### Testing Activities in Sprint

**Sprint Planning**:
- Participate in user story discussion
- Identify testing tasks
- Define acceptance criteria

**Daily Standup**:
- Sync test progress
- Identify blocking issues
- Adjust test plan

**Sprint Review**:
- Demo test results
- Collect feedback
- Verify acceptance criteria

**Sprint Retrospective**:
- Review testing process
- Identify improvement points
- Update testing practices

Issue 7: How to measure test strategy effectiveness

Symptom: Don't know if strategy is effective

Solution:

Define Test Strategy KPIs:

## Test Strategy Effectiveness Metrics

### Quality Metrics
| Metric | Target | Current | Status |
|--------|--------|---------|--------|
| Production defects | < 5/month | 3/month | ✅ |
| Defect escape rate | < 5% | 3% | ✅ |
| Critical defects | 0 | 0 | ✅ |
| Customer complaints | < 2/month | 1/month | ✅ |

### Efficiency Metrics
| Metric | Target | Current | Status |
|--------|--------|---------|--------|
| Test automation rate | > 80% | 85% | ✅ |
| Test execution time | < 2h | 1.5h | ✅ |
| Defect fix time | < 2 days | 1.5 days | ✅ |
| Release frequency | 2 weeks | 2 weeks | ✅ |

### Coverage Metrics
| Metric | Target | Current | Status |
|--------|--------|---------|--------|
| Requirements coverage | 100% | 100% | ✅ |
| Code coverage | > 80% | 85% | ✅ |
| Automation coverage | > 70% | 75% | ✅ |

### Improvement Suggestions
- ✅ Quality metrics met, continue maintaining
- ⚠️  Consider increasing release frequency to weekly
- 💡 Explore AI-assisted testing to improve efficiency

Get More Help

If the issue is still unresolved:

1. Check FAQ.md
2. Check example README.md files
3. Reference test strategy templates
4. Consult team's test manager

Related Skills: requirements-analysis-en, test-case-writing-en, test-reporting-en, functional-testing-en.

Target Audience

• QA engineers and developers executing this testing domain in real projects
• Team leads who need structured, reproducible testing outputs
• AI users who need fast, format-ready deliverables for execution and reporting

Not Recommended For

• Pure production incident response without test scope/context
• Decisions requiring legal/compliance sign-off without expert review
• Requests lacking minimum inputs (scope, environment, expected behavior)

Critical Success Factors

• Provide clear scope, environment, and acceptance criteria before generation
• Validate generated outputs against real system constraints before execution
• Keep artifacts traceable (requirements -> test points -> defects -> decisions)

Output Templates and Parsing Scripts

• Template directory: output-templates/

- template-word.md (Word-friendly structure) - template-excel.tsv (Excel paste-ready) - template-xmind.md (XMind-friendly outline) - template-json.json - template-csv.csv - template-markdown.md

• Parser scripts directory: scripts/

- Parse (generic): parse_output_formats.py - Parse (per-format): parse_word.py, parse_excel.py, parse_xmind.py, parse_json.py, parse_csv.py, parse_markdown.py - Convert (generic): convert_output_formats.py - Convert (per-format): convert_to_word.py, convert_to_excel.py, convert_to_xmind.py, convert_to_json.py, convert_to_csv.py, convert_to_markdown.py - Batch convert: batch_convert_templates.py (outputs into artifacts/)

Examples:

python3 scripts/parse_json.py output-templates/template-json.json
python3 scripts/parse_markdown.py output-templates/template-markdown.md
python3 scripts/convert_to_json.py output-templates/template-markdown.md
python3 scripts/convert_output_formats.py output-templates/template-json.json --to csv
python3 scripts/batch_convert_templates.py --skip-same