ISTQB FL Chapter 4 실무 적용 – 설계 기법은 기술이 아니라 전략이다

케이스가 아니라 논리를 설계하는 것, 그게 진짜 테스트 설계다

---

1️⃣ 이 글은 왜 쓰는가

ISTQB Foundation Level Chapter 4는 "테스트 설계 기법"을 다루는 파트입니다.
단순히 Equivalence Partitioning, Boundary Value Analysis, Decision Table 등의
기법 이름을 외우는 챕터로 오해받기 쉽습니다.

하지만 이 챕터는 **"테스트라는 논리를 어떻게 구성할 것인가"**를 묻는 파트입니다.
실무에선 테스트 케이스가 많다고 좋은 게 아닙니다.
“최소한의 케이스로 최대의 결함을 잡아내는 전략”이 중요합니다.

---

2️⃣ 설계 기법이 필요한 이유

기법의 목적 / 설명

테스트 설계의 체계화	감에 의존한 케이스 작성이 아니라, 근거 있는 구조화
누락 방지	논리 조합, 조건 누락 등 사각지대 방지
반복성 보장	다른 QA가 동일 기법으로 케이스 작성 가능
테스트 범위 최적화	필요 이상으로 많거나 적은 테스트 방지

---

3️⃣ 실무 시나리오 적용 예시

✅ 시나리오 1: 기능이 단순하지만 결함이 반복 발생

[상황]
회원가입 입력 폼: 이름, 생년월일, 성별, 약관 동의
테스트는 "입력되고, 다음으로 넘어가는지"만 확인

[문제]

• 생년월일 유효성 검사 빠짐
• 약관 체크 시 로직 누락
• 성별 항목이 API로 전달되지 않음

[기법 적용]

• Equivalence Partitioning → 유효/무효 입력 구간 분리
• Boundary Value Analysis → 생년월일 경계값 (1900~현재 기준)
• Checklist Based Test → 모든 필드가 API에 포함되는지 확인

[결과]
기능 테스트는 10개 미만 케이스로 완성
→ 결함 탐지율 향상 + 리소스 절감

---

✅ 시나리오 2: 복잡한 요금 계산 로직 테스트

[상황]
요금 계산은 나이, 등급, 이용 시간, 할인 코드 등에 따라 다르게 계산됨

[문제]

• QA는 “모든 조합은 불가능하다”며 감으로 케이스 작성
• 주요 조합 결함 누락 발생

[기법 적용]

• Decision Table → 규칙별 조합 정리 후 케이스 추출
• Cause-Effect Graphing → 인과 관계 기반 테스트 설계
• Pairwise Testing → 주요 입력값 최소 조합으로 최적화

[결과]
필수 조합 24개 도출, 테스트 커버리지 3배 향상
→ QA의 설득력 확보 + 개발과 커뮤니케이션 개선

---

✅ 시나리오 3: 모바일 UI 테스트 케이스 산정

[상황]
로그인, 검색, 장바구니 등 모바일 UI 동작 테스트

[문제]

• 테스트 케이스 기준이 명확하지 않음
• OS 버전, 화면 해상도별 테스트 범위 혼란

[기법 적용]

• State Transition → 기능 흐름 기반 테스트 설계
• Classification Tree Method → 디바이스 분류 기준 명확화
• Exploratory Testing → 제약조건 내 자유 탐색 강화

[결과]
UI 흐름 케이스 12개, 디바이스 조합 6개로 압축
→ 결함 탐지율은 그대로, 테스트 시간 40% 단축

---

4️⃣ 챕터별 테스트 설계 기법 요약

기법 / 특징 / 실무 활용 포인트

동등 분할 (EP)	입력 값의 그룹화	유효/무효 조건 나누기
경계값 분석 (BVA)	경계 조건 집중	나이/금액/시간 제한 등
결정 테이블	복잡한 조건 분기	할인 조건, 정책 로직
상태 전이	상태 변화 기반 테스트	로그인/장바구니/예약 등
분류 트리	조합 간소화	다양한 입력 조건 분류
탐색적 테스트	경험 기반 탐색	자동화 어려운 UI 등
원인-결과 그래프	논리적 상관 관계 정리	정책 변화, 규칙 계산 로직

---

5️⃣ 설계 기법은 기술이 아니라, “논리의 언어”다

잘못된 접근 / 바른 해석

“EP는 그냥 유효/무효를 나누는 거야”	→ 유효/무효 구간을 나누는 기준이 무엇인가를 정의하는 기법
“BVA는 숫자 경계만 보면 되는 거지”	→ 경계가 실질적 리스크 포인트인지 판단할 수 있어야 함
“결정 테이블은 복잡한 거야”	→ 복잡한 구조를 단순하게 만들기 위한 도구

---

✅ 마무리 요약

• 테스트 설계는 단순히 케이스를 만드는 게 아니라,
  논리와 전략으로 품질을 끌어올리는 기술입니다.
• Equivalence Partitioning, BVA, Decision Table 등의 기법은
  ‘기법’이 아닌 ‘언어’로 이해하고 실전에 녹여야 진짜 쓰입니다.
• 감에 의존한 테스트는 흔들립니다.
  기법에 기반한 테스트는 재현성과 설득력을 가집니다.

---

🔗 추천하는 글

→ [ISTQB FL Chapter 3 실무 적용 – 실행 없이도 결함을 잡는다]
→ [ISTQB FL Chapter 5 실무 적용 – 계획 없는 품질은 없다]