기능 테스트 계획 제안

기능 테스트 계획 제안 스킬

목적

요구사항과 제약 조건을 구체적인 테스트에 체계적으로 매핑하는 테스트 계획을 생성합니다. 이를 통해 모든 요구사항에 검증 방안이 마련되고 테스트 구현을 안내할 수 있습니다.

사용 시점

• 핵심 제약 조건이 포함된 설계 문서가 존재할 때
• 구현 전에 테스트 접근 방식을 계획할 준비가 되었을 때
• 각 요구사항을 검증할 테스트가 무엇인지 문서화해야 할 때

전제 조건

• 기능 개념 문서가 ./docs/features/NNNN-feature-name/concept.md에 존재해야 함
• 요구사항 문서가 ./docs/features/NNNN-feature-name/requirements.md에 존재해야 함
• 설계 문서가 ./docs/features/NNNN-feature-name/design.md에 존재해야 함 (핵심 제약 조건 포함)

절차

1. 전제 조건 확인

ls ./docs/features/NNNN-feature-name/concept.md
ls ./docs/features/NNNN-feature-name/requirements.md
ls ./docs/features/NNNN-feature-name/design.md

존재하지 않는 파일이 있다면 먼저 해당 단계를 완료하세요.

2. 요구사항 및 제약 조건 추출

requirements.md에서 모든 REQ-* 식별자를 검토합니다. design.md에서 모든 CC-* 핵심 제약 조건을 검토합니다.

3. 테스트 계획 파일 생성

./docs/features/NNNN-feature-name/test-plan.md 파일을 다음 구조로 생성합니다:

# 테스트 계획: 기능 이름

## 개요

테스트 접근 방식에 대한 간략한 설명.

## 테스트 유형

- **단위(Unit)**: 내부 로직을 격리하여 테스트, 모의(Mock) 허용
- **통합(Integration)**: 실제 외부 리소스(파일 시스템, 네트워크)를 사용, 모의(Mock) 금지
- **테스트 불가(Not testable)**: 자동화된 테스트로 검증 불가 (이유 설명)
- **범위 외(Out of scope)**: 외부 인증 필요 - 문서화하되 구현하지 않음

## 요구사항 커버리지

| 요구사항 ID | 테스트 유형 | 테스트 이름 | 설명 |
|-------------|-------------|-------------|------|
| REQ-1       | unit        | test_xxx  | 검증 내용 |
| REQ-2       | integration | test_yyy  | 검증 내용 |
| REQ-3       | not-testable | -         | 테스트 불가 이유 |
| REQ-4       | out-of-scope | -         | 범위 외 이유 |

## 핵심 제약 조건 검증

| 제약 조건 ID | 검증 접근 방식 | 테스트 이름 |
|--------------|----------------|-------------|
| CC-1         | 제약 조건을 어떻게 검증하는지 | test_xxx |

## 통합 테스트 요구사항

CLI 프로그램의 경우 통합 테스트는 반드시:
- 사용자가 실행하는 실제 CLI 바이너리/명령어를 실행해야 함
- 내부 API를 직접 테스트해서는 안 됨
- 사용자/고객이 실제로 수행할 작업을 그대로 수행해야 함

## 테스트 구현 참고 사항

이 테스트를 구현하기 위한 특별한 지침이 있다면 여기에 기록합니다.

4. 각 요구사항 매핑

requirements.md의 각 REQ-*에 대해:

1. 테스트 유형 결정:

   • 단위(Unit): 내부 로직, 알고리즘, 데이터 변환
   • 통합(Integration): 파일 I/O, 네트워크 호출, CLI 명령어, 외부 프로세스
   • 테스트 불가(Not testable): 자동화 불가 (예: 주관적 품질, 인간 판단 필요, 설정이 불가능한 경우)
   • 범위 외(Out of scope): 외부 시스템(클라우드 API, 인증이 필요한 레지스트리)에 대한 인증 필요

2. 테스트 이름을 설명적으로 작성 (예: test_parses_valid_config)

3. 검증하는 내용에 대한 간략한 설명 작성

5. 각 핵심 제약 조건 매핑

design.md의 각 CC-*에 대해:

1. 제약 조건이 어떻게 검증될지 설명
2. 이를 강제하는 특정 테스트 이름 연결
3. 자동화 테스트 대신 코드 리뷰가 필요한 경우 명시

6. CLI 테스트 접근 방식 문서화

기능에 CLI 명령어가 포함된 경우:

• 통합 테스트는 실제 바이너리를 실행
• stdout/stderr를 캡처하여 검증
• 실제 사용자 워크플로우를 처음부터 끝까지 테스트
• CLI 레이어를 모의(Mock)하지 않음

7. 범위 외 테스트 표시

외부 인증이 필요한 테스트의 경우:

1. 무엇을 테스트할 것인지 문서화
2. 범위 외인 이유 설명
3. 수동 검증 단계가 있다면 기록

검증

# 파일 존재 확인
ls ./docs/features/NNNN-feature-name/test-plan.md

# 모든 요구사항이 포함되었는지 확인
grep -c "REQ-" ./docs/features/NNNN-feature-name/test-plan.md
grep -c "REQ-" ./docs/features/NNNN-feature-name/requirements.md
# 개수가 비슷해야 함

# 모든 제약 조건이 포함되었는지 확인
grep -c "CC-" ./docs/features/NNNN-feature-name/test-plan.md
grep -c "CC-" ./docs/features/NNNN-feature-name/design.md
# 개수가 비슷해야 함

일반적인 문제

누락된 커버리지: 모든 REQ-*와 CC-*는 테스트 계획에 반드시 포함되어야 합니다. 검증 grep 명령어를 사용하여 확인하세요.

잘못된 테스트 유형: 단위 테스트는 파일 시스템/네트워크를 사용해서는 안 됩니다. 통합 테스트는 모의(Mock)를 사용해서는 안 됩니다.

동작 대신 내부 구현 테스트: CLI 도구의 경우 사용자가 실행하는 CLI 명령어를 테스트하고 내부 함수를 테스트하지 마세요.

모호한 설명: 테스트 설명은 어떤 특정 동작을 검증하는지 명확히 명시해야 합니다.

다음 단계

테스트 계획을 생성한 후:

1. 이해 관계자와 커버리지를 검토
2. 기능 구현 계획 제안 스킬로 진행하여 구현 계획 수립
3. 구현 계획은 테스트 요구사항을 위해 test-plan.md를 참조해야 함