Agent skill

testing-strategy

테스트 전략, 테스팅 계획, QA 전략, 품질 보증, 테스트 피라미드, 테스트 시나리오, 커버리지 목표 - Designs test strategies including test pyramid ratios, scenario categories, and coverage targets. Use when planning how to test a feature, designing QA approach, or creating test plans. Do NOT use for TDD implementation (use tdd-workflow) or E2E test execution (use e2e-runner).

View SKILL.md on GitHub Repository
Stars 0
Forks 0

Install this agent skill to your Project

npx add-skill https://github.com/aimskr/aims-claude-toolkit/tree/main/skills/testing-strategy

Metadata

Additional technical details for this skill

author
jaehashin
version
1.2.0

SKILL.md

Testing Strategy Skill

Provides a systematic workflow for test strategy planning and quality assurance.

When to Use

  • Designing test strategy for new features
  • Improving test coverage
  • Creating QA checklists
  • Designing test scenarios

Stack Detection (Auto)

Before designing strategy, detect the project's test stack:

1. Check package.json → Jest/Vitest/Mocha/Playwright/Cypress
2. Check requirements.txt/pyproject.toml → pytest/unittest
3. Check build.gradle/pom.xml → JUnit/TestNG/Mockito
4. Check CI config (.github/workflows, Jenkinsfile) → existing test stages
5. Check existing test files → patterns already in use

Auto-select test tools based on detection:

Stack Unit Integration E2E
TypeScript/Node Jest or Vitest Supertest Playwright
Python/FastAPI pytest pytest + httpx Playwright
Java/Spring Boot JUnit 5 Spring Boot Test Selenium/Playwright
React/Next.js Vitest + RTL MSW Playwright/Cypress

If no test infrastructure exists, recommend setup based on detected stack before proceeding to strategy design.

The Process

Phase 1: Test Scope Analysis

Current State Assessment:

  1. Analyze existing test code structure (tests/, __tests__/, *.spec.*)
  2. Check current coverage
  3. Review test stages in CI pipeline

Scope Definition:

  • In Scope: What to test this time
  • Out of Scope: What to exclude and why
  • Dependencies: External dependencies requiring mocks/stubs

Phase 2: Test Pyramid Design

Ratio Guide:

┌─────────────────────────────────────┐
│  E2E (5-10%)                        │
│  - Critical User Journeys only      │
│  - Execution: Slow                  │
│  - Maintenance: Difficult           │
├─────────────────────────────────────┤
│  Integration (15-25%)               │
│  - API boundaries, DB integration   │
│  - Module interactions              │
├─────────────────────────────────────┤
│  Unit (70-80%)                      │
│  - Pure functions, business logic   │
│  - Fast feedback                    │
│  - Isolated tests                   │
└─────────────────────────────────────┘

Phase 3: Test Scenario Writing

Scenario Categories:

Type Description Example
Happy Path Normal flow Valid input → Success
Edge Cases Boundary conditions Empty array, max value, null
Error Cases Error handling Invalid input, network error
Security Security scenarios Unauthenticated access, permission overflow

Boundary Value Analysis (BVA):

Input range: 1-100

Test values:
- 0 (lower -1) → Error
- 1 (lower bound) → Success
- 50 (middle) → Success
- 100 (upper bound) → Success
- 101 (upper +1) → Error

Phase 4: Test Code Writing Guide

AAA Pattern:

def test_feature_condition_expectedResult():
    # Arrange - Setup
    user = User(name="test")

    # Act - Execute
    result = user.greet()

    # Assert - Verify
    assert result == "Hello, test"

FIRST Principles:

  • Fast: Execute quickly
  • Independent: No dependency on other tests
  • Repeatable: Always same result
  • Self-validating: Clear success/failure
  • Timely: Written alongside code

Phase 5: Test Execution and Verification

Coverage Targets:

Target Setting Guide:

- Line Coverage: 80%+ (minimum baseline)
- Branch Coverage: 75%+ (conditional verification)
- Function Coverage: 90%+ (prevent function omission)

Note: Coverage is a means, not an end
High coverage ≠ Good tests

Flaky Test Handling:

  1. Identify reproduction conditions
  2. Timing issues → Explicit waits
  3. Order dependency → Strengthen isolation
  4. External dependency → Mock handling

Output Templates

Test Strategy Document

markdown
# Test Strategy: [Feature Name]

## Test Scope
- **In Scope:**
- **Out of Scope:**

## Test Pyramid
| Type | Ratio | Target | Tools |
|------|-------|--------|-------|
| Unit | 70% | Business logic | Jest/Pytest/JUnit |
| Integration | 20% | API, DB | Supertest/pytest |
| E2E | 10% | Critical flows | Playwright/Cypress |

## Test Scenarios
### Normal Cases
| ID | Scenario | Input | Expected Result |
|----|----------|-------|-----------------|

### Exception Cases
| ID | Scenario | Input | Expected Result |
|----|----------|-------|-----------------|

## Coverage Targets
- Line: 80%
- Branch: 75%

## Test Environment
- Local: Docker Compose
- CI: GitHub Actions

Key Principles

  1. Test First (TDD): Write tests before code when possible
  2. Isolation: Each test must run independently
  3. Clear Failure: Cause should be immediately apparent on failure
  4. Maintainability: Manage test code like production code
  5. Appropriate Level: Meaningful tests over 100% coverage

Completion

테스트 전략 문서가 생성되고 사용자가 승인하면 완료.

Troubleshooting

Coverage is high but bugs still slip through: Coverage measures lines executed, not behavior verified. Audit assertions — tests with no meaningful assertions inflate coverage without catching bugs. Test pyramid ratio is wrong (too many E2E): Identify E2E tests that test only one module’s logic and convert to unit/integration tests. Reserve E2E for cross-module critical paths only. Flaky tests blocking CI: Quarantine flaky tests immediately (move to separate suite). Fix root cause (timing, order dependency, external state) before restoring to main suite.

Recommended Agent Skills

Expand your agent's capabilities with these related and highly-rated skills.

aimskr/aims-claude-toolkit

build-error-resolver

빌드 에러, 빌드 오류, 컴파일 에러, 빌드 실패 해결, 의존성 에러 - Specialized in resolving build errors, compilation failures, and dependency issues. Use when build fails, compilation errors occur, or dependency conflicts arise. Do NOT use for runtime bugs or logic errors (use debug-specialist instead).

0 0
Explore
aimskr/aims-claude-toolkit

brainstorming

브레인스토밍, 아이디어, 기획, 구상, 아이디어회의, 설계, 요구사항 분석, 접근법 탐색 - Use before creating new features or significant changes to explore user intent, requirements, and design options. Collaborative brainstorming through step-by-step questioning. Do NOT use for simple bug fixes, config changes, or tasks with clear requirements already defined.

0 0
Explore
aimskr/aims-claude-toolkit

doc-coauthoring

문서 작성, 문서화, 문서, 스펙 작성, 기술 문서, 제안서, RFC, 설계 문서, 의사결정 문서 - Collaborative document co-authoring through 3 stages: context gathering, iterative refinement, and reader testing. Use when writing docs, proposals, tech specs, decision docs, or RFCs. Do NOT use for PRD/product requirements (use prd-strategist) or implementation plans (use writing-plans).

0 0
Explore
aimskr/aims-claude-toolkit

learning-research

학습 리서치, 학습 자료, 공부 자료, 학습, 공부, 스터디, 개념 정리, 이해 - 특정 주제를 깊이 이해하기 위한 학습 자료를 수집·정리한다. 병렬 전문가 서브에이전트로 개념, 원리, 실습, 심화 자료를 수집하고 이해도별로 체계화된 학습 노트를 생성한다. Obsidian vault에 자동 저장. 의사결정용 자료 조사는 research 스킬을, 시장조사는 market-research 스킬을 사용할 것.

0 0
Explore
aimskr/aims-claude-toolkit

devil-advocate

0 0
Explore
aimskr/aims-claude-toolkit

ui-ux-design

UI, UX, 디자인, UI 디자인, UX 디자인, 사용자 경험, 화면, 인터랙션, 라이브 리뷰, 와이어프레임, 화면 설계 - Create and review UI/UX designs with live browser testing. Use for design implementation, interaction testing, visual inspection, and iterative refinement with Playwright. Also triggered when continuing from prd-strategist's Design Direction output.

0 0
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results