명세 기반 기법 (1) 동등분할과 경계값 분석

개념

왜 기법이 필요한가

"나이 입력 필드"를 테스트한다고 하자. 입력 가능한 값은 사실상 무한하다. 아무 값이나 20개 넣어보는 것과, 기법으로 6개를 고르는 것 중 후자가 결함을 더 많이 찾는다. 테스트 설계 기법은 요령이 아니라 커버리지를 근거로 설명할 수 있게 만드는 도구다.

동등분할 (Equivalence Partitioning)

같은 방식으로 처리될 입력들을 하나의 그룹으로 묶고, 그룹당 대표값 하나만 테스트한다.

요구사항: 나이는 19세 이상 65세 이하만 가입할 수 있다.

핵심 규칙 두 가지가 있다.

1. 유효 파티션은 한 번에 여러 개를 조합해도 된다. (통과하는 케이스는 묶어서 확인)
2. 비유효 파티션은 반드시 한 번에 하나씩 테스트한다. 두 개를 동시에 위반하면 어느 쪽 검증 로직이 동작한 건지 알 수 없다. 앞선 검증에 가려져 뒤쪽 검증의 버그를 놓치는 현상을 결함 마스킹(fault masking) 이라고 한다.

경계값 분석 (Boundary Value Analysis)

결함은 파티션 한가운데가 아니라 경계에서 나온다. 이유는 코드를 보면 자명하다.

// 요구사항: 19세 이상 65세 이하 가입 가능
function canSignUp(age) {
  return age > 19 && age < 65;   // 버그: >= 와 <= 여야 한다
}

이 코드는 나이 30을 넣으면 정상 통과한다. 19와 65를 넣어야만 드러난다. > 와 >=, < 와 <=, i < n 과 i <= n 을 헷갈리는 것은 경력과 무관하게 계속 발생한다. 그래서 경계는 항상 본다.

경계값은 두 방식이 있다.

2-value (경계 ± 1) — 실무에서 가장 흔하다.

19세 이상 65세 이하  →  18, 19  /  65, 66

3-value (경계 앞·경계·경계 뒤) — 리스크가 큰 영역에서 쓴다.

19세 이상 65세 이하  →  18, 19, 20  /  64, 65, 66

놓치기 쉬운 경계들

숫자 범위만 경계가 아니다. 실무 결함의 상당수가 여기서 나온다.

특히 "정확히 기준선에 걸친 값" 이 위험하다. 무료 배송 기준이 30,000원일 때 정확히 30,000원을 주문하면 무료인가 아닌가? 요구사항에 안 적혀 있다면 그건 결함이 아니라 명세 결함이고, 개발이 시작되기 전에 물어보는 것이 QA의 일이다.

두 기법은 항상 세트로 쓴다

동등분할로 어디를 볼지 정하고, 경계값으로 그 안 어디를 찌를지 정한다.

요구사항: 주문 금액 30,000원 이상이면 배송비 무료, 미만이면 3,000원.

6건이면 이 요구사항은 충분히 덮인다. 무작정 20건 만드는 것보다 낫고, 각 케이스가 왜 존재하는지 설명할 수 있다. 이 "설명 가능성"이 리뷰와 면접에서 결정적이다.

실무에서 왜 필요한가

자동화 테스트를 짤 때 파라미터라이즈 테스트에 어떤 값을 넣을지 고르는 근거가 바로 이 두 기법이다. "값을 몇 개 넣을까"가 아니라 "어떤 값이 서로 다른 코드 경로를 대표하는가"를 판단하는 게 이 두 기법의 실질적 쓸모다.

AI가 만든 TC를 검증할 때도 마찬가지다. AI에게 TC를 시키면 대체로 유효 케이스는 잘 만들고 경계와 비유효 조합을 빠뜨린다. 실제로 "나이 입력 TC 만들어줘"를 시켜보면 대부분 19와 65 자체를 빼먹거나, 넣더라도 >= 와 > 중 어느 쪽이 맞는지 요구사항에서 확인하지 않고 넘어간다. 기법을 모르면 "빠졌다"는 사실 자체를 알아채지 못한다. 그 확인이 사람의 몫이다.

채용시장에서의 위치

거의 모든 QA 채용공고에 "테스트 케이스 설계 기법 이해"가 들어간다. 면접에서 실제로 손으로 풀리는 단골 문제이기도 하다 — "이 입력 필드의 TC를 만들어 보세요" 같은 형태다. 이 모듈(테스트 설계 기법)이 이 커리큘럼 전체에서 가장 먼저, 가장 비중 있게 다뤄지는 이유가 여기 있다.

실습 과제

과제 1 — 비밀번호 규칙 TC 설계 (10분)

비밀번호는 8자 이상 20자 이하이며, 영문 대문자·소문자·숫자·특수문자 중 3종류 이상을 포함해야 한다. 공백은 허용하지 않는다.

동등분할 표와 경계값을 적용해 TC를 설계한다. 목표는 12건 이내.

체크 포인트:

• 길이 경계 4개(7, 8, 20, 21)를 넣었는가
• "3종류 이상"의 경계인 정확히 3종류와 2종류를 구분했는가
• 공백이 문자열 중간·앞뒤에 있는 경우를 나눴는가
• 비유효 케이스를 한 번에 하나씩만 위반시켰는가

과제 2 — 결함이 숨겨진 샘플 앱에서 찾아보기 (10분)

로그인 화면에서 위 기법대로 입력해 본다. 경계값에서만 드러나는 결함이 심어져 있다. 무엇을 찾았고 어떤 기법이 그것을 잡아냈는지 메모에 적는다.

과제 3 — AI TC 채점하기 (10분)

AI에게 과제 1의 요구사항을 그대로 입력해 TC를 생성시킨 뒤, 내가 만든 표와 대조해 채점표를 만든다.

마지막 행이 핵심이다. AI는 "최대 3회 시도 제한" 같은 요구사항에 없는 규칙을 자주 지어낸다. 이것이 환각이고, 그대로 TC로 넘기면 개발자와 싸우게 된다.

자가 체크리스트

• 동등분할의 정의와 목적을 한 문장으로 설명할 수 있다
• 비유효 파티션을 한 번에 하나씩만 테스트해야 하는 이유(결함 마스킹)를 설명할 수 있다
• 경계값 분석의 2-value 방식과 3-value 방식을 구분해 적용할 수 있다
• 경계에서 결함이 나오는 이유를 코드(> vs >=) 수준에서 설명할 수 있다
• 숫자 범위 외의 경계(문자열 길이, 목록 0건, 날짜, 금액 기준선)를 5가지 이상 나열할 수 있다
• 요구사항에 경계 처리가 명시되지 않았을 때 명세 결함으로 제기할 수 있다
• 하나의 요구사항에 대해 근거를 설명할 수 있는 TC 표를 만들 수 있다
• AI가 만든 TC에서 빠진 경계와 창작된 요구사항을 찾아낼 수 있다

흔한 실수

• 비유효 파티션 두 개를 한 케이스에 동시에 넣는다. "나이 -5, 이메일 형식 오류"를 한 TC에 넣으면 어느 검증이 실패한 건지 알 수 없다 (결함 마스킹). 비유효는 항상 하나씩.
• 경계값을 "대략 근처 값"으로 때운다. 29,000원 대신 29,999원을 넣어야 한다. 근사값은 진짜 경계를 비껴가기 쉽다.
• 숫자 범위에서만 경계를 찾는다. 문자열 길이·목록 개수·날짜·파일 크기에도 경계가 있다는 걸 잊는다.
• AI가 만든 TC를 검수 없이 그대로 채택한다. 경계가 빠졌는지, 요구사항에 없는 규칙을 지어냈는지 반드시 대조한다.
• 케이스 개수를 늘리는 것 자체를 목표로 삼는다. 근거 없이 20개를 만드는 것보다, 근거 있는 6개가 리뷰에서 더 설득력 있다.

참고 자료

• ISTQB Foundation — Test Techniques — 블랙박스 기법의 표준 정의
• Software Testing Help — Boundary Value Analysis and Equivalence Partitioning — 예제가 풍부하다
• Microsoft PICT (페어와이즈 도구) — 이 모듈 뒤쪽 레슨에서 다룰 조합 테스트 도구