testing-strategy
Scannednpx machina-cli add skill shinpr/agentic-code/testing-strategy --openclawTest Strategy: ROI-Based Selection
Core Principle: Maximum Coverage, Minimum Tests
Philosophy: 10 reliable tests > 100 unmaintained tests
Quality over quantity - focus resources on high-value tests that provide maximum coverage with minimum maintenance burden.
ROI Calculation Framework
ROI Formula
ROI Score = (Business Value × User Frequency + Legal Requirement × 10 + Defect Detection)
/ (Creation Cost + Execution Cost + Maintenance Cost)
Value Components
Business Value (0-10 scale):
- 10: Revenue-critical (payment processing, checkout)
- 8-9: Core business features (user registration, data persistence)
- 5-7: Important secondary features (search, filtering)
- 2-4: Nice-to-have features (UI enhancements)
- 0-1: Cosmetic features
User Frequency (0-10 scale):
- 10: Every user, every session (authentication)
- 8-9: >80% of users regularly
- 5-7: 50-80% of users occasionally
- 2-4: <50% of users rarely
- 0-1: Edge case users only
Legal Requirement (boolean → 0 or 1):
- 1: Legally mandated (GDPR compliance, data protection)
- 0: Not legally required
Defect Detection (0-10 scale):
- 10: High likelihood of catching critical bugs
- 5-7: Moderate likelihood of catching bugs
- 0-4: Low likelihood (simple logic, well-tested patterns)
Cost Components
Test Level Cost Table:
| Test Level | Creation Cost | Execution Cost | Maintenance Cost | Total Cost |
|---|---|---|---|---|
| Unit | 1 | 1 | 1 | 3 |
| Integration | 3 | 5 | 3 | 11 |
| E2E | 10 | 20 | 8 | 38 |
Cost Rationale:
- Unit Tests: Fast to write, fast to run, rarely break from refactoring
- Integration Tests: Moderate setup, slower execution, moderate maintenance
- E2E Tests: Complex setup, very slow execution, high brittleness (12x more expensive than unit tests)
ROI Calculation Examples
Example 1: Payment Processing Integration Test
Business Value: 10 (revenue-critical)
User Frequency: 9 (90% of users)
Legal Requirement: 0
Defect Detection: 8 (high complexity)
ROI = (10 × 9 + 0 + 8) / 11 = 98 / 11 = 8.9
Decision: HIGH ROI → Generate this test
Example 2: UI Theme Toggle E2E Test
Business Value: 2 (cosmetic feature)
User Frequency: 5 (50% of users)
Legal Requirement: 0
Defect Detection: 3 (simple logic)
ROI = (2 × 5 + 0 + 3) / 38 = 13 / 38 = 0.34
Decision: LOW ROI → Skip this E2E test (consider unit test instead)
Example 3: GDPR Data Deletion E2E Test
Business Value: 8 (critical compliance)
User Frequency: 1 (rare user action)
Legal Requirement: 1 (legally mandated)
Defect Detection: 9 (high consequences if broken)
ROI = (8 × 1 + 1 × 10 + 9) / 38 = 27 / 38 = 0.71
Decision: MEDIUM ROI → Generate (legal requirement justifies cost)
Critical User Journey Definition
Tests with HIGH priority regardless of strict ROI calculation:
Mandatory Coverage Areas
-
Revenue-Impacting Flows
- Payment processing end-to-end
- Checkout and order completion
- Subscription management
- Purchase confirmation and receipts
-
Legally Required Flows
- GDPR data deletion/export
- User consent management
- Data protection compliance
- Regulatory audit trails
-
High-Frequency Core Functionality
- User authentication/authorization (>80% of users)
- Core CRUD operations for primary entities
- Critical business workflows
- Data integrity for primary data models
Budget Exception: Critical User Journeys may exceed standard budget limits with explicit justification.
Test Selection Guidelines
Selection Thresholds
Integration Tests:
- ROI > 3.0: Strong candidate
- ROI 1.5-3.0: Consider based on available budget
- ROI < 1.5: Skip or convert to unit test
E2E Tests:
- ROI > 2.0: Strong candidate
- ROI 1.0-2.0: Consider if Critical User Journey
- ROI < 1.0: Skip (too expensive relative to value)
Push-Down Analysis
Before generating higher-level test, ask:
-
Can this be unit-tested?
- YES → Generate unit test instead
- NO → Continue to integration test consideration
-
Already covered by integration test?
- YES → Don't create E2E version
- NO → Consider E2E test if ROI justifies
Example:
- "Tax calculation accuracy" → Unit test (pure logic)
- "Tax applied to order total" → Integration test (multiple components)
- "User sees correct tax in checkout flow" → E2E test only if Critical User Journey
Deduplication Strategy
Before generating any test:
- Search existing test suite for similar coverage
- Check for overlapping scenarios at different test levels
- Identify redundant verifications already covered elsewhere
Decision Matrix:
Existing coverage found?
→ Full coverage: Skip new test
→ Partial coverage: Extend existing test
→ No coverage: Generate new test
Application in Test Generation
Phase 1: Candidate Enumeration
- List all possible test scenarios
- Assign ROI metadata to each candidate
Phase 2: ROI-Based Selection
- Calculate ROI for each candidate
- Apply deduplication checks
- Apply push-down analysis
- Sort by ROI (descending)
Phase 3: Budget Enforcement
- Select top N tests within budget limits
- Document budget usage
- Report selection rationale
See: .agents/tasks/acceptance-test-generation.md for detailed implementation process
Continuous Improvement
Metrics to Track
-
Selection Rate: Tests generated / Total candidates
- Target: 25-35% (indicates effective filtering)
-
Average ROI: Average ROI of generated tests
- Target: >3.0 for integration, >1.5 for E2E
-
Budget Utilization: Actual tests / Budget limit
- Target: 80-100% (full utilization of valuable test slots)
-
Defect Detection Rate: Bugs caught / Total tests
- Track over time to validate ROI predictions
Calibration
Periodically review:
- Are high-ROI tests actually catching bugs?
- Are cost estimates accurate?
- Do business value ratings align with stakeholder priorities?
Adjust formula weights based on empirical data
Anti-Patterns to Avoid
❌ Gaming the System:
- Inflating business value scores to justify favorite tests
- Ignoring ROI when it contradicts intuition
- Cherry-picking ROI calculation only for preferred tests
✅ Proper Usage:
- Apply ROI calculation consistently to all candidates
- Document justification when overriding ROI decisions
- Use empirical data to calibrate scores over time
❌ Analysis Paralysis:
- Spending excessive time on precise ROI calculations
- Debating single-point differences in scores
- Treating ROI as exact science rather than decision aid
✅ Practical Application:
- Use ROI for relative prioritization, not absolute precision
- Focus on order-of-magnitude differences (8.9 vs 0.34)
- Make quick decisions for obvious high/low ROI cases
Source
git clone https://github.com/shinpr/agentic-code/blob/main/.agents/skills/testing-strategy/SKILL.mdView on GitHub Overview
This skill prioritizes tests based on ROI and critical user journeys, guiding decisions on coverage, test types, and budgets. It emphasizes high-value tests with maximum coverage and minimal maintenance, using a formal ROI framework to balance value, frequency, legal needs, and defect detection against cost.
How This Skill Works
For each test item, assign Business Value, User Frequency, Legal Requirement, and Defect Detection. Compute ROI Score using the provided ROI formula and compare against cost estimates from the Test Level Cost table (Unit, Integration, E2E). Prioritize tests with high ROI and ensure Critical User Journeys (revenue flows, legal flows, high-frequency core functions) receive coverage even if budgets are tight.
When to Use It
- Deciding test coverage for a new release
- Choosing between unit, integration, and E2E test types
- Budgeting testing effort across features
- Prioritizing tests for revenue-critical and legally required flows
- Reassessing the suite after major refactors or scope changes
Quick Start
- Step 1: Identify candidate tests and assign Business Value, User Frequency, Legal Requirement, and Defect Detection for each
- Step 2: Look up the Test Level Cost (Unit=3, Integration=11, E2E=38) and compute ROI Score using the formula
- Step 3: Prioritize tests with high ROI and align coverage to Critical User Journeys; allocate budget accordingly
Best Practices
- Anchor tests to Critical User Journeys such as revenue flows, GDPR-related actions, and high-frequency authentication
- Compute ROI scores per candidate test and per test level to guide coverage decisions
- Prefer unit tests when ROI is high and maintenance is low; reserve E2E tests for high-value flows
- Document business value, user frequency, legal requirements, and defect detection with each test candidate
- Revisit ROI and coverage periodically as product metrics shift
Example Use Cases
- Payment Processing Integration Test – high ROI due to revenue impact; generate this test
- UI Theme Toggle E2E Test – often low ROI; consider unit tests or omit if not critical
- GDPR Data Deletion E2E Test – medium ROI but legally required; justify cost
- User Authentication Regression – high-frequency core functionality test with strong ROI rationale
- Core CRUD Validation for Primary Entities – high-value tests essential for data integrity