개념
앞 레슨에서 동등분할과 경계값 분석을 배웠다. 이 두 기법은 사실 더 큰 지도의 한 구역일 뿐이다. 이 레슨은 그 지도 전체를 펼쳐서, 이 모듈에서 앞으로 배울 기법들이 어디에 속하고 언제 쓰는지 미리 가늠하게 한다.
세 갈래 지도
| 갈래 | 무엇을 근거로 만드는가 | 이 모듈에서 다루는 기법 |
|---|---|---|
| 명세 기반 (블랙박스) | 요구사항·명세서. 코드는 안 본다 | 동등분할·경계값(완료), 상태전이·결정테이블, 유즈케이스, 페어와이즈, 분류 트리 |
| 구조 기반 (화이트박스) | 실제 코드의 구조 | 구문·분기·조건·MC-DC 커버리지 |
| 경험 기반 | 테스터의 경험과 직관 | 오류 추정, 체크리스트 |
동등분할·경계값은 "요구사항에 적힌 조건(나이 19~65세 등)"에서 출발했다 — 그래서 명세 기반이다. 코드를 한 줄도 안 보고도 쓸 수 있었다는 걸 기억해두면 이후 기법을 분류하기 쉬워진다.
무엇을 기준으로 고르는가
기법은 "더 좋은 기법"이 따로 있는 게 아니라, 상황에 맞는 기법이 있다.
- 명세서가 명확하고 테스트 가능한 조건이 있는가? → 명세 기반 기법부터 시작한다. 이 모듈 레슨 3~6이 여기 속한다.
- 코드에 접근할 수 있고, "이 코드가 실제로 실행됐는지" 확인해야 하는가? → 구조 기반 기법을 쓴다. 레슨 7에서 다룬다.
- 명세가 불명확하거나 시간이 부족한데, 과거에 자주 터졌던 유형의 결함이 의심되는가? → 경험 기반 기법으로 빠르게 채운다. 레슨 8에서 다룬다.
실무에서는 한 기법만 쓰지 않는다. 동등분할로 큰 그룹을 나누고, 그 경계를 경계값으로 찌르고, 변수가 여러 개면 페어와이즈로 조합을 줄이고, 시간이 남으면 경험 기반으로 빈틈을 훑는 식으로 겹쳐서 쓴다. 이 모듈 마지막 레슨(TC 설계 종합)에서 이 조합을 실제로 연습한다.
지도를 미리 보는 이유
지도를 모른 채 기법을 하나씩 배우면 "이건 언제 쓰는 거지?"를 매번 새로 고민하게 된다. 먼저 지도를 보면, 새 기법을 배울 때마다 "아, 이건 명세 기반 쪽에서 조합 문제를 해결하는 기법이구나" 하고 위치를 잡을 수 있다. 지도 자체를 외울 필요는 없다 — 이후 레슨을 읽으며 이 표로 계속 돌아와도 된다.
실무에서 왜 필요한가
면접이나 실무 리뷰에서 "왜 이 기법을 쓰셨나요?"라는 질문에 "그냥 배운 거라서요"는 답이 안 된다. "명세가 명확했고 조합해야 할 변수가 많아서 페어와이즈를 썼습니다"처럼 상황과 기법을 연결해 설명할 수 있어야 설득력이 생긴다. 이 지도가 그 설명의 뼈대다. 또한 실무에서 시간은 항상 부족하다 — 어떤 상황에 어떤 기법이 가장 효율적인지 판단하는 능력 자체가 시니어와 주니어를 가르는 기준 중 하나다.
실습 과제
과제 1 — 상황에 기법 갈래 매칭하기 (10분)
다음 세 상황 각각에 어떤 갈래(명세 기반/구조 기반/경험 기반)가 가장 먼저 필요할지 고르고, 이유를 한 줄로 적는다.
- 신규 기능의 요구사항 문서가 상세히 있고, 아직 코드는 없다.
- 이미 배포된 코드에 대해 "정말 모든 분기가 테스트됐는지" 감사받아야 한다.
- 요구사항 문서가 거의 없이 "일단 화면부터 보고 테스트해달라"는 요청을 받았고, 릴리즈까지 하루 남았다.
과제 2 — 기법 조합 설계하기 (10분)
"할인 쿠폰 적용" 기능에 대해 최소 두 가지 갈래의 기법을 조합한다면 어떤 순서로, 어떤 기법을 쓸지 계획을 2~3문장으로 적어본다. (아직 각 기법을 자세히 배우기 전이니 "동등분할로 시작해서 조합이 많으면 …로 줄인다" 정도의 큰 그림으로 충분하다.)
자가 체크리스트
- 명세 기반·구조 기반·경험 기반 세 갈래를 "무엇을 근거로 만드는가"로 구분할 수 있다
- 동등분할·경계값 분석이 왜 명세 기반에 속하는지 설명할 수 있다
- 상황(명세 유무, 코드 접근, 시간 압박)에 따라 어느 갈래부터 시작할지 판단할 수 있다
- 실무에서는 한 기법만이 아니라 여러 기법을 조합해서 쓴다는 것을 안다
흔한 실수
- 한 기법을 배우면 그것만 계속 쓴다. 동등분할을 배웠다고 모든 상황에 동등분할만 적용하면, 조합이 많은 상황이나 코드 검증이 필요한 상황에서는 비효율적이다.
- 기법 선택 이유를 설명하지 못한다. "왜 이 기법을 썼나요?"에 답하지 못하면, 리뷰나 면접에서 그 케이스의 근거 자체가 흔들린다.
- 구조 기반 기법을 명세 기반처럼 오해한다. 구조 기반은 코드를 봐야 쓸 수 있다 — 명세만 보고 "이 코드의 분기를 다 커버했다"고 말할 수 없다.
참고 자료
- ISTQB Foundation Level Syllabus — Test Techniques — 명세/구조/경험 기반 분류의 표준 출처
- Lee Copeland, A Practitioner's Guide to Software Test Design — 기법 선택 전략을 다룬 실무 고전