Testing Strategy
Overview
This skill guides agents in selecting and applying appropriate testing strategies for any deliverable. The right testing approach depends on what's being tested, its criticality, and the available time and resources.
When to Use
- Before starting development to define testing approach upfront
- When planning how to verify a deliverable works correctly
- When deciding what types of tests to write and in what order
- When test coverage or quality is questioned
- When introducing a new feature, change, or fix
- Don't use when: Building throwaway prototypes or exploratory proofs of concept
Core Procedures
Step 1: Determine Testing Scope
Ask:
- What is the complexity of the deliverable? (simple/moderate/complex)
- What is the criticality? (low/medium/high/critical)
- Who will use it? (internal team/cross-company/end users)
- What are the failure consequences? (inconvene/degraded/blocked/harmful)
Step 2: Select Testing Layers
Based on scope, select applicable testing layers:
| Deliverable Type |
Required Testing |
Optional |
| Single function/method |
Unit tests |
Property-based tests |
| Module/component |
Unit + integration tests |
Performance tests |
| API/Service |
Unit + integration + contract tests |
Load/security tests |
| UI/Feature |
Unit + E2E tests |
Accessibility/usability tests |
| System/Platform |
Integration + E2E + load tests |
Security/chaos tests |
| Data/Analytics |
Data validation tests |
Accuracy/privacy tests |
| Prompt/AI output |
Functional tests + evaluation tests |
Bias/safety tests |
| Infrastructure |
Integration + smoke tests |
Chaos/disaster recovery tests |
Step 3: Define Test Cases
For each testing layer, define cases covering:
- Happy Path: Expected inputs produce expected outputs
- Edge Cases: Boundary conditions, empty/null inputs, maximum values
- Error Cases: Invalid inputs, missing dependencies, failure modes
- Regression Cases: Previously discovered bugs, known issues
Step 4: Prioritize Test Execution
Order:
- Unit tests first (fast, cheap, isolate problems)
- Integration tests second (verify component interaction)
- E2E/system tests third (verify full workflow)
- Performance/security tests as applicable
- Manual/acceptance tests last
Step 5: Set Coverage Targets
| Criticality |
Minimum Coverage |
Target Coverage |
| Low |
50% |
70% |
| Medium |
70% |
85% |
| High |
85% |
95% |
| Critical |
95% |
100% |
Quality Checklist
Error Handling
- Error: Cannot automate a test case
Response: Document manual test, explore automation alternatives, flag for future automation
- Error: Tests are too slow to run regularly
Response: Separate into fast/slow suites, run fast suite on every change, slow suite on schedule
- Error: Tests are flaky (intermittent failures)
Response: Fix or quarantine flaky tests immediately - they undermine confidence in test suite
Cross-Team Integration
Related Skills: test-driven-development, testing-verification, output-validation-checklist, edge-case-analysis
Used By: ALL agents writing code or deliverables, especially testing agents (QA teams, Code Reviewers)
1---2name: testing-strategy3description: Use when planning how to test any deliverable or system. This skill provides a framework for selecting the right testing approach based on what is being delivered, ensuring comprehensive coverage without unnecessary overhead.4---56# Testing Strategy78## Overview9This skill guides agents in selecting and applying appropriate testing strategies for any deliverable. The right testing approach depends on what's being tested, its criticality, and the available time and resources.1011## When to Use12- Before starting development to define testing approach upfront13- When planning how to verify a deliverable works correctly14- When deciding what types of tests to write and in what order15- When test coverage or quality is questioned16- When introducing a new feature, change, or fix17- **Don't use when:** Building throwaway prototypes or exploratory proofs of concept1819## Core Procedures2021### Step 1: Determine Testing Scope22Ask:23- What is the complexity of the deliverable? (simple/moderate/complex)24- What is the criticality? (low/medium/high/critical)25- Who will use it? (internal team/cross-company/end users)26- What are the failure consequences? (inconvene/degraded/blocked/harmful)2728### Step 2: Select Testing Layers29Based on scope, select applicable testing layers:3031| Deliverable Type | Required Testing | Optional |32|-----------------|-----------------|----------|33| Single function/method | Unit tests | Property-based tests |34| Module/component | Unit + integration tests | Performance tests |35| API/Service | Unit + integration + contract tests | Load/security tests |36| UI/Feature | Unit + E2E tests | Accessibility/usability tests |37| System/Platform | Integration + E2E + load tests | Security/chaos tests |38| Data/Analytics | Data validation tests | Accuracy/privacy tests |39| Prompt/AI output | Functional tests + evaluation tests | Bias/safety tests |40| Infrastructure | Integration + smoke tests | Chaos/disaster recovery tests |4142### Step 3: Define Test Cases43For each testing layer, define cases covering:441. **Happy Path:** Expected inputs produce expected outputs452. **Edge Cases:** Boundary conditions, empty/null inputs, maximum values463. **Error Cases:** Invalid inputs, missing dependencies, failure modes474. **Regression Cases:** Previously discovered bugs, known issues4849### Step 4: Prioritize Test Execution50Order:511. Unit tests first (fast, cheap, isolate problems)522. Integration tests second (verify component interaction)533. E2E/system tests third (verify full workflow)544. Performance/security tests as applicable555. Manual/acceptance tests last5657### Step 5: Set Coverage Targets58| Criticality | Minimum Coverage | Target Coverage |59|-------------|-----------------|-----------------|60| Low | 50% | 70% |61| Medium | 70% | 85% |62| High | 85% | 95% |63| Critical | 95% | 100% |6465## Quality Checklist66- [ ] Testing scope appropriate for complexity and criticality67- [ ] All required testing layers included68- [ ] Happy path, edge cases, and error cases covered69- [ ] Tests are automated where possible70- [ ] Coverage targets defined and tracked71- [ ] Tests are maintainable (clear, independent, documented)7273## Error Handling74- **Error:** Cannot automate a test case75 **Response:** Document manual test, explore automation alternatives, flag for future automation76- **Error:** Tests are too slow to run regularly77 **Response:** Separate into fast/slow suites, run fast suite on every change, slow suite on schedule78- **Error:** Tests are flaky (intermittent failures)79 **Response:** Fix or quarantine flaky tests immediately - they undermine confidence in test suite8081## Cross-Team Integration82**Related Skills:** test-driven-development, testing-verification, output-validation-checklist, edge-case-analysis83**Used By:** ALL agents writing code or deliverables, especially testing agents (QA teams, Code Reviewers)
Construct-AI-primary