테스트 설계 기법 지도 — 전략적으로 기법 고르기

개념

앞 레슨에서 동등분할과 경계값 분석을 배웠다. 이 두 기법은 사실 더 큰 지도의 한 구역일 뿐이다. 이 레슨은 그 지도 전체를 펼쳐서, 이 모듈에서 앞으로 배울 기법들이 어디에 속하고 언제 쓰는지 미리 가늠하게 한다.

이 레슨에는 새로운 기법이 나오지 않는다. 대신 기법을 고르는 능력을 다룬다. 실무에서 주니어와 시니어를 가르는 지점은 "몇 개의 기법을 아는가"가 아니라 "지금 이 상황에 무엇을 꺼낼지 30초 안에 정할 수 있는가"다.

쉬운 비유 — 세 명의 검사관

새로 지은 건물을 검사한다고 해보자. 검사관이 세 명 온다.

• 설계도 검사관 은 도면을 손에 들고 온다. "여기 비상구가 두 개로 표시돼 있는데 실제로 두 개입니까?" 도면에 적힌 것을 하나씩 대조한다. 도면이 부실하면 이 사람은 할 일이 없다.
• 골조 검사관 은 벽을 뜯고 들어간다. 도면에 없는 배선, 실제로 연결 안 된 파이프를 본다. 하지만 벽을 뜯을 권한과 시간이 없으면 못 한다.
• 베테랑 검사관 은 도면도 벽도 안 보고 건물을 한 바퀴 돈다. "이 건축사가 지은 건물은 지하 배수가 늘 문제더라." 20년치 경험이 근거다. 근거가 문서화돼 있지 않으니 다른 사람이 그대로 따라 하긴 어렵다.

세 사람은 경쟁 관계가 아니다. 보는 곳이 다르다. 소프트웨어 테스트 설계 기법의 세 갈래가 정확히 이 셋이다. 그리고 좋은 검사는 셋을 다 부르되, 예산 안에서 순서와 비중을 정하는 것이다.

세 갈래 지도

동등분할·경계값은 "요구사항에 적힌 조건(나이 19~65세 등)"에서 출발했다 — 그래서 명세 기반이다. 코드를 한 줄도 안 보고도 쓸 수 있었다는 걸 기억해두면 이후 기법을 분류하기 쉬워진다.

세 갈래의 성격을 조금 더 뜯어보면 이렇게 정리된다.

"놓치는 것" 줄이 가장 중요하다. 구조 기반 커버리지 100%를 달성해도 "구현되지 않은 요구사항"은 절대 발견되지 않는다. 없는 코드에는 커버리지가 측정되지 않기 때문이다. 반대로 명세 기반만 하면 "명세에 없는데 개발자가 임의로 넣은 분기"를 못 본다. 두 갈래는 서로의 사각지대를 메운다 — 이것이 세 갈래를 굳이 구분해서 배우는 실질적 이유다.

판단 흐름도 — 무엇부터 물어야 하는가

기법은 "더 좋은 기법"이 따로 있는 게 아니라, 상황에 맞는 기법이 있다. 상황을 판별하는 질문은 순서가 있다. 위에서부터 차례로 답해 내려가면 된다.

1. 판정 기준이 되는 명세·수용 기준이 있는가?
   ├─ 예 →  ▶ 명세 기반부터 시작 (2번으로)
   └─ 아니오 → 4번으로

2. 그 명세에서 무엇이 복잡한가?
   ├─ 입력값 하나의 범위        → 동등분할·경계값        (레슨 1)
   ├─ 조건 여러 개가 맞물린 규칙 → 결정테이블            (레슨 3)
   ├─ 시간에 따라 상태가 변함   → 상태전이              (레슨 3)
   ├─ 사용자 흐름·시나리오      → 유즈케이스            (레슨 4)
   ├─ 옵션 조합이 폭발함        → 페어와이즈            (레슨 5)
   ├─ 봐야 할 "관점"이 여러 개  → 분류 트리             (레슨 6)
   └─ 상태 모델이 크고 반복됨   → 모델 기반 테스트      (레슨 11)

3. 코드에 접근할 수 있고, "실제로 실행됐는지"를 증명해야 하는가?
   ├─ 예 → ▶ 구조 기반을 명세 기반 위에 덧댄다
   │        · 얼마나 덜 실행됐나  → 구문·분기·조건 커버리지 (레슨 7)
   │        · 최소 몇 개 필요한가 → 순환 복잡도·경로 테스트 (레슨 10)
   └─ 아니오 → 4번으로

4. 시간이 부족하거나 명세가 부실한가?
   └─ 예 → ▶ 경험 기반으로 채운다 (레슨 8)
            · 과거 결함 이력이 있다 → 오류 추정
            · 반복되는 점검 항목이다 → 체크리스트

5. 어느 경로로 왔든 마지막 질문: 빈틈이 남았는가?
   → 입력·처리·출력 관점으로 훑고 중복을 정리한다 (레슨 9)

이 흐름도에서 3번이 "예/아니오"가 아니라 "덧댄다"로 되어 있는 점을 눈여겨보자. 구조 기반은 명세 기반을 대신하는 기법이 아니다. 명세 기반으로 케이스를 만들어 실행한 뒤 "그래서 코드의 몇 퍼센트가 돌았나"를 되묻는 사후 점검 도구에 가깝다. 이 관계를 거꾸로 알고 있으면 레슨 7에서 헷갈린다.

판단 트리를 실제 상황에 대보기

흐름도는 외우는 게 아니라 굴려보는 것이다. 네 가지 상황에 적용해보자.

상황 1 — 신규 결제 수단 추가. PRD가 15쪽으로 상세하고, 금액 구간별 수수료 정책 표까지 들어 있다. 코드는 아직 개발 중이라 없다.

1번 → 예. 2번 → 금액 구간은 동등분할·경계값, 수수료 정책 표는 조건이 여러 개 맞물리므로 결정테이블. 3번 → 코드가 아직 없으니 지금은 불가, 개발 완료 후 커버리지로 되짚기. 4번 → 시간이 있으니 급하지 않다.

결론: 명세 기반 중심. 결정테이블을 먼저 그리는데, 여기엔 부가 효과가 있다 — 표의 빈칸이 곧 PRD가 답하지 않은 조합이라서, 개발 시작 전에 기획자에게 되물을 질문 목록이 자동으로 나온다.

상황 2 — 레거시 정산 배치 리팩터링. 명세는 없고 "지금과 똑같이 동작하기만 하면 된다"가 유일한 요구사항이다. 코드는 있다.

1번 → 아니오(명세가 없다). 그런데 4번으로 바로 가면 안 된다. 여기서 현재 동작 자체가 명세라는 점을 알아채는 게 핵심이다. 3번 → 코드가 있고 접근 가능하다.

결론: 구조 기반이 주인공이 되는 드문 경우다. 리팩터링 전 코드의 분기를 훑어 케이스를 만들고, 리팩터링 전후 결과를 비교한다. 순환 복잡도(레슨 10)로 "최소 몇 개의 경로를 확인해야 하는지"를 계산해두면 회귀 범위를 숫자로 방어할 수 있다.

상황 3 — 릴리즈 D-1 핫픽스. 장애 대응으로 한 줄 고쳤고, 검증 시간은 두 시간. 명세는 장애 티켓 한 줄이 전부다.

1번 → 사실상 아니오. 4번 → 예, 시간이 절대적으로 부족하다.

결론: 경험 기반. 다만 "감으로 아무거나 눌러본다"가 아니다. 고친 코드가 닿는 영역의 과거 결함 이력을 근거로 삼는다. "이 화면은 지난 6개월간 소수점 반올림과 빈 목록에서 세 번 터졌다" 같은 기록이 그대로 우선순위가 된다. 여기에 회귀 체크리스트 상위 10개를 얹으면 두 시간을 가장 밀도 있게 쓸 수 있다.

상황 4 — 외부 제휴사 API 연동. 제휴사가 준 API 문서는 있다. 하지만 제휴사 서버의 코드는 볼 수 없고, 요청 파라미터 조합이 6개 필드 × 3~4값이다.

1번 → 예(제휴사 문서가 명세다). 2번 → 조합이 폭발하므로 페어와이즈. 3번 → 아니오. 상대편 코드에는 구조 기반을 쓸 수 없다. 우리 쪽 연동 코드에는 쓸 수 있지만, 결함이 나는 곳은 대개 경계 너머다.

결론: 명세 기반(페어와이즈) + 경험 기반. 구조 기반이 원천적으로 막혀 있다는 사실 자체가 전략을 바꾼다. 코드를 못 보니 응답 로그와 에러 코드가 유일한 관찰 창구이고, 그래서 "문서에 없는 에러 코드가 오면?" 같은 경험 기반 질문의 값어치가 평소보다 크다.

네 상황을 겹쳐 보면 규칙이 하나 보인다. 기법을 고르는 것은 취향이 아니라 제약의 결과다. 명세가 없으면 명세 기반을 못 쓰고, 코드가 없거나 남의 것이면 구조 기반을 못 쓰고, 시간이 없으면 준비 비용이 큰 기법을 못 쓴다. 그래서 실무에서 첫 질문은 "어떤 기법이 좋을까?"가 아니라 "지금 나에게 무엇이 주어져 있는가?" 여야 한다.

한 기능의 생애주기 — 기법은 국면마다 바뀐다

기법 선택은 프로젝트 시작 때 한 번 정하고 끝나는 게 아니다. 같은 기능이라도 국면이 바뀌면 쓸 수 있는 기법과 써야 할 기법이 바뀐다. "선물하기" 기능 하나가 6개월간 어떤 기법을 만나는지 따라가보자.

D-60, 요구사항 리뷰. 코드가 한 줄도 없다. 그런데 여기서 이미 명세 기반 기법을 쓴다 — 케이스를 만들려고가 아니라 명세의 구멍을 찾으려고 쓴다. "받는 사람이 회원이 아닐 때 × 유효기간이 지났을 때 × 결제 취소가 겹쳤을 때"를 결정테이블 초안으로 그려보니 12개 조합 중 5개가 PRD에 답이 없다. 이 5개 질문이 이 시점 QA의 산출물이다(모듈 2에서 배운 테스트 가능한 요구사항 만들기와 정확히 이어진다).

D-30, 개발 중. 명세가 확정됐으니 본격적으로 케이스를 만든다. 금액·유효기간은 동등분할·경계값, 상태(대기→수락→만료→취소)는 상태전이, 옵션 조합은 페어와이즈로 압축한다. 이 국면이 명세 기반 기법의 전성기다.

D-20, 첫 통합 테스트. 개별 케이스는 다 통과하는데 "실제로 선물을 주고받는 전체 흐름"에서 어색한 지점이 나온다. 여기서 유즈케이스 기반(레슨 4)이 들어온다. 단위 조건이 아니라 사용자의 목표를 따라가는 흐름이 대상이다.

D-14, 코드 리뷰와 커버리지 점검. 이제 코드가 있다. 명세 기반으로 만든 케이스를 돌려놓고 분기 커버리지를 재보니 68%다. 안 돌아간 32%를 열어보니 명세에 없는 "관리자 강제 회수" 분기가 들어 있었다. 명세 기반만으로는 영원히 못 찾았을 케이스다. 구조 기반이 사각지대를 메우는 전형적 장면이다.

D-1, 릴리즈 직전. 마지막 빌드가 늦게 나왔고 남은 시간은 세 시간. 전체 케이스 재실행은 불가능하다. 경험 기반으로 전환한다 — 이번 스프린트에 가장 많이 수정된 파일이 닿는 화면, 과거에 결제 관련 결함이 몰렸던 경로를 우선 훑는다.

D+45, 리팩터링 후 회귀. 기능은 그대로 두고 내부 구조만 바꿨다. 명세는 안 바뀌었으니 새 케이스를 만들 이유가 없다. 바뀐 코드가 어디까지 닿는지가 유일한 질문이므로 구조 기반이 다시 전면에 나온다.

정리하면 이렇게 된다.

이 표의 함의가 하나 있다. 기법을 배우는 순서와 실무에서 만나는 순서가 다르다. 이 모듈은 명세 기반 → 구조 기반 → 경험 기반 순으로 배우지만, 실제 프로젝트에서는 같은 주에 세 갈래를 다 쓰는 날도 있다. 그래서 지도가 필요한 것이다.

기법을 잘못 골랐을 때 벌어지는 일

기법 선택 실패는 조용히 일어나서 잘 드러나지 않는다. 네 가지 전형적인 실패를 보자.

실패 1 — 명세가 부실한데 결정테이블을 그리려 했다.

정산 화면 테스트에 배정된 신입 QA가 "조건이 여러 개니까 결정테이블"이라고 판단하고 표를 그리기 시작했다. 그런데 명세에 적힌 조건이 "정산 대상 여부", "보류 상태", "예외 계약"뿐이고 각각의 정의가 없다. 정의를 추정해가며 표를 채우느라 이틀이 지났고, 완성된 표를 개발자에게 보여주니 "이 세 개는 사실 한 필드에서 나오는 값이라 조합 자체가 생기지 않는다"는 답이 돌아왔다.

• 무엇이 잘못됐나: 결정테이블은 조건이 명확히 정의돼 있을 때 조합을 정리하는 기법이다. 조건의 정의부터 없으면 표를 채우는 행위가 추측을 형식화하는 일이 된다. 형식이 그럴듯해서 추측이라는 사실이 가려진다는 게 더 나쁘다.
• 어떻게 했어야 하나: 흐름도 1번에서 "명세가 있는가"에 사실은 아니오 였다. 표를 완성하려 하지 말고, 10분만 그려본 뒤 빈칸을 질문 목록으로 만들어 기획자에게 되돌렸어야 한다. 같은 결정테이블이라도 이때는 산출물이 케이스가 아니라 질문이다.

실패 2 — 명세가 충분한데 감으로만 테스트했다.

쿠폰 정책이 표로 명확히 정리된 기능인데, 담당자가 "익숙한 화면"이라며 탐색적으로만 훑고 통과시켰다. 배포 후 "정액 쿠폰 + 무료배송 쿠폰 중복 적용" 조합에서 금액이 음수가 되는 결함이 나왔다. 명세 표에는 그 조합이 "불가"로 명시돼 있었다.

• 무엇이 잘못됐나: 근거가 이미 문서로 존재하는데 그걸 쓰지 않았다. 경험 기반은 다른 근거가 없을 때 쓰는 보완재이지, 있는 명세를 대신하는 게 아니다.
• 어떻게 했어야 하나: 명세 표를 그대로 결정테이블로 옮겼다면 그 조합은 한 행으로 존재했을 것이다. 익숙함은 기법을 생략할 근거가 되지 못한다 — 오히려 익숙한 화면일수록 "당연히 되겠지"로 건너뛰는 조합이 늘어난다.

실패 3 — 커버리지 숫자를 품질 목표로 삼았다.

팀이 "분기 커버리지 90% 미만이면 릴리즈 불가"라는 규칙을 세웠다. 몇 스프린트 뒤 커버리지는 92%가 됐는데 유출 결함은 줄지 않았다. 확인해보니 단언(assert) 없이 함수를 호출만 하는 테스트가 늘어나 있었다. 코드는 "실행"됐지만 아무것도 검증되지 않았다.

• 무엇이 잘못됐나: 구조 기반 지표는 "무엇을 안 봤는가"를 알려주는 역방향 신호다. 낮은 커버리지는 확실한 위험 신호지만, 높은 커버리지는 품질의 증거가 아니다. 자세한 함정은 레슨 7에서 다룬다.
• 어떻게 했어야 하나: 커버리지는 미달 구간을 찾아 왜 안 돌았는지 묻는 데 쓴다. 앞의 "선물하기" 사례에서 미실행 32%를 열어보니 명세에 없는 분기가 나왔던 것이 올바른 사용법이다.

실패 4 — 페어와이즈를 아무 데나 썼다.

필드가 3개뿐인 폼(각 2·2·3값 = 12조합)에 페어와이즈 도구를 돌려 6개로 줄였다. 줄인 6개에는 "필수 약관 미동의 + 결제 시도"라는 반드시 확인해야 할 조합이 빠져 있었다.

• 무엇이 잘못됐나: 페어와이즈는 조합이 감당 못 할 만큼 많을 때 손실을 감수하고 줄이는 기법이다. 전수 12개는 그냥 다 하면 된다. 그리고 도구가 "중요한 조합"을 알 리 없다 — 도구는 통계적으로 균등하게 고를 뿐이다.
• 어떻게 했어야 하나: 전수가 가능한 규모면 전수로 가고, 페어와이즈를 쓰더라도 필수 조합은 고정(seed)으로 지정한다. 이 지정 기능이 왜 필요한지는 레슨 5에서 다룬다.

네 실패의 공통 구조를 보면 이렇다.

모든 실패가 "기법을 몰라서"가 아니라 "상황을 안 봐서" 생겼다는 점이 이 레슨의 요지다.

겹쳐 쓰기 — 실무의 기본값

실무에서는 한 기법만 쓰지 않는다. 동등분할로 큰 그룹을 나누고, 그 경계를 경계값으로 찌르고, 변수가 여러 개면 페어와이즈로 조합을 줄이고, 상태가 있으면 상태전이를 얹고, 시간이 남으면 경험 기반으로 빈틈을 훑는 식으로 겹쳐서 쓴다.

겹쳐 쓸 때는 순서가 있다. 보통 이 순서가 낭비가 가장 적다.

1. 범위를 나눈다 — 동등분할로 무엇을 대표값으로 삼을지 정한다.
2. 경계를 찌른다 — 나눈 구획의 경계에 경계값을 배치한다.
3. 조건을 정리한다 — 규칙이 얽혀 있으면 결정테이블, 시간축이 있으면 상태전이.
4. 조합을 줄인다 — 그래도 폭발하면 페어와이즈로 압축하되 필수 조합은 고정.
5. 흐름으로 묶는다 — 흩어진 케이스를 유즈케이스 시나리오로 이어 실행 순서를 만든다.
6. 되짚는다 — 실행 후 커버리지로 미실행 영역을 확인한다.
7. 남은 시간을 채운다 — 경험 기반 체크리스트로 빈틈을 훑는다.

1~5는 케이스를 만드는 단계, 6은 검사하는 단계, 7은 보완하는 단계다. 이 셋을 섞어 생각하면 "커버리지를 먼저 재고 케이스를 만들자" 같은 뒤집힌 계획이 나온다. 이 조합을 한 기능에 실제로 적용하는 연습은 레슨 9(TC 설계 종합)에서 한다.

시간이 정해져 있을 때 — 배분 감각

실무에서 가장 자주 받는 질문은 "이 기능 테스트에 3일 있는데 뭘 하죠?"다. 정답은 없지만 출발점으로 삼을 만한 배분은 있다.

마지막 줄이 특이하다. 규제 산업에서는 경험 기반의 비중이 오히려 낮다. 근거를 문서로 증명해야 하는데 "제 경험상 여기가 위험합니다"는 증빙이 되지 않기 때문이다. 같은 기법이 어떤 조직에서는 실용적이고 어떤 조직에서는 쓸 수 없다는 것 — 이것도 기법 선택이 상황의 함수라는 증거다.

지도를 미리 보는 이유

지도를 모른 채 기법을 하나씩 배우면 "이건 언제 쓰는 거지?"를 매번 새로 고민하게 된다. 먼저 지도를 보면, 새 기법을 배울 때마다 "아, 이건 명세 기반 쪽에서 조합 문제를 해결하는 기법이구나" 하고 위치를 잡을 수 있다.

지도 자체를 외울 필요는 없다 — 이후 레슨을 읽으며 이 표로 계속 돌아와도 된다. 다만 앞으로 각 레슨을 읽을 때 세 가지는 매번 확인하며 읽기를 권한다.

1. 이 기법의 전제 조건은 무엇인가 (없으면 못 쓰는 것)
2. 이 기법은 케이스 수를 어떻게 정하는가 (얼마나 예측 가능한가)
3. 이 기법이 못 보는 것은 무엇인가 (다른 갈래로 메워야 할 사각지대)

이 세 질문에 답할 수 있게 되면, 기법 아홉 개를 외운 사람이 아니라 상황에 맞게 꺼내 쓸 수 있는 사람이 된다.

실무에서 왜 필요한가

근거를 말할 수 있어야 케이스가 방어된다

면접이나 실무 리뷰에서 "왜 이 기법을 쓰셨나요?"라는 질문에 "그냥 배운 거라서요"는 답이 안 된다. "명세가 명확했고 조합해야 할 변수가 많아서 페어와이즈를 썼습니다"처럼 상황과 기법을 연결해 설명할 수 있어야 설득력이 생긴다. 이 지도가 그 설명의 뼈대다.

이건 태도의 문제가 아니라 실질적인 문제다. 테스트 케이스는 항상 줄이라는 압력을 받는다. "이거 꼭 해야 하나요?"라는 질문에 "동등분할로 나눈 5개 구획 중 3개를 덜어내면 이 정책 조건이 통째로 미검증으로 남습니다"라고 답할 수 있으면 협상이 된다. 근거가 없으면 케이스는 일정 압박 앞에서 그냥 잘려나간다.

시간 배분이 곧 QA의 실력이다

실무에서 시간은 항상 부족하다. 어떤 상황에 어떤 기법이 가장 효율적인지 판단하는 능력 자체가 시니어와 주니어를 가르는 기준 중 하나다. 주니어는 아는 기법을 성실하게 전부 적용하려다 시간을 다 쓰고, 시니어는 이번엔 어떤 기법을 안 쓸지를 먼저 정한다. 앞의 배분 표가 그 감각의 출발점이다.

기법 선택이 팀의 대화를 바꾼다

기법 이름은 팀 안에서 공용어로 작동한다. "이 부분 좀 더 봐주세요"보다 "이 조건 조합은 결정테이블로 정리해봤는데 세 칸이 명세에 없습니다"가 훨씬 빠르게 움직인다. 개발자에게도, 기획자에게도, 다른 QA에게도 같은 그림이 전달되기 때문이다. 모듈 2에서 배운 "요구사항을 질문으로 되돌리기"가 실제로 힘을 갖는 순간이 바로 기법이 만들어낸 빈칸을 들이밀 때다.

자동화·AI 시대에 더 중요해진다

케이스를 실행하는 일은 점점 자동화되고, 케이스 초안을 만드는 일도 AI가 상당 부분 해준다. 하지만 "이 상황에서 무엇을 근거로 설계할 것인가"를 정하는 일은 여전히 사람의 판단이다. AI가 뽑아준 케이스 목록을 보고 "이건 명세 기반으로 만든 것인데 상태 전이 관점이 통째로 빠졌다"고 짚어내려면, 정확히 이 지도가 머릿속에 있어야 한다. 스테이지 6(AI 교차검증)에서 이 능력을 직접 쓰게 된다.

채용시장에서의 위치

테스트 설계 기법은 QA 면접에서 거의 반드시 나오는 주제다. 그런데 질문의 형태가 경력에 따라 다르다.

세 번째 줄이 이 레슨의 자리다. 신입 지원자라도 세 번째 질문에 답할 수 있으면 확실히 눈에 띈다. 답할 때는 기법 이름을 나열하는 대신 판단 과정을 순서대로 말하는 게 좋다. "먼저 명세가 판정 기준이 될 만한지 확인하고, 안 되면 그 자체를 질문으로 돌린 뒤, 그 사이엔 과거 결함 이력 기반으로 우선순위를 잡겠습니다"처럼.

ISTQB Foundation Level 시험에서도 이 분류(명세 기반/구조 기반/경험 기반)는 배점이 큰 영역이다. 자격증을 준비한다면 각 기법이 어느 갈래에 속하는지를 묻는 문제가 반복해서 나오므로 이 레슨의 첫 표가 그대로 시험 범위이기도 하다.

실습 과제

과제 1 — 상황에 기법 갈래 매칭하기 (10분)

다음 다섯 상황 각각에 어떤 갈래(명세 기반/구조 기반/경험 기반)가 가장 먼저 필요할지 고르고, 이유를 한 줄로 적는다.

1. 신규 기능의 요구사항 문서가 상세히 있고, 아직 코드는 없다.
2. 이미 배포된 코드에 대해 "정말 모든 분기가 테스트됐는지" 감사받아야 한다.
3. 요구사항 문서가 거의 없이 "일단 화면부터 보고 테스트해달라"는 요청을 받았고, 릴리즈까지 하루 남았다.
4. 기능 변경은 없고 내부 구조만 정리한 리팩터링 PR을 검증해야 한다.
5. 제휴사 API를 연동하는데 문서는 있지만 상대 서버 코드는 볼 수 없고, 파라미터 조합이 200가지가 넘는다.

과제 2 — 판단 흐름도 직접 굴려보기 (15분)

아래 상황을 본문의 판단 흐름도 1~5번에 순서대로 대입해, 각 번호에서 무엇이라고 답했는지 적고 최종 기법 조합을 정한다.

온라인 강의 플랫폼에 "수강 기간 연장" 기능을 추가한다. 기획서에는 연장 가능 조건(수강률 80% 미만, 만료 후 30일 이내, 연장은 1회만, 유료 강의만)이 표로 정리돼 있다. 개발은 2주 뒤 완료 예정이고, 검증 기간은 5일이다.

과제 3 — 실패 사례 진단하기 (10분)

아래는 실제로 흔한 장면들이다. 각각 어떤 유형의 기법 선택 실패인지 본문의 네 가지 분류에 대보고, 무엇을 했어야 하는지 한 줄로 적는다.

1. "이번 스프린트 커버리지 95% 달성했습니다"라고 보고했는데, 다음 주에 결제 금액이 0원으로 찍히는 결함이 유출됐다.
2. 명세에 나온 조건이 두 개뿐인데 페어와이즈 도구를 돌렸다.
3. 3년간 담당한 익숙한 화면이라 케이스 없이 훑고 통과시켰는데, 새로 추가된 옵션 조합에서 결함이 났다.
4. 기획자가 아직 정하지 못한 정책을 QA가 임의로 가정해 상태 전이도를 완성했고, 그 그림이 개발팀에 그대로 전달돼 구현됐다.

과제 4 — 기법 조합 설계하기 (10분)

"할인 쿠폰 적용" 기능에 대해 최소 두 가지 갈래의 기법을 조합한다면 어떤 순서로, 어떤 기법을 쓸지 계획을 3~4문장으로 적어본다. 아직 각 기법을 자세히 배우기 전이니 "동등분할로 시작해서 조합이 많으면 …로 줄인다" 정도의 큰 그림으로 충분하다.

작성한 뒤 아래를 스스로 점검한다.

• 각 기법을 고른 이유가 상황(명세·코드·시간)과 연결돼 있는가?
• 케이스를 만드는 단계와 검사하는 단계를 구분했는가?
• 이 조합이 못 보는 것이 무엇인지 한 줄로 말할 수 있는가?

과제 5 — 내 프로젝트의 배분 그려보기 (선택, 10분)

지금 담당하고 있거나 최근에 했던 테스트 업무를 하나 떠올려, 실제로 쓴 시간을 세 갈래로 나눠 대략의 비율로 적어본다. 그리고 본문의 배분 표와 비교한다.

차이가 크다면 이유가 무엇인지 한 줄로 적는다. "기법을 몰라서"인지, "그 갈래를 쓸 전제가 없어서"인지를 구분하는 게 이 과제의 목적이다. 후자라면 그건 개인의 문제가 아니라 팀 프로세스의 문제이고, 개선 제안의 재료가 된다.

자가 체크리스트

• 명세 기반·구조 기반·경험 기반 세 갈래를 "무엇을 근거로 만드는가"로 구분할 수 있다
• 동등분할·경계값 분석이 왜 명세 기반에 속하는지 설명할 수 있다
• 세 갈래 각각의 전제 조건(명세/코드 접근/경험)을 댈 수 있다
• 세 갈래 각각이 못 보는 것을 하나씩 말할 수 있다
• 판단 흐름도의 질문 순서(명세 → 무엇이 복잡한가 → 코드 접근 → 시간 → 빈틈 점검)를 따라갈 수 있다
• 구조 기반이 명세 기반을 대체하는 게 아니라 덧대는 관계임을 설명할 수 있다
• 명세의 어떤 복잡함이 어떤 기법으로 이어지는지(범위/조건 조합/상태/흐름/조합 폭발/관점) 연결할 수 있다
• 같은 기능이라도 프로젝트 국면에 따라 쓰는 기법이 달라진다는 것을 예로 설명할 수 있다
• 리팩터링 회귀에 왜 구조 기반이 적합한지 말할 수 있다
• 기법 선택 실패 네 유형(전제 없이 강행 / 있는 근거 무시 / 지표를 목표로 / 과잉 최적화)을 구분할 수 있다
• 커버리지 숫자가 높다는 것이 왜 품질의 증거가 아닌지 설명할 수 있다
• 겹쳐 쓰기의 순서(만들기 → 검사하기 → 보완하기)를 구분할 수 있다
• 시간·상황에 따라 세 갈래의 비중을 다르게 배분할 수 있다
• 이 모듈의 어떤 레슨에서 어떤 기법을 배우는지 대략 짚을 수 있다

흔한 실수

• 한 기법을 배우면 그것만 계속 쓴다. 동등분할을 배웠다고 모든 상황에 동등분할만 적용하면, 조합이 많은 상황이나 코드 검증이 필요한 상황에서는 비효율적이다.
• 기법 선택 이유를 설명하지 못한다. "왜 이 기법을 썼나요?"에 답하지 못하면, 리뷰나 면접에서 그 케이스의 근거 자체가 흔들린다. 케이스를 줄이라는 압박이 올 때 방어할 말도 없어진다.
• 구조 기반 기법을 명세 기반처럼 오해한다. 구조 기반은 코드를 봐야 쓸 수 있다 — 명세만 보고 "이 코드의 분기를 다 커버했다"고 말할 수 없다.
• 구조 기반이 명세 기반을 대체한다고 생각한다. 커버리지 100%여도 아예 구현되지 않은 요구사항은 절대 발견되지 않는다. 없는 코드에는 커버리지가 측정되지 않는다.
• 전제가 없는데 기법 형식만 채운다. 조건 정의가 없는 상태에서 결정테이블을 완성하면, 결과물은 정리된 표가 아니라 형식을 갖춘 추측이다. 표가 그럴듯해서 추측이라는 사실이 오히려 가려진다.
• QA의 가정이 명세가 되어버린다. 미정 사항을 임의로 채워 그림을 완성하면 그 그림이 구현 근거가 된다. 빈칸은 빈칸으로 남기고 "미정"이라고 표시해 되돌린다.
• 익숙한 기능이라고 기법을 생략한다. 익숙할수록 "당연히 되겠지"로 건너뛰는 조합이 늘어난다. 명세가 있으면 익숙해도 명세 기반부터 간다.
• 커버리지 수치를 품질 목표로 삼는다. 지표가 목표가 되면 지표를 올리는 쪽으로 행동이 왜곡된다(단언 없는 테스트가 늘어나는 식). 커버리지는 미달 구간을 열어보고 "왜 안 돌았나"를 묻는 데 쓴다.
• 줄일 필요가 없는데 조합을 줄인다. 전수가 가능한 규모에 페어와이즈를 쓰면 얻는 것 없이 중요한 조합만 잃는다.
• 기법 선택을 프로젝트 초반에 한 번 정하고 끝낸다. 요구사항 리뷰, 개발 중, 릴리즈 직전, 리팩터링 후는 각각 다른 갈래가 유리하다.
• 시간이 부족하다는 이유로 아무 근거 없이 훑는다. 시간 부족은 경험 기반을 선택할 이유이지, 근거를 버릴 이유가 아니다. 과거 결함 이력과 변경 영향 범위가 그 근거다.

참고 자료

• ISTQB Foundation Level Syllabus — Test Techniques — 명세/구조/경험 기반 분류의 표준 출처. 시험에서 배점이 큰 영역이다
• ISTQB Glossary — black-box / white-box / experience-based test technique 각각의 공식 정의
• Lee Copeland, A Practitioner's Guide to Software Test Design — 기법 선택 전략을 다룬 실무 고전. 기법별 적용 조건 비교가 특히 유용하다
• Rex Black, Advanced Software Testing Vol. 1 — 상황(위험·일정·명세 품질)에 따라 기법을 배분하는 관점을 다룬다
• ISO/IEC/IEEE 29119-4 — 테스트 설계 기법을 국제 표준으로 정리한 문서. 규제 산업에서 기법 선택의 근거로 인용된다