명세 기반 기법 (5) 분류 트리 기법과 TESTONA

개념

동등분할(레슨 1)이 입력값 하나를 그룹으로 나눴다면, 분류 트리 기법(Classification Tree Method) 은 테스트 대상 전체를 여러 관점(분류, Classification) 으로 나누고, 각 관점을 다시 구체적인 값들(클래스, Class) 로 쪼개는 걸 나무(tree) 구조로 시각화 한다. 원리는 동등분할과 비슷하지만, 여러 관점을 한눈에 정리하고 빠진 게 없는지 확인하는 데 특히 강하다.

먼저 비유 하나 — 여행 짐 싸기

여행 짐을 쌀 때 생각나는 대로 가방에 넣으면 꼭 하나를 빠뜨린다. 반면 "옷 / 세면도구 / 전자기기 / 서류" 로 칸을 먼저 나눠두면, 가방을 닫기 전에 네 칸을 훑기만 해도 빠진 게 눈에 띈다. "어? 서류 칸이 비어 있네 — 여권은?"

분류 트리가 하는 일이 정확히 이것이다. 테스트 케이스를 생각나는 대로 적으면 반드시 한 관점이 통째로 빠진다. 먼저 칸(분류)을 만들고, 그다음에 칸을 채우면(클래스) 빈 칸이 시각적으로 드러난다. 기법의 가치는 "많이 만들어내는 것"이 아니라 "빠진 것이 눈에 보이게 만드는 것" 에 있다.

용어 세 개만 정확히 잡고 간다

이 기법에서 헷갈리는 건 거의 전부 용어를 섞어 쓰는 데서 온다. 세 층으로 나뉜다.

2층과 3층을 구분하는 간단한 방법이 있다. 분류는 "질문"이고 클래스는 "답"이다.

• "가입 경로가 무엇인가?" → 분류
• "이메일 / 카카오 / 애플" → 그 질문에 대한 답들, 즉 클래스

이 문장 하나만 기억하면 트리가 무너지지 않는다. "빈 값"은 답이므로 클래스이고, "아이디 유효성"은 질문이므로 분류다. 답과 질문이 같은 층에 섞여 있으면 그건 트리가 아니라 그냥 목록이다.

트리를 그리는 5단계 — 손으로 따라 그려보기

"회원가입 폼"을 대상으로 실제로 한 단계씩 그려본다. 종이나 화이트보드에 같이 그려보면 훨씬 빨리 익는다.

1단계 — 테스트 대상과 범위를 못 박는다

가장 먼저 하는 일은 트리의 뿌리에 무엇을 적을지 정하는 것 이다. 이게 곧 범위 선언이다.

회원가입 폼

"회원가입"이라고만 적으면 범위가 흐릿하다. 가입 완료 후의 환영 메일까지 포함인가? 관리자 승인 절차는? 뿌리에 무엇을 적느냐에 따라 이후 모든 가지가 달라지므로, 여기서 포함/제외를 한 줄로 적어두는 습관 이 좋다.

대상: 회원가입 폼 (가입 버튼을 누른 직후 응답까지) 제외: 가입 후 환영 메일 발송, 관리자 승인

2단계 — 분해(classification): 관점부터 뽑는다

여기가 이 기법의 핵심이자 가장 어려운 단계다. 아직 값은 생각하지 않는다. "무엇에 따라 이 기능의 동작이 달라지는가"만 묻는다.

회원가입 폼
├── 가입 경로
├── 약관 동의
└── 이메일 인증

값을 나중으로 미루는 게 중요하다. 값부터 떠올리면 "생각나는 값"이 있는 관점만 남고, 떠오르지 않는 관점은 아예 존재조차 하지 않게 된다. 관점을 먼저 다 깔아놓아야 "이 칸은 값이 뭐지?"라는 질문이 생긴다.

3단계 — 각 분류를 클래스로 쪼갠다

이제 각 관점 아래 값을 채운다. 이 단계에서 하는 일이 정확히 레슨 1의 동등분할 이다. 같은 결과가 나올 값끼리 묶고, 대표값 하나만 남긴다.

회원가입 폼
├── 가입 경로
│   ├── 이메일 직접 가입
│   ├── 카카오 소셜 로그인
│   └── 애플 소셜 로그인
├── 약관 동의
│   ├── 필수만 동의
│   ├── 필수 + 선택 전체 동의
│   └── 필수 미동의
└── 이메일 인증
    ├── 즉시 인증 완료
    ├── 만료 후 인증(24시간 초과)
    └── 인증하지 않음

이때 한 분류 안의 클래스들은 서로 겹치지 않고(배타적), 합치면 전부를 덮어야(완전) 한다. "즉시 / 만료 후 / 안 함"은 이 조건을 만족한다. 반면 "빠름 / 느림 / 24시간 초과"는 겹친다 — 24시간 초과도 "느림"에 들어가기 때문이다. 트리를 그리다 이런 겹침이 보이면 그 자체가 좋은 신호다. 아직 팀이 그 개념을 정확히 정의하지 않았다는 뜻이다.

4단계 — 조합 규칙(combination)을 트리에 표시한다

여기가 초보자가 가장 자주 건너뛰는 단계이고, 그래서 트리가 "예쁜 그림"으로 끝나는 이유다. 모든 클래스가 자유롭게 조합되는 건 아니다. 불가능한 조합과 강제되는 조합을 트리 옆에 적어둔다.

회원가입 폼
├── 가입 경로
│   ├── 이메일 직접 가입          ← 이메일 인증 분류가 적용됨
│   ├── 카카오 소셜 로그인        ← [제약] 이메일 인증 단계 없음
│   └── 애플 소셜 로그인          ← [제약] 이메일 인증 단계 없음
│                                    + 이메일 가리기(릴레이 주소) 가능
├── 약관 동의
│   ├── 필수만 동의
│   ├── 필수 + 선택 전체 동의
│   └── 필수 미동의               ← [기대] 항상 가입 차단. 다른 분류와 무관
└── 이메일 인증
    ├── 즉시 인증 완료
    ├── 만료 후 인증(24시간 초과)
    └── 인증하지 않음

제약을 적어두면 두 가지가 동시에 해결된다.

• 불가능한 조합을 만들다 시간을 버리지 않는다. "카카오 가입 + 이메일 인증 만료"는 존재할 수 없는 케이스다.
• 기대 결과가 미리 정해진 조합이 드러난다. "필수 미동의"는 나머지가 무엇이든 차단이어야 한다. 이런 조합은 하나만 확인해도 충분하다.

5단계 — 표로 펼쳐 테스트 케이스로 만든다

트리는 아직 테스트 케이스가 아니다. 마지막에 클래스를 가로로 조합해 표로 펼친다.

3번 행의 이메일 인증 칸이 — 인 것에 주목하자. 4단계에서 "필수 미동의는 다른 분류와 무관"이라고 적어뒀기 때문에, 그 조합은 하나로 접을 수 있다. 제약을 표시해두면 케이스 수가 줄어든다.

여기서 몇 개의 행을 만들지는 분류 트리가 정하지 않는다. 전부 조합하면 3 × 3 × 3 = 27개지만, 앞 레슨의 페어와이즈 를 적용하면 9개 안팎으로 줄어든다.

분류 트리는 "무엇을 테스트할지 빠짐없이 정리하는 도구"이고, 그중 무엇을 실제로 조합할지는 페어와이즈 같은 다른 기법이 정한다.

두 기법은 경쟁 관계가 아니라 앞뒤 공정 이다. 트리가 재료를 다 꺼내놓고, 페어와이즈가 그중 무엇을 요리할지 고른다.

분류를 뽑아내는 질문 목록

2단계가 어렵다는 사람이 많다. 관점은 떠올리는 게 아니라 질문 목록으로 긁어내는 것 이다. 아래 질문을 순서대로 던지면 대부분의 화면에서 5~7개가 나온다.

마지막 두 줄이 실무에서 가장 자주 통째로 빠지는 관점이다. 명세가 대개 정상 흐름의 한 번 만 기술하기 때문이다. 트리를 그릴 때 "실패" 가지와 "이후" 가지가 아예 없다면, 그건 트리가 완성된 게 아니라 명세를 그대로 옮겨 적은 것이다.

계층이 두 단계를 넘어갈 때

클래스 아래에 다시 분류가 붙을 수 있다. 어떤 클래스를 골랐을 때만 의미가 생기는 관점이 있기 때문이다.

결제
└── 결제 수단
    ├── 신용카드
    │   └── 카드사              ← "신용카드"일 때만 의미 있는 분류
    │       ├── 국내 카드
    │       └── 해외 카드
    ├── 간편결제
    │   └── 연동 상태
    │       ├── 이미 연동됨
    │       └── 최초 연동
    └── 무통장 입금

이렇게 그리면 "간편결제인데 카드사를 고른다" 같은 무의미한 조합이 구조적으로 생기지 않는다. 다만 깊이가 3단계를 넘어가면 사람이 한눈에 못 읽는다. 깊어지면 트리를 나눈다 — "결제 수단 선택"과 "카드 결제 상세"를 별도 트리로 쪼개는 편이 거의 항상 낫다.

동등분할·페어와이즈와 무엇이 다른가

세 기법은 서로 이어져 있지만 하는 일이 다르다. 이 표가 이 레슨에서 가장 오래 기억할 부분이다.

페어와이즈의 약점 칸이 핵심이다. 페어와이즈 도구는 넣어준 인자 안에서만 최적의 조합을 찾는다. 인자를 하나 통째로 안 넣었다면, 도구는 그 사실을 절대 알려주지 않는다. 30개를 6개로 줄여준 화면을 보면 오히려 "체계적으로 다 커버했다"는 착각 까지 얹힌다. 분류 트리는 그 앞 단계에서 "인자 목록 자체가 맞는가"를 눈으로 검사하는 장치다.

그래서 언제 이 기법이 특히 유리한가

빠진 조합을 한눈에 확인할 수 있다는 것이 다른 기법 대비 결정적인 강점이다. 같은 정보를 표로 적어놓은 경우와 비교해보면 차이가 분명하다.

표로 정리하면 이렇게 된다.

행이 세 줄뿐이니 깔끔해 보인다. 바로 그게 함정이다. 표는 "적혀 있는 것"만 보여주고, 적히지 않은 것에 대해서는 아무 신호도 주지 않는다. "만 14세 미만 가입"이라는 관점이 빠져 있어도 표는 여전히 완결돼 보인다.

트리는 다르다. 가지가 시각적으로 배치되어 있으면 비어 보이는 자리 가 생긴다. 가입 경로 가지가 셋인데 나이 관련 가지가 하나도 없으면, 훑는 순간 "어? 미성년자 가입은 어디 들어가지?"라는 질문이 자연스럽게 떠오른다. 사람의 눈은 목록의 누락은 잘 못 잡지만 그림의 비대칭은 아주 잘 잡는다.

특히 유리한 상황을 정리하면 이렇다.

반대로 불리한 상황 도 분명하다. 인자가 10개를 넘어가면 트리가 화면을 넘어가 시각적 강점이 사라진다. 상태 흐름이 중요한 기능(레슨 3의 상태 전이)이나, 조건과 결과의 대응이 핵심인 규칙(결정 테이블)은 애초에 다른 기법의 영역이다. 트리는 "관점의 목록"에 강하고 "순서와 흐름"에는 약하다.

TESTONA — 도구가 해주는 일과 못 해주는 일

TESTONA는 분류 트리 기법을 구현한 독일산 상용 도구로, 트리를 그래픽으로 그리고 조합을 자동으로 생성해준다. 자동차·임베디드 산업처럼 테스트 설계 과정 자체를 문서로 남기고 감사받아야 하는 분야 에서 특히 많이 쓰인다 — 트리 구조가 "우리가 어떤 관점을 고려했는지"를 그대로 보여주는 문서가 되기 때문이다.

도구의 역할을 정확히 나눠보면 이렇다.

오른쪽 칸이 전부 판단 이라는 점을 보자. 도구는 왼쪽만 한다. 즉 도구를 산다고 누락이 사라지지 않는다. 이 기법의 본체는 "체계적으로 빠짐없이 쪼개는 사고방식" 자체이고, 도구는 그 사고를 빠르고 예쁘게 기록해주는 보조 장치다.

도구가 없을 때 — 손으로 그리는 실무적 대안

현실의 대부분 팀은 TESTONA 라이선스가 없다. 그래도 전혀 문제가 되지 않는다. 효과의 90%는 "관점을 먼저 나눠 그린다"는 행위 자체에서 나오기 때문이다.

가장 실용적인 조합은 "화이트보드로 그리고, 확정된 트리를 텍스트로 옮겨 저장소에 넣는 것" 이다. 그리는 단계에서는 손이 빠른 도구가 좋고, 남기는 단계에서는 변경 이력이 보이는 형식이 좋다. 텍스트 트리는 Pull Request의 diff에 그대로 나타나므로 "이번 스프린트에 어떤 관점이 추가됐는지"가 리뷰에서 보인다.

한 가지만 지키면 어떤 도구든 효과는 같다. 먼저 분류를 다 깔고, 그다음에 클래스를 채우고, 마지막에 조합을 만든다. 이 순서를 지키지 않고 값부터 적기 시작하면 어떤 비싼 도구를 써도 결과는 그냥 목록이다.

사례 연구 — 화이트보드 30분이 찾아낸 빠진 가지

한 커머스 팀의 실제와 비슷한 장면이다. 쿠폰 적용 기능을 개편하는 스프린트였고, QA는 이미 명세를 보고 테스트 케이스 40여 개를 만들어둔 상태였다.

1단계 — 케이스가 아니라 트리부터 그려보기로 한다. 케이스 목록을 스프레드시트로 공유하면 리뷰에서 아무도 끝까지 읽지 않는다는 걸 경험으로 알고 있었다. 대신 화이트보드에 관점만 먼저 적었다.

쿠폰 적용
├── 쿠폰 종류
├── 회원 등급
├── 결제 수단
└── 장바구니 구성

2단계 — 클래스를 채운다. 개발자 두 명과 기획자가 같이 붙어 15분 만에 채워졌다.

쿠폰 적용
├── 쿠폰 종류
│   ├── 정률(10%)
│   ├── 정액(3,000원)
│   └── 무료배송
├── 회원 등급
│   ├── 일반
│   └── VIP
├── 결제 수단
│   ├── 카드
│   ├── 간편결제
│   └── 무통장
└── 장바구니 구성
    ├── 단일 상품
    ├── 복수 상품
    └── 쿠폰 제외 상품 포함

3단계 — 팀이 트리를 훑는다. 여기서 기획자가 이렇게 말했다.

"이거 전부 결제 누르기 전 얘기네요. 결제 끝난 다음은요?"

케이스 40개를 훑을 때는 아무도 못 했던 지적이다. 목록에서는 "없는 것"이 보이지 않지만, 가지 네 개가 나란히 놓인 그림에서는 전부 같은 성격이라는 게 눈에 띄었다.

4단계 — 가지를 하나 추가한다.

└── 결제 이후 처리
    ├── 전체 취소
    ├── 부분 취소(일부 상품만)
    └── 반품 후 재주문

5단계 — 새 가지에서 케이스를 뽑는다. 여기서 실제 결함이 두 개 나왔다.

첫 번째는 금액이 어긋나는 정산 결함이었고, 결제 후에만 재현되므로 명세 기반 케이스로는 끝까지 안 나왔을 가능성이 높다.

무엇이 이 발견을 만들었는가. 새로운 지식이 아니다. 부분 취소가 있다는 건 팀 전원이 알고 있었다. 다만 "관점을 나란히 놓고 보는 30분"이 없었을 뿐이다. 분류 트리가 하는 일이 정확히 이것이다 — 아는 것을 빠뜨리지 않게 만드는 것.

좋은 분류 트리의 조건 네 가지

그린 트리가 쓸 만한지 스스로 점검하는 기준이다.

1. 각 분류 안의 클래스가 겹치지 않고 전부를 덮는가. 겹치면 중복 케이스가 나오고, 덮지 못하면 구멍이 생긴다.
2. 모든 분류가 실제로 동작을 바꾸는가. 결과에 아무 영향이 없는 관점을 넣으면 조합만 배로 늘어난다. "화면 배경색"은 대개 분류가 아니다.
3. 불가능한 조합이 표시되어 있는가. 4단계를 건너뛴 트리는 반드시 존재하지 않는 케이스를 만들어낸다.
4. 한 화면에 들어오는가. 이 기법의 강점은 시각성이다. 스크롤해야 다 보이는 트리는 이미 강점을 잃었으니 쪼갠다.

실무에서 왜 필요한가

팀 리뷰에서 가장 큰 힘을 발휘한다

관점이 3~4개를 넘어가는 복잡한 화면에서는 표 하나로 모든 조건을 관리하기 버거워진다. 분류 트리는 팀 리뷰에서 특히 힘을 발휘한다 — 트리를 화면에 띄워놓고 "여기 빠진 관점 있나요?"라고 물으면, 표를 훑어볼 때보다 훨씬 빠르게 답이 나온다.

이건 QA의 능력 문제가 아니라 정보 구조의 문제 다. 케이스 목록 40줄을 리뷰에 띄우면 개발자와 기획자는 3분 뒤에 노트북을 본다. 가지 다섯 개짜리 트리를 띄우면 30초 만에 자기 영역에 대해 말하기 시작한다. 리뷰 참여를 끌어내는 것 자체가 이 기법의 실무적 효용이다.

도메인 지식이 흩어져 있을 때 그것을 모은다

앞의 사례에서 빠진 가지를 찾아낸 사람은 QA가 아니라 기획자였다. 실무에서 누락은 보통 아무도 모르는 것 이 아니라 각자 알고 있지만 아무도 꺼내지 않은 것 이다. 트리는 각자가 자기 영역의 빈칸을 알아볼 수 있는 형태로 정보를 배치한다.

규제 산업에서는 설계 근거 자체가 산출물이다

자동차, 의료기기, 항공처럼 규제가 강한 도메인(부록에서 다룰 표준들)에서는 "테스트 설계가 체계적이었다"는 걸 문서로 증명해야 한다. 여기서 요구되는 건 케이스 수가 아니라 "어떤 관점을 고려했고, 왜 그 조합을 골랐는가" 다. 분류 트리는 그 질문에 그림 하나로 답한다. TESTONA가 자동차 업계에서 자리를 잡은 이유도 기능보다 이 문서성에 가깝다.

회귀 테스트 범위를 정할 때의 지도가 된다

기능이 변경되면 "어디까지 다시 테스트할 것인가"를 정해야 한다. 트리가 있으면 판단이 쉬워진다. 변경이 특정 가지 안에서 끝나는지, 아니면 여러 가지에 걸치는지가 눈에 보이기 때문이다. "결제 수단 가지만 바뀌었으니 그 가지 조합만 재실행" 같은 결정을 근거와 함께 내릴 수 있다.

인수인계와 온보딩 비용을 줄인다

새로 합류한 QA에게 케이스 300개를 넘기면 무엇이 중요한지 알 수 없다. 트리 한 장을 먼저 주면 제품을 보는 관점 이 먼저 전달된다. 케이스는 그 관점의 결과물이라 나중에 읽어도 된다. 이건 뒤에서 배울 테스트 케이스 설계 종합(레슨 9)에서 말하는 "중복과 누락을 줄이는 구조"와도 이어진다.

채용시장에서의 위치

분류 트리 기법은 ISTQB 계열 자격 시험에서 명세 기반 기법의 하나로 등장하고, 자동차 소프트웨어 QA 채용 공고에서는 TESTONA가 도구 이름으로 직접 언급되기도 한다. 다만 일반 웹·앱 QA 면접에서 "TESTONA 써봤나요?"를 묻는 경우는 드물다. 대신 이렇게 묻는다.

• "복잡한 화면의 테스트 케이스를 어떻게 설계하시나요?"
• "테스트 케이스에서 누락을 어떻게 방지하시나요?"

두 질문 다 이 레슨의 내용이 그대로 답이 된다. "먼저 관점을 나누고, 각 관점을 값으로 쪼갠 뒤, 조합은 페어와이즈로 줄입니다. 관점을 트리로 그려두면 리뷰에서 빠진 가지를 찾기 쉽습니다." — 도구 이름을 대는 것보다 이렇게 절차로 답하는 쪽 이 훨씬 좋은 인상을 준다. 기법을 외운 사람이 아니라 방법을 가진 사람으로 보이기 때문이다.

실습 과제

과제 1 — 분류 트리 그리기 (12분)

"게시글 작성" 기능에 대해 분류 트리를 그린다. 최소 3개의 관점(예: 제목 길이, 첨부파일 개수, 공개 범위)을 정하고, 각 관점마다 클래스를 2~3개씩 적는다. 텍스트로 들여쓰기 구조로 표현해도 된다.

본문의 "분류를 뽑아내는 질문 목록" 을 순서대로 적용해보는 것이 목적이다.

게시글 작성
├── 제목 길이
│   ├── 정상(1~50자)
│   ├── 빈 값
│   └── 최대 초과(51자)
├── 첨부파일
│   ├── 없음
│   ├── 1개
│   └── 최대 개수 초과
├── 공개 범위
│   ├── 전체 공개
│   ├── 팔로워만
│   └── 비공개
├── 작성 중 실패
│   ├── 저장 중 네트워크 끊김
│   └── 저장 버튼 연속 2회 클릭
└── 작성 이후
    ├── 수정
    └── 삭제

과제 2 — 빠진 관점 찾기 (8분)

아래 분류 트리를 보고, 빠졌을 법한 관점 하나를 찾아 추가한다.

파일 업로드
├── 파일 형식
│   ├── 이미지(JPG/PNG)
│   └── 지원 안 하는 형식
└── 업로드 방식
    ├── 드래그 앤 드롭
    └── 파일 선택 버튼

과제 3 — 조합 규칙 표시하기 (10분)

과제 2에서 완성한 트리에 불가능한 조합 과 결과가 미리 정해진 조합 을 표시해본다. 최소 두 개를 찾아 트리 옆에 [제약] 또는 [기대]로 적는다.

과제 4 — 트리를 표로 펼치기 (12분)

본문의 "회원가입 폼" 트리를 표로 펼쳐, 테스트 케이스 6~9개를 만든다. 조건은 두 가지다.

• 모든 클래스가 최소 한 번씩 등장해야 한다
• 4단계에서 표시한 제약을 위반하는 행이 없어야 한다

다 만든 뒤 스스로 물어본다. "27개 전부를 만들지 않은 근거를 한 문장으로 말할 수 있는가?"

과제 5 — 실제 업무 화면으로 그려보기 (선택, 15분)

지금 담당하는 제품에서 조건이 복잡한 화면 하나를 골라 트리를 그린다. 목표는 완성이 아니라 분류 5개를 채우는 것 까지다.

다 그린 뒤 개발자나 기획자에게 5분만 보여주고 "빠진 가지 있나요?"라고 물어본다. 이 질문이 얼마나 잘 통하는지 직접 확인하는 게 이 과제의 진짜 목적이다.

자가 체크리스트

• 분류 트리의 "분류(Classification)"와 "클래스(Class)"를 "질문과 답"으로 구분해 설명할 수 있다
• 테스트 대상을 나무 구조로 직접 그릴 수 있다
• 트리를 그리는 5단계(대상 → 분류 → 클래스 → 조합 규칙 → 표)를 순서대로 적용할 수 있다
• 값보다 관점을 먼저 뽑아야 하는 이유를 설명할 수 있다
• 한 분류 안의 클래스가 겹치지 않고 전부를 덮어야 하는 이유를 안다
• 불가능한 조합·결과가 정해진 조합을 트리에 표시할 수 있다
• 분류 트리와 페어와이즈가 왜 경쟁이 아니라 앞뒤 공정인지 설명할 수 있다
• 페어와이즈만 쓸 때 생기는 "인자 누락은 못 잡는다"는 한계를 설명할 수 있다
• 표보다 트리가 "빠진 관점 찾기"에 유리한 이유를 예를 들어 설명할 수 있다
• 도구(TESTONA)가 해주는 일과 사람이 해야 하는 일을 구분할 수 있다
• 도구가 없어도 화이트보드·마인드맵·스프레드시트로 같은 효과를 낼 수 있음을 안다
• 이 기법이 불리한 상황(인자가 너무 많을 때, 흐름이 핵심일 때)을 댈 수 있다

흔한 실수

• 관점과 클래스를 뒤섞는다. "아이디 유효성"은 관점이고 "빈 값"은 그 아래 클래스다. 이 둘을 같은 층위에 섞어 그리면 트리가 아니라 그냥 목록이 된다. 헷갈리면 "질문인가 답인가"를 물어본다.
• 값부터 적기 시작한다. 떠오르는 값이 있는 관점만 트리에 남고, 떠오르지 않는 관점은 존재조차 하지 않게 된다. 분류를 다 깔고 나서 클래스를 채운다.
• 트리를 다 그려놓고 조합을 만들지 않는다. 트리는 "무엇을 테스트할지"를 정리하는 단계일 뿐, 실제 테스트 케이스는 클래스들을 조합해야 나온다.
• 조합 규칙(제약)을 표시하지 않는다. 존재할 수 없는 조합을 만들어 시간을 쓰거나, 하나로 접을 수 있는 조합을 다 실행하게 된다.
• 정상 흐름 관점만으로 트리를 채운다. "실패했을 때"와 "그 이후(취소·환불·수정)" 가지가 없으면 트리가 아니라 명세를 옮겨 적은 것이다. 실무 결함은 이 두 가지에 몰린다.
• 관점을 너무 잘게 쪼개 트리가 감당 안 되게 커진다. 관점이 5~6개를 넘어가면 오히려 표(결정 테이블)나 페어와이즈 조합 단계로 넘어가거나, 트리를 둘로 나눈다.
• 결과에 영향을 주지 않는 관점을 넣는다. 조합만 배로 늘어난다. "이 값이 바뀌면 기대 결과가 달라지는가?"에 답할 수 없으면 그건 분류가 아니다.
• 도구가 있어야 할 수 있는 기법이라고 생각한다. 종이와 펜으로 5분이면 그린다. 효과의 대부분은 "관점을 먼저 나눈다"는 행위에서 나온다.
• 트리를 그려놓고 혼자만 본다. 이 기법의 최대 효용은 리뷰다. 그린 트리를 팀에 보여주지 않으면 시각화의 가치를 절반 이상 버리는 셈이다.
• 한 번 그린 트리를 갱신하지 않는다. 기능이 바뀌면 가지도 바뀐다. 낡은 트리는 "이미 다 고려했다"는 착각만 남긴다.

참고 자료

• ISTQB Glossary — Classification Tree Method — 분류 트리 기법의 공식 정의
• TESTONA — 분류 트리 기법을 구현한 도구 소개 페이지
• Grochtmann & Grimm, "Classification Trees for Partition Testing" (1993) — 분류 트리 기법의 원논문. 동등분할을 다차원으로 확장한 것이라는 출발점이 정리되어 있다
• 이 모듈 레슨 1(동등분할·경계값 분석) — 각 분류를 클래스로 쪼갤 때 그대로 쓰는 기법
• 이 모듈 레슨 5(페어와이즈와 PICT) — 트리로 정리한 인자를 조합 단계에서 줄이는 기법
• 이 모듈 레슨 9(TC 설계 종합) — 여러 기법으로 만든 케이스에서 중복과 누락을 줄이는 방법