QA Strategy and Metrics Skill
Metadata (Tier 1)
Keywords: strategy, testing pyramid, quality, metrics, technical debt, complexity, maintainability, coverage principles
File Patterns: N/A (conceptual skill)
Modes: code_review, testing_frontend, testing_backend
Activation: Conceptual queries about testing strategy, quality metrics, or technical debt.
Instructions (Tier 2)
Testing Pyramid
E2E (5-10%)
Integration (15-20%)
Unit Tests (70-80%)
Rationale:
- Unit: Fast (ms), cheap, high confidence in individual components
- Integration: Moderate speed (seconds), tests component interactions
- E2E: Slow (seconds-minutes), expensive, fragile, but validates real workflows
Anti-Pattern: Inverted pyramid (too many E2E tests)
- Slow CI/CD pipeline
- Flaky tests due to external dependencies
- High maintenance burden
Cyclomatic Complexity (CC)
Formula: CC = E - N + 2P
- E = edges in control flow graph
- N = nodes
- P = connected components
Interpretation:
- 1-5: Low risk, straightforward logic
- 6-10: Moderate complexity, well-structured
- 11-20: Complex, consider refactoring
- 21+: Very complex, MUST refactor
When to refactor:
- Function has CC > 15
- Function has multiple responsibilities
- Difficult to write tests (need many mocks)
Code Coverage Metrics
Statement Coverage: % of code lines executed Branch Coverage: % of decision paths taken (if/else, switch) Function Coverage: % of functions called
Critical Insight: 100% coverage ≠ 100% tested
- May miss edge cases
- May not test error handling
- May not validate business logic
Focus Areas:
- Error handlers (try/except, catch)
- Boundary conditions (null, empty, max)
- Complex conditionals
Maintainability Index (MI)
Formula (simplified):
MI = 171 - 5.2 * ln(HV) - 0.23 * CC - 16.2 * ln(LOC)
- HV = Halstead Volume (code complexity)
- CC = Cyclomatic Complexity
- LOC = Lines of Code
Ranges:
- 85-100: Highly maintainable
- 65-84: Moderately maintainable
- 0-64: Difficult to maintain
Technical Debt
Formula: Debt = (Cost to Fix) * (Impact if Not Fixed)
Types:
- Code Debt: Poor structure, duplication
- Test Debt: Low coverage, missing tests
- Documentation Debt: Missing/outdated docs
- Architectural Debt: Design constraints
When to Pay Down:
- High-traffic code paths
- Before major refactoring
- Security-sensitive areas