디시전 테이블 테스트란 복수의 조건과 그 조합을 표 형식으로 정리하여 테스트 케이스를 설계하는 기법입니다. 로그인 처리·권한 관리·할인 로직 등 복수 조건이 얽히는 업무 규칙 검증에서 특히 효과를 발휘합니다.
디시전 테이블을 사용하면 복수 조건의 조합을 빠짐없이·중복 없이 정리할 수 있어 「그 조합을 테스트하는 것을 잊었다」는 문제를 근본적으로 방지할 수 있습니다.
📌 이런 분께 추천합니다
- 디시전 테이블 테스트를 처음 배우는 QA 엔지니어·개발자
- 복수 조건의 조합 테스트를 어떻게 정리하면 좋을지 고민하는 분
- 업무 로직·권한 관리의 테스트를 체계화하고 싶은 분
- ISTQB 학습에서 디시전 테이블을 이해하고 싶은 분
✅ 이 글을 읽으면 얻을 수 있는 것
- 디시전 테이블의 개념과 작성법을 알 수 있다
- 실무에서 자주 나오는 로그인·권한 관리에의 적용 방법을 알 수 있다
- pytest의 parametrize와 조합하여 자동 테스트에 활용할 수 있다
👤 이 글을 쓴 사람
QA 엔지니어·테스트 자동화 엔지니어로서 15년 이상의 실무 경험을 가진 Yoshi가 집필. 디시전 테이블은 업무 로직의 복잡한 테스트 설계에서 매일 활용하는 기법입니다. 구현 코드는 GitHub에 공개 중입니다: github.com/YOSHITSUGU728/automated-testing-portfolio
「조건이 2개 이상 얽히면 어떤 조합을 테스트해야 할지 모르게 된다」——이런 고민은 QA 엔지니어라면 누구나 경험하는 것입니다.
- 조건이 늘어날수록 테스트 케이스가 폭발적으로 증가한다
- 어떤 조합을 테스트했는지·하지 않았는지가 모호해진다
- 「그 패턴, 테스트하지 않았다」는 누락이 발생한다
디시전 테이블 테스트는 이런 문제를 해결하는 기법입니다. 이 글에서는 개념부터 구체적인 작성법·pytest 응용까지 한 번에 해설합니다.
📌 결론
- 조건을 세로축·케이스를 가로축으로 표 형식으로 정리하여 전체 조합을 일람화하는 테스트 설계 기법
- 조건 2개=4패턴,3개=8패턴이 기본이지만 불가능한 조합은 삭제하여 효율화할 수 있다
- pytest의
parametrize에 전달하면 설계한 표를 그대로 자동 테스트로 변환할 수 있다
디시전 테이블 테스트란?
디시전 테이블 테스트는 「조건(입력)」과 「액션(기대 결과)」의 관계를 표 형식으로 정리하는 테스트 설계 기법입니다. 조건의 조합을 체계적으로 정리할 수 있기 때문에 복잡한 업무 로직 테스트에서 널리 사용됩니다. 「결정표 테스트」라고도 불립니다.
예를 들어 「사용자 종별(일반/프리미엄)」과 「쿠폰 유무(있음/없음)」라는 2개 조건이 얽힌 할인 처리를 테스트하는 경우 디시전 테이블을 사용하면 4패턴(2×2)을 빠짐없이 정리할 수 있습니다.
| 비교 항목 | 디시전 테이블 없음 | 디시전 테이블 있음 |
|---|---|---|
| 조합 관리 | 머릿속·목록으로 관리 | 표로 한눈에 전체 패턴 파악 |
| 누락 위험 | 높음(빠짐이 발생하기 쉬움) | 낮음(표로 망라성 보증) |
| 팀 공유 | 구두 설명 필요·모호해지기 쉬움 | 표를 그대로 공유·리뷰하기 쉬움 |
| 자동 테스트로의 변환 | 설계와 코드가 분리되기 쉬움 | parametrize에 그대로 사용 가능 |
디시전 테이블의 구조와 작성법
디시전 테이블은 「조건부」와 「액션부」의 2가지 파트로 구성됩니다.
📋 디시전 테이블의 기본 구조
| 💡 읽는 방법 포인트
| ||||||||||||||||||||||||||||||
| 파트 | 내용 | 예시 |
|---|---|---|
| 조건부(Conditions) | 테스트하는 입력 조건 | ID가 올바른가? / 비밀번호가 올바른가? |
| 액션부(Actions) | 조건 조합에 대응하는 기대 결과 | 로그인 성공 / 에러 표시 |
디시전 테이블의 장점
- 조건 조합을 빠짐없이 정리할 수 있다:전체 패턴이 표에 나열되어 누락을 방지
- 테스트 케이스의 누락을 방지할 수 있다:「감각적 테스트」에서 「망라적 테스트」로 변화
- 팀 리뷰가 쉽다:표 형식으로 QA와 개발이 공통 인식을 가질 수 있다
- 자동 테스트로 변환하기 쉽다:pytest의
parametrize에 그대로 전달 가능
작성 순서
| 스텝 | 내용 |
|---|---|
| STEP 1 | 사양서에서 「조건」을 추출한다(Yes/No로 답할 수 있는 형태로 만든다) |
| STEP 2 | 조건 수에서 전체 패턴 수를 계산한다(Yes/No 조건 n개 = 2ⁿ패턴) |
| STEP 3 | 각 패턴에 대응하는 액션(기대 결과)을 기입한다 |
| STEP 4 | 실제로는 발생하지 않는 조합(불가능한 케이스)을 제외하여 삭감한다 |
실례①:로그인 처리의 디시전 테이블
가장 자주 사용되는 예로서 로그인 처리의 디시전 테이블을 작성해 봅니다. 조건은 「ID가 올바른가」「비밀번호가 올바른가」의 2가지입니다.
| 조건 / 액션 | 케이스1 | 케이스2 | 케이스3 | 케이스4 |
|---|---|---|---|---|
| 조건①:ID가 올바른가 | Yes | Yes | No | No |
| 조건②:비밀번호가 올바른가 | Yes | No | Yes | No |
| 액션:로그인 성공 | ✅ | ❌ | ❌ | ❌ |
| 액션:에러 메시지 표시 | ❌ | ✅ | ✅ | ✅ |
이 테이블에서 4가지 테스트 케이스가 명확하게 도출됩니다. 케이스2·3·4는 모두 에러가 되지만 에러 메시지 내용(ID가 틀림 / 비밀번호가 틀림 / 둘 다 틀림)이 다른 경우도 있으므로 3건 모두 실시하는 것을 추천합니다.
실례②:할인 로직의 디시전 테이블(조건 3가지)
조건이 3가지가 되면 패턴은 8가지로 늘어납니다. 「회원 종별(프리미엄)」「쿠폰 사용」「구매 금액(30,000원 이상)」의 3개 조건으로 할인율을 결정하는 로직을 예시로 합니다.
| 조건 / 액션 | C1 | C2 | C3 | C4 | C5 | C6 | C7 | C8 |
|---|---|---|---|---|---|---|---|---|
| 프리미엄 회원 | Y | Y | Y | Y | N | N | N | N |
| 쿠폰 있음 | Y | Y | N | N | Y | Y | N | N |
| 30,000원 이상 | Y | N | Y | N | Y | N | Y | N |
| → 할인율 | 30% | 25% | 20% | 15% | 15% | 10% | 5% | 0% |
이 테이블을 한눈에 보면 C4(프리미엄·쿠폰 없음·30,000원 미만=15%)와 C5(비프리미엄·쿠폰 있음·30,000원 이상=15%)가 같은 할인율임을 알 수 있습니다. 이처럼 「같은 결과가 되는 케이스」를 발견하여 테스트 수를 줄이는 것도 디시전 테이블의 효과입니다.
pytest에의 응용
디시전 테이블로 설계한 테스트 케이스는 pytest의 @pytest.mark.parametrize에 그대로 전달할 수 있습니다. 다음은 로그인 처리의 디시전 테이블을 pytest로 구현한 예시입니다.
먼저 테스트 대상 로그인 함수를 준비합니다.
def login(user_id: str, password: str) -> dict:
"""로그인 처리(샘플)"""
VALID_ID = "test_user"
VALID_PW = "secret_pass"
if user_id == VALID_ID and password == VALID_PW:
return {"success": True, "message": "로그인 성공"}
elif user_id != VALID_ID:
return {"success": False, "message": "ID가 존재하지 않습니다"}
else:
return {"success": False, "message": "비밀번호가 올바르지 않습니다"}다음으로 디시전 테이블의 4케이스를 그대로 파라미터로 구현합니다.
import pytest
# 디시전 테이블의 4케이스를 그대로 파라미터화
@pytest.mark.parametrize("user_id, password, expected_success, expected_msg", [
# 케이스1:ID 올바름·PW 올바름 → 성공
("test_user", "secret_pass", True, "로그인 성공"),
# 케이스2:ID 올바름·PW 틀림 → 실패
("test_user", "wrong_pass", False, "비밀번호가 올바르지 않습니다"),
# 케이스3:ID 틀림·PW 올바름 → 실패
("wrong_user", "secret_pass", False, "ID가 존재하지 않습니다"),
# 케이스4:ID 틀림·PW 틀림 → 실패
("wrong_user", "wrong_pass", False, "ID가 존재하지 않습니다"),
])
def test_login(user_id, password, expected_success, expected_msg):
result = login(user_id, password)
assert result["success"] == expected_success
assert result["message"] == expected_msg실행 결과 샘플
$ pytest test_login.py -v
========================= test session starts ==========================
collected 4 items
test_login.py::test_login[test_user-secret_pass-True-로그인 성공] PASSED [ 25%]
test_login.py::test_login[test_user-wrong_pass-False-비밀번호가 올바르지 않습니다] PASSED [ 50%]
test_login.py::test_login[wrong_user-secret_pass-False-ID가 존재하지 않습니다] PASSED [ 75%]
test_login.py::test_login[wrong_user-wrong_pass-False-ID가 존재하지 않습니다] PASSED [100%]
========================== 4 passed in 0.12s ===========================⚠️ 디시전 테이블 테스트에서 자주 발생하는 실패 패턴 4선
실무에서 디시전 테이블을 작성할 때 빠지기 쉬운 실패를 소개합니다.
① 조건을 Yes/No로 변환하지 않고 테이블을 작성한다
디시전 테이블의 조건은 반드시 「Yes/No(참/거짓)」로 답할 수 있는 형태로 만들어야 합니다. 「사용자 종별」처럼 복수의 값을 갖는 조건은 「프리미엄 회원인가?(Yes/No)」로 변환하고 나서 사용합니다. 조건을 정리하지 않고 테이블을 작성하면 패턴 계산이 어긋나 누락이 발생합니다.
② 불가능한 조합을 삭제하는 것을 잊어 테스트가 너무 많아진다
예를 들어 「쿠폰 적용 완료」와 「쿠폰 코드 미입력」은 동시에 발생할 수 없는 조합입니다. 이런 불가능한 케이스를 삭제하지 않으면 테스트 수가 필요 이상으로 늘어납니다. 테이블을 작성한 후 반드시 「현실에서 발생할 수 있는가?」를 확인하고 나서 불가능한 케이스를 제외하세요.
③ 같은 결과가 되는 케이스를 무분별하게 통합하여 에러의 차이를 놓친다
액션(기대 결과)이 같아도 에러 메시지 내용이나 후속 처리가 다른 경우가 있습니다. 「둘 다 에러가 된다」만을 보고 케이스를 통합하면 「ID가 틀림」과 「비밀번호가 틀림」으로 다른 메시지가 나와야 하는데 놓쳐버립니다. 통합 전에 기대 결과의 상세까지 확인하세요.
④ 조건이 6개 이상이 되어 테이블이 너무 거대해진다
조건이 6개가 되면 64패턴,7개에서는 128패턴이 됩니다. 이 규모가 되면 디시전 테이블만으로는 관리하기 어렵습니다. 조건이 5개 이상인 경우에는 페어와이즈 테스트와 조합하여 패턴 수를 줄이거나 조건을 그룹으로 나누어 복수의 테이블로 분할하는 것을 검토하세요.
FAQ
Q. 디시전 테이블은 언제 사용해야 하나요?
디시전 테이블은 복수의 조건이 조합되어 결과가 결정되는 처리의 테스트 설계에 적합합니다. 예를 들어 로그인 인증·권한 관리·요금 계산·할인 로직 등입니다. 조건이 1개만인 경우에는 동등 분할이나 경계값 분석으로 더 간단하게 설계할 수 있습니다.
Q. 디시전 테이블과 페어와이즈 테스트의 차이는?
디시전 테이블은 「모든 조건의 조합」을 정리하는 기법입니다. 반면 페어와이즈 테스트는 「조건의 쌍을 최소 1번씩 테스트한다」는 것으로 테스트 케이스 수를 줄이는 기법입니다. 조건이 5개 이상이 되는 경우에는 디시전 테이블 단독으로는 패턴 수가 폭발하기 때문에 페어와이즈 테스트와의 병용이 실무에서는 자주 이루어집니다.
Q. 디시전 테이블과 동등 분할·경계값 분석은 어떻게 사용 구분하나요?
동등 분할·경계값 분석은 「1개의 입력 필드의 값의 범위」를 검증할 때 사용합니다. 디시전 테이블은 「복수의 조건의 조합」을 검증할 때 사용합니다. 실무에서는 양쪽을 조합하는 경우가 많아 폼의 각 필드에는 동등 분할·경계값 분석을 사용하면서 업무 로직에는 디시전 테이블을 사용하는 구성이 일반적입니다.
Q. 조건이 Yes/No의 2값이 아닌 경우에는 어떻게 하면 되나요?
「회원 등급:일반·실버·골드」처럼 3값 이상인 경우에는 「실버 이상인가?(Yes/No)」「골드인가?(Yes/No)」처럼 Yes/No 형식의 조건으로 분해합니다. 또는 3값의 경우에는 3열(일반·실버·골드)로 세로로 나열하는 형식의 테이블도 유효합니다.
Q. ISTQB에서 디시전 테이블은 어느 정도 이해하면 합격할 수 있나요?
ISTQB Foundation Level에서는 「디시전 테이블의 읽는 방법과 기본적인 작성법」이 출제됩니다. 이 글의 로그인 처리 예시(조건 2개·4패턴)레벨을 확실히 이해하고 있으면 합격 라인입니다. 조건 수에서 패턴 수를 계산할 수 있는 것(조건 n개=2ⁿ)도 파악해 두세요.
📖 관련 글
실무에서는 디시전 테이블을 스프레드시트로 작성하고 리뷰 후에 pytest의 parametrize로 변환하는 워크플로우가 자주 사용됩니다. 설계와 구현을 분리할 수 있기 때문에 QA팀과 개발팀 양쪽이 리뷰하기 쉬워지는 장점이 있습니다.
📋 이 글의 정리
- 디시전 테이블은 조건(세로축)×케이스(가로축)로 전체 조합을 일람화하는 기법
- 조건 n개=2ⁿ패턴(Yes/No 조건의 경우)이 기본으로 불가능·중복 케이스를 삭제하여 테스트 수를 최적화할 수 있다
- 로그인·권한 관리·할인 로직 등 복수 조건이 얽히는 업무 규칙에 특히 유효
- pytest parametrize와의 궁합이 최상으로 설계 테이블을 그대로 자동 테스트로 변환할 수 있다
- 조건이 5개 이상이 되면 페어와이즈 테스트와의 조합을 검토한다
디시전 테이블은 「머릿속에서 막연하게 생각하고 있던 조합」을 가시화하여 누락을 제로에 가깝게 만드는 기법입니다. 먼저 가까운 로그인 처리나 권한 체크에 2〜3개 조건의 테이블을 만드는 것부터 시작해 보세요.

