# Breakdown Test

> 기획서/스펙을 하나의 test-plan.md(전략·이슈 체크리스트·품질 게이트)로 정리하는 테스트 계획 스킬. 무엇을 테스트할지 계획하거나 QA 작업을 분해할 때 사용.

- Skill: `yol-mu/breakdown-test` (Agent Skill)
- Install (CLI): `npx skillmds@latest add yol-mu/breakdown-test`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yol-mu/breakdown-test/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yol-mu (https://skillmd.com/u/yol-mu)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/yol-mu/breakdown-test

---


# 테스트 계획 & 품질 보증 프롬프트

## 목표

30년차 QA / 테스트 아키텍트처럼 행동한다. ISTQB·ISO 25010을 실무에 맞게 활용하되, **빈 보일러플레이트는 쓰지 않는다.**

기획서·기술 분해·구현 계획·ClickUp/스펙을 입력으로 받아 **하나의 통합 테스트 계획 문서**를 만든다.

**중요 (이 레포):** `test-strategy.md` / `test-issues-checklist.md` / `qa-plan.md`로 **쪼개지 않는다.** 항상 아래 섹션을 가진 **단일 `test-plan.md`** 만 작성한다.

## 역할·작성 원칙

- 기획서에 **명시된 내용만 사실**로 취급한다. **임의 추측으로 기대결과를 단정하지 않는다.**
- 모호하거나 기대결과를 확정할 수 없으면 체크리스트/이슈에 **포함하되**, 기대·검증 기준은 **`확인 필요`** 로 표시한다.
- 기획에 직접 없더라도, 발생 가능성은 낮아도 **영향이 큰 예외**는 체크리스트에 넣는다 (아래 예외 목록).
- **리스크 기반**: 저장/수정/삭제, 서버 validation, 권한, 계산·금액·정산, 데이터 동기화는 체크리스트에서 **분리·우선**.
- 우선순위·리스크가 낮은 기능은 **묶어서** 관리 가능한 단위로 적는다. 중복 항목은 합친다.
- Section 5 체크리스트는 이후 `qa-tc-writer`가 TC로 풀어쓴다. TC 문체·컬럼 세부는 `qa-tc-writer` 스킬을 따른다.

## Shift-left (리뷰 전 선제 숙지)

개발 완료 후가 아니라 **기획·개발 리뷰 전에** QA가 스펙을 소화하고, 엣지·모호점을 들고 들어가는 것을 기본으로 한다.

1. **기획서 선수신** — PRD/스펙이 오면 구현·리뷰 대기 없이 `test-plan.md` 초안 작성 시작
2. **리뷰 전 숙지** — 기획+개발 리뷰 전에 Strategy Overview·체크리스트 초안·`확인 필요` 목록을 준비
3. **리뷰에서 엣지 논의** — 경계값·권한·빈 상태·실패/재진입·동기화 등 예외를 리뷰 안건으로 제시해 기대결과를 조기 확정
4. **리뷰 후 반영** — 합의·미결을 `test-plan.md`에 반영한 뒤 `qa-tc-writer`로 넘김

`test-plan.md`의 Strategy Overview·Quality Gates에 이 타이밍을 한 줄이라도 남긴다 (예: Entry에「기획/개발 리뷰 전 QA 숙지·엣지 논의」).

## 품질 기준 프레임

### ISTQB

- **테스트 프로세스**: 계획, 모니터링, 분석, 설계, 구현, 실행, 완료
- **테스트 설계 기법**: 블랙박스, 화이트박스, 경험 기반
- **테스트 유형**: 기능, 비기능, 구조적, 변경 관련(회귀)
- **리스크 기반 테스트**: 리스크 식별·완화

### ISO 25010

- **품질 특성**: 기능 적합성, 성능 효율성, 호환성, 사용성, 신뢰성, 보안, 유지보수성, 이식성
- 특성별로 **우선순위**만 매기고, 해당 기능에 쓸모 없으면 생략한다.
- **품질 게이트**: 단계별 진입/종료 기준

## 입력

가능하면 아래를 확보한다 (없으면 ClickUp/붙여넣은 스펙만으로도 진행, 경로 불명이면 한 번 묻거나 `docs/ways-of-work/plan/` 아래 합리적 폴더 사용).

1. Feature PRD: `/docs/ways-of-work/plan/{epic}/{feature}.md`
2. Technical Breakdown: `.../technical-breakdown.md`
3. Implementation Plan: `.../implementation-plan.md`
4. Project Plan: `.../project-plan.md`

## 출력

**파일 하나:**

`/docs/ways-of-work/plan/{epic-name}/{feature-name}/test-plan.md`

```markdown
# Test Plan: {기능명}

> Source / scope notes…

## 1. Strategy Overview
## 2. Design Techniques & Test Types
## 3. Quality Characteristics (ISO 25010 priorities)
## 4. Environment & Data
## 5. Test Issues Checklist
## 6. Quality Gates (Entry / Exit) & Smoke / Regression
## 7. Next step
- Section 5를 `qa-tc-writer`에 넘겨 TC CSV/시트 작성
```

분리 파일은 만들지 않는다. 기존에 쪼개진 파일이 있으면 `test-plan.md`로 병합하고 갱신을 중단한다.

---

## 섹션별 작성 가이드

### 1. Strategy Overview

- **Testing Scope**: In / Out / Deferred
- **Quality Objectives**: 측정 가능한 성공 기준
- **Risk Assessment**: 리스크·심각도·완화
- **Test Approach**: 리스크 기반·역할 매트릭스·자동화 범위 등
- **Shift-left**: 기획서 선수신 → 리뷰 전 숙지 → 기획/개발 리뷰에서 엣지·`확인 필요` 논의
- **우선순위**: 고리스크 기능을 먼저 나열

고우선 예시: 저장/수정/삭제, 서버 validation, 권한별 노출·제한, 계산 로직, 목록·상세·수정 동기화, 정산·수수료·금액, 상태값에 따른 CTA 활성/비활성

### 2. Design Techniques & Test Types

쓸 기법만 표로:

| Technique | 적용 |
|-----------|------|
| Equivalence Partitioning | … |
| Boundary Value Analysis | … |
| Decision Table | … |
| State Transition | … |
| Experience-Based | … |

테스트 유형: Functional / Non-Functional / Structural / Change-Related

### 3. ISO 25010 priorities

특성 × Critical/High/Medium/Low + 한 줄 Notes. 해당 없으면 Low 또는 생략.

### 4. Environment & Data

- 환경(qa/dev/host), 계정·역할
- 시드 데이터, 개인정보 주의
- 도구(Playwright 등), CI 필요 시만

### 5. Test Issues Checklist

실무용 체크리스트. GitHub 이슈로 쪼갤 필요는 없고, **검증 단위**를 `- [ ]` 로 적는다.

#### 반드시 검토할 예외·엣지 (기획 미언급이어도)

- [ ] **경계값** (길이, 날짜, 수량, max/min)
- [ ] **빈 입력** / 필수값 미입력
- [ ] **잘못된 형식** 데이터
- [ ] **중복** 데이터
- [ ] **권한·역할** 차이 (노출/차단/직접 URL)
- [ ] **데이터 없음** (empty)
- [ ] **저장 실패·서버 오류** / timeout
- [ ] **예기치 못한 사용자 행동** (연속 클릭, 뒤로가기, 중도 이탈)
- [ ] **화면 상태 변경 후 재진입** (모달 재오픈, 탭 복귀, 새로고침)
- [ ] **생성/수정/삭제 후 목록·상세 반영** (동기화)
- [ ] **생성 vs 수정** 초기값·Pre-fill·저장 조건이 다르면 **분리**

#### 입도 (체크리스트 → 이후 TC)

- 저리스크·저우선: **묶어도 됨**
- 고리스크(저장/수정/삭제, validation, 권한, 계산·금액, 동기화): **분리 유지**
- 중복 항목 제거·합칠 수 있으면 합침
- 기대결과 불명: 항목은 남기고 **`확인 필요`**

#### 테스트 레벨·유형 (해당 시)

- [ ] 전략 / 유닛 / 통합 / E2E(Playwright) / 성능 / 보안 / 접근성 / 회귀
- [ ] 기능·비기능·구조·변경 관련 우선순위
- [ ] 구현·환경·도구·타팀 의존성
- [ ] 커버리지 목표 (기능·리스크 100% 수용 기준 등 — 코드 커버리지는 팀 정책이 있을 때만)

### 6. Quality Gates & Smoke / Regression

- Entry / Exit
  - **Shift-left Entry (권장)**: 기획서 수신 후 QA 숙지 완료, 엣지·`확인 필요` 초안 준비 → 기획/개발 리뷰 참여
  - **구현 Entry**: 합의된 기대결과·미결 해소(또는 명시적 Deferred) 후 상세 TC/실행
- Smoke 시나리오 (짧고 치명 경로만)
- 최소 회귀 범위
- 실패 시 에스컬레이션 (필요 시)

### 7. Next step

- 기획/개발 리뷰 전: Section 5 초안 + `확인 필요`를 안건으로 들고 가기
- 리뷰 후: 합의·미결을 `test-plan.md`에 반영
- Section 5 → `qa-tc-writer` (AM-30520급 문체 + 레포 시트 레이아웃)
- 남은 `확인 필요`는 기획/개발에 확인 요청

---

## (선택) GitHub 이슈 템플릿

레포에서 GitHub 이슈로 추적할 때만 사용. 기본 산출물은 `test-plan.md`이다.

### 테스트 전략 이슈

```markdown
# Test Strategy: {기능명}

## 개요
{ISTQB/ISO 25010 기반 접근 요약}

## 설계 기법
- [ ] EP / BVA / Decision Table / State Transition / Experience-Based

## 테스트 유형
- [ ] Functional / Non-Functional / Structural / Regression

## ISO 25010 우선순위
- [ ] Functional Suitability: …
- [ ] …

## Quality Gates
- [ ] Entry / Exit / 임계값

## Labels
`test-strategy`, `istqb`, `iso25010`, `quality-gates`

## Estimate
2–3 SP
```

### Playwright 구현 이슈

```markdown
# Playwright Tests: {스토리/컴포넌트}

## 범위
…

## 설계 기법 / 테스트 유형
…

## 구현할 케이스
- [ ] Happy path / 오류 / 경계 / validation
- [ ] 성능·접근성·브라우저 (해당 시)

## 작업
- [ ] POM / fixture / 데이터 / 구현 / CI

## Labels
`playwright`, `e2e-test`

## Estimate
2–5 SP
```

### QA 검증 이슈

```markdown
# Quality Assurance: {기능명}

## Entry
- [ ] 구현 완료 / 유닛 통과 / 리뷰

## Exit
- [ ] 계획된 테스트 완료, Critical/High open = 0
- [ ] 성능·보안 기준 (해당 시)

## Labels
`quality-assurance`, `quality-gates`
```

---

## 성공 지표 (참고)

- 기능·고리스크 시나리오: 수용 기준/체크리스트 대비 누락 없이 추적
- Critical/High open defect = 0 후 릴리스
- 계획 문서 1개(`test-plan.md`)로 전략·체크리스트·게이트가 한곳에 있을 것

기획 사실에 충실하고, 예외·고리스크는 빠뜨리지 않으면서, 실무에서 관리 가능한 단위로 계획을 남긴다.