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

개념

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

나무 구조로 그리기

로그인 화면을 분류 트리로 그려본다.

로그인 화면
├── 아이디 유효성
│   ├── 유효한 형식
│   ├── 빈 값
│   └── 형식 오류
├── 비밀번호 유효성
│   ├── 일치
│   ├── 불일치
│   └── 빈 값
└── 디바이스
    ├── PC
    └── 모바일

세 개의 관점(아이디 유효성, 비밀번호 유효성, 디바이스)이 있고, 각 관점 아래 구체적인 값(클래스)들이 있다. 이 구조를 표로 펼치면 각 클래스를 조합해 테스트 케이스를 만들 수 있다 — 이때 모든 조합을 다 쓸 수도 있고, 앞 레슨에서 배운 페어와이즈로 줄일 수도 있다. 분류 트리는 "무엇을 테스트할지 빠짐없이 정리하는 도구"이고, 그중 무엇을 실제로 조합할지는 페어와이즈 같은 다른 기법이 정한다 — 두 기법은 경쟁 관계가 아니라 보완 관계다.

왜 굳이 나무로 그리는가

동등분할을 표로만 정리하면, 관점이 여러 개일 때 "내가 관점을 빠뜨리지 않았나?"를 확인하기 어렵다. 나무 구조는 가지가 몇 개 있는지 한눈에 보이기 때문에, 빠진 관점이 있으면 시각적으로 어색해 보인다. 예를 들어 위 로그인 트리에서 "계정 잠금 여부"라는 관점이 빠져 있다면, 트리를 훑어보다가 "어? 계정이 잠긴 상태는 어디 들어가지?"라는 질문이 자연스럽게 떠오른다. 이게 표보다 트리가 나은 지점이다.

TESTONA

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

실무에서 왜 필요한가

관점이 3~4개를 넘어가는 복잡한 화면에서는 표 하나로 모든 조건을 관리하기 버거워진다. 분류 트리는 팀 리뷰에서 특히 힘을 발휘한다 — 트리를 화면에 띄워놓고 "여기 빠진 관점 있나요?"라고 물으면, 표를 훑어볼 때보다 훨씬 빠르게 답이 나온다. 규제 산업(자동차, 의료기기 — 부록에서 다룰 표준들)에서는 "테스트 설계가 체계적이었다"는 걸 문서로 증명해야 하는데, 분류 트리 자체가 그 증거 자료가 된다.

실습 과제

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

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

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

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

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

자가 체크리스트

분류 트리의 "관점(Classification)"과 "클래스(Class)"를 구분해 설명할 수 있다
테스트 대상을 나무 구조로 직접 그릴 수 있다
분류 트리와 페어와이즈가 왜 경쟁이 아니라 보완 관계인지 설명할 수 있다
표보다 트리가 "빠진 관점 찾기"에 유리한 이유를 설명할 수 있다

흔한 실수

관점과 클래스를 뒤섞는다. "아이디 유효성"은 관점이고 "빈 값"은 그 아래 클래스다. 이 둘을 같은 층위에 섞어 그리면 트리가 아니라 그냥 목록이 된다.
트리를 다 그려놓고 조합을 만들지 않는다. 트리는 "무엇을 테스트할지"를 정리하는 단계일 뿐, 실제 테스트 케이스는 클래스들을 조합해야 나온다.
관점을 너무 잘게 쪼개 트리가 감당 안 되게 커진다. 관점이 5~6개를 넘어가면 오히려 표(결정 테이블)나 페어와이즈 조합 단계로 넘어가는 게 낫다.

참고 자료

ISTQB Glossary — Classification Tree Method — 분류 트리 기법의 공식 정의
TESTONA — 분류 트리 기법을 구현한 도구 소개 페이지