테스트 코드, 어디까지 검증해야 할까?

테스트 코드를 작성하다 보면 검증 범위에 대한 확신이 서지 않을 때가 있다. 이렇게 당연한 것도 테스트해야 할까? a를 검증했는데 b까지 검증할 필요가 있을까? 이런 고민은 테스트를 감으로 작성하고 있기 때문에 생긴다.

테스트 설계 기법을 활용하면 “무엇을, 왜 검증하는가”에 대한 근거가 생기고, 누락 없이 체계적으로 테스트 목록을 도출할 수 있다. 이 글에서는 대표적인 블랙박스 테스트 설계 기법들을 쇼핑몰 주문/결제 도메인의 요구사항에 적용해, 테스트 목록을 뽑아내는 과정을 보여준다.

---

테스트 케이스란

본격적으로 기법을 다루기 전에, 테스트 케이스가 무엇인지 짚고 넘어가자.

테스트 케이스는 소프트웨어가 특정 조건에서 기대대로 동작하는지 검증하기 위한 테스트의 최소 단위다. 사전 조건, 입력값, 실행 절차, 기대 결과로 구성된다.

쇼핑몰에서 “주문 수량은 1개 이상이어야 한다”는 요구사항을 검증하는 테스트 케이스를 예로 들면 다음과 같다.

항목	내용
사전 조건	상품이 등록되어 있고, 재고가 충분하다
입력값	주문 수량: 0
실행 절차	주문 수량에 0을 입력하고 주문 버튼을 클릭한다
기대 결과	주문이 실패하고, “수량은 1개 이상이어야 합니다” 오류가 발생한다

하나의 테스트 케이스는 하나의 조건만 검증해야 한다. 하나의 테스트에서 여러 가지를 동시에 검증하면 테스트가 실패했을 때 어떤 조건 때문에 실패한 건지 원인을 파악하기 어렵다. 예를 들어, “주문 수량이 0이면 실패하고, 음수여도 실패한다”를 하나의 테스트에 넣는 것보다 각각 별도의 테스트 케이스로 분리하는 것이 좋다.

테스트 설계 기법은 이 테스트 케이스를 체계적으로 도출하기 위한 방법론이다. 기법 없이 작성하면 “생각나는 대로” 만들게 되어 누락이 생기기 쉽고, 기법을 적용하면 논리적 근거를 가지고 빠짐없이 케이스를 도출할 수 있다.

---

1. 동등 분할 (Equivalence Partitioning)

입력 데이터를 동일한 처리가 예상되는 그룹(파티션)으로 나누고, 각 그룹에서 대표값 하나만 테스트하는 기법이다. 같은 파티션 내의 값은 동일하게 동작한다고 가정하기 때문에, 모든 값을 테스트하지 않아도 효율적으로 검증 범위를 확보할 수 있다.

요구사항

주문 수량은 1개 이상 99개 이하여야 한다.

기법 적용

이 요구사항에서 파티션을 나누면 다음과 같다.

파티션	범위	유효 여부
파티션 1	0 이하	무효
파티션 2	1 ~ 99	유효
파티션 3	100 이상	무효

도출된 테스트 목록

각 파티션에서 대표값을 하나씩 선택한다.

TC	입력값	기대 결과	근거
TC-01	수량: -1	주문 실패	무효 파티션 1의 대표값
TC-02	수량: 5	주문 성공	유효 파티션의 대표값
TC-03	수량: 150	주문 실패	무효 파티션 2의 대표값

포인트는 대표값 선택이 아니라 파티션을 올바르게 나누는 것이다. 요구사항을 잘못 해석해서 파티션을 잘못 나누면 결함을 놓칠 수 있다.

---

2. 경계값 분석 (Boundary Value Analysis)

동등 분할의 경계 지점에서 결함이 집중적으로 발생한다는 경험적 사실에 기반한 기법이다. < 를 써야 하는데 <= 를 쓴다거나, 99까지 허용해야 하는데 100까지 허용하는 식의 “1 차이” 실수는 실무에서 가장 흔한 결함 유형 중 하나다. 경계값 분석은 이런 실수를 잡아내는 데 효과적이다.

요구사항

주문 수량은 1개 이상 99개 이하여야 한다.

기법 적용

동등 분할에서 나눈 파티션의 경계 지점을 찾는다.

경계	무효 값	경계값 (유효)
하한	0	1
상한	100	99

도출된 테스트 목록

TC	입력값	기대 결과	근거
TC-04	수량: 0	주문 실패	하한 경계 바로 바깥
TC-05	수량: 1	주문 성공	하한 경계값
TC-06	수량: 99	주문 성공	상한 경계값
TC-07	수량: 100	주문 실패	상한 경계 바로 바깥

동등 분할로 파티션을 나누고, 경계값 분석으로 경계를 집중 검증하는 것이 가장 기본적인 조합이다. 이 두 기법만 제대로 적용해도 입력값 관련 결함의 상당 부분을 잡아낼 수 있다.

---

3. 결정 테이블 테스팅 (Decision Table Testing)

먼저 결정 테이블이 무엇인지부터 짚어보자. 결정 테이블은 조건(Condition)과 그에 따른 동작(Action)의 관계를 표 형태로 정리한 것이다. 행에는 조건과 동작을, 열에는 가능한 조합(규칙)을 나열한다. 이렇게 테이블로 만들면 “이 조건 조합일 때 어떤 동작을 해야 하지?“를 한눈에 볼 수 있다.

결정 테이블 테스팅은 이 테이블의 각 규칙을 하나의 테스트 케이스로 만들어 검증하는 기법이다. 조건이 복잡하게 얽혀 있을 때 누락 없이 모든 조합을 검증할 수 있다.

요구사항

할인 정책은 회원 등급과 쿠폰 보유 여부에 따라 결정된다.

• VIP 회원: 기본 10% 할인, 쿠폰 적용 시 20% 할인
• 일반 회원: 기본 할인 없음, 쿠폰 적용 시 10% 할인
• 비회원: 기본 할인 없음, 쿠폰 적용 시 5% 할인

기법 적용

요구사항을 결정 테이블로 정리한다.

규칙	회원 등급	쿠폰 보유	→ 할인율
R1	VIP	O	20%
R2	VIP	X	10%
R3	일반	O	10%
R4	일반	X	0%
R5	비회원	O	5%
R6	비회원	X	0%

도출된 테스트 목록

테이블의 각 규칙이 곧 하나의 테스트 케이스가 된다.

TC	회원 등급	쿠폰	상품 가격	기대 결제 금액	근거
TC-08	VIP	O	50,000원	40,000원	R1: 20% 할인
TC-09	VIP	X	50,000원	45,000원	R2: 10% 할인
TC-10	일반	O	50,000원	45,000원	R3: 10% 할인
TC-11	일반	X	50,000원	50,000원	R4: 할인 없음
TC-12	비회원	O	50,000원	47,500원	R5: 5% 할인
TC-13	비회원	X	50,000원	50,000원	R6: 할인 없음

결정 테이블의 진짜 가치는 테스트 목록 도출이 아니라 테이블을 만드는 과정에 있다. 조건 조합을 빠짐없이 나열하다 보면 요구사항에서 정의하지 않은 케이스, 모순되는 규칙이 자연스럽게 드러난다.

---

4. 상태 전이 테스팅 (State Transition Testing)

시스템이 상태를 가지고, 특정 이벤트에 의해 상태가 전환되는 경우에 사용하는 기법이다. 상태 전이 다이어그램을 그리고, 유효한 전이와 무효한 전이를 모두 테스트한다.

요구사항

주문은 다음 상태를 가진다: 주문완료, 결제완료, 배송중, 배송완료, 취소됨, 반품처리중

• 주문완료 후 결제하면 결제완료가 된다.
• 결제완료 후 배송을 시작하면 배송중이 된다.
• 배송중 배송이 완료되면 배송완료가 된다.
• 결제완료 상태에서만 주문 취소가 가능하다.
• 배송완료 상태에서만 반품 요청이 가능하다.

기법 적용

요구사항을 상태 전이 다이어그램으로 정리한다.

주문 상태 전이 다이어그램

그리고 모든 상태 × 이벤트 조합을 상태 전이 테이블로 만든다. 여기서 유효한 전이뿐 아니라 무효한 전이까지 확인하는 것이 핵심이다.

현재 상태	결제	배송시작	배송완료	주문취소	반품요청
주문완료	→ 결제완료	불가	불가	불가	불가
결제완료	불가	→ 배송중	불가	→ 취소됨	불가
배송중	불가	불가	→ 배송완료	불가	불가
배송완료	불가	불가	불가	불가	→ 반품처리중
취소됨	불가	불가	불가	불가	불가
반품처리중	불가	불가	불가	불가	불가

도출된 테스트 목록

유효 전이 테스트

TC	현재 상태	이벤트	기대 결과
TC-14	주문완료	결제	결제완료로 전이
TC-15	결제완료	배송시작	배송중으로 전이
TC-16	배송중	배송완료	배송완료로 전이
TC-17	결제완료	주문취소	취소됨으로 전이
TC-18	배송완료	반품요청	반품처리중으로 전이

무효 전이 테스트

TC	현재 상태	이벤트	기대 결과
TC-19	배송중	주문취소	전이 거부 (취소 불가)
TC-20	취소됨	배송시작	전이 거부 (배송 불가)
TC-21	배송완료	주문취소	전이 거부 (취소 불가)
TC-22	주문완료	반품요청	전이 거부 (반품 불가)

상태 전이 테스팅에서 놓치기 쉬운 것이 무효 전이다. 유효한 흐름만 테스트하면 “배송 중인 주문을 취소할 수 있는” 같은 결함을 놓칠 수 있다. 상태 전이 테이블에서 “불가”로 표시된 칸들이 모두 무효 전이 테스트 후보다.

---

5. 유스케이스 테스팅 (Use Case Testing)

사용자의 실제 사용 시나리오 흐름을 기반으로 테스트를 설계하는 기법이다. 단위 기능이 아닌 처음부터 끝까지의 전체 흐름을 검증하며, 기본 흐름뿐 아니라 대안 흐름과 예외 흐름까지 테스트한다.

요구사항

사용자는 상품을 장바구니에 담고, 주문 후 결제할 수 있다.

• 기본 흐름: 상품 선택 → 장바구니 담기 → 주문 → 결제 → 주문 확인
• 대안 흐름: 재고 부족 시 입고 알림 등록 가능
• 예외 흐름: 결제 실패 시 주문은 결제 대기 상태를 유지한다
• 예외 흐름: 장바구니가 비어 있으면 주문할 수 없다

기법 적용

요구사항에서 기본 흐름, 대안 흐름, 예외 흐름을 분리한다.

흐름 유형	시나리오
기본 흐름	상품 선택 → 장바구니 담기 → 주문 → 결제 → 주문 확인
대안 흐름	상품 선택 → 재고 부족 → 입고 알림 등록
예외 흐름 1	장바구니 담기 → 주문 → 결제 실패 → 결제 대기 상태 유지
예외 흐름 2	빈 장바구니 → 주문 시도 → 주문 거부

도출된 테스트 목록

TC	시나리오	사전 조건	기대 결과
TC-23	정상 주문 및 결제	상품 재고 충분, 결제 수단 유효	결제 성공, 주문 상태: 결제완료
TC-24	재고 부족 시 알림 등록	상품 재고 0	장바구니 담기 실패, 입고 알림 등록 성공
TC-25	결제 실패	상품 재고 충분, 결제 수단 무효	결제 실패, 주문 상태: 주문완료 유지
TC-26	빈 장바구니 주문	장바구니에 상품 없음	주문 거부

유스케이스 테스팅은 개별 기법으로 검증하기 어려운 전체 흐름의 정합성을 확인하는 데 강점이 있다. 단, 실패 시 원인 파악이 어려울 수 있으므로 단위 테스트와 함께 사용하는 것이 좋다.

---

어떤 기법을 언제 쓸까

기법은 단독이 아니라 조합해서 사용한다. 하나의 기능을 테스트할 때도 성격에 따라 다른 기법을 적용하면 된다.

검증 대상	적합한 기법	예시
입력값에 범위가 있을 때	동등 분할 + 경계값 분석	주문 수량 범위 검증
여러 조건 조합으로 동작이 결정될 때	결정 테이블	회원 등급별 할인 정책
상태와 전이가 있을 때	상태 전이	주문→결제→배송→완료 흐름
전체 시나리오 검증이 필요할 때	유스케이스	장바구니부터 결제까지 전체 흐름

예를 들어 쇼핑몰 주문 기능이라면, 주문 수량에는 경계값 분석을, 등급/쿠폰 조합에는 결정 테이블을, 주문→결제→배송 흐름에는 상태 전이를, 전체 구매 시나리오에는 유스케이스 테스팅을 적용할 수 있다.

“이걸 테스트해야 하나?“라는 고민이 들 때, 기법을 기준으로 판단하면 감이 아닌 근거로 답할 수 있다. 기법이 도출하라고 하는 케이스는 작성하고, 도출되지 않는 케이스는 과감히 생략하면 된다.