개념
앞의 기법들(동등분할, 경계값, 상태전이, 결정테이블)은 입력값이나 조건 하나하나를 정교하게 파고든다. 유즈케이스 기반 테스트는 시야를 넓혀 사용자가 목표를 달성하기 위해 시스템과 주고받는 전체 흐름을 본다.
유즈케이스의 구조
유즈케이스는 보통 이렇게 구성된다.
- 행위자(Actor): 누가 이 목표를 가지고 있는가
- 사전조건(Precondition): 시작하기 전에 만족해야 하는 상태
- 기본 흐름(Main/Basic Flow): 아무 문제 없이 목표를 달성하는 정상 경로
- 대안 흐름(Alternative Flow): 정상 경로에서 갈라지지만 결국 목표는 달성하는 경로
- 예외 흐름(Exception Flow): 목표 달성에 실패하는 경로
- 사후조건(Postcondition): 끝났을 때의 상태
유즈케이스: 비밀번호 재설정
- 행위자: 비밀번호를 잊은 사용자
- 사전조건: 가입된 계정이 있다
- 기본 흐름: ① 이메일 입력 → ② 재설정 링크 수신 → ③ 링크 클릭 → ④ 새 비밀번호 입력 → ⑤ 재설정 완료
- 대안 흐름: ③에서 링크가 만료됐으면 → 재발송 안내 → ①로 돌아감
- 예외 흐름: ①에서 가입되지 않은 이메일이면 → "가입 정보 없음" 안내 (보안상 실제로는 "메일을 보냈습니다"로 동일하게 응답하는 경우가 많다 — 이 자체도 테스트 대상이다)
- 사후조건: 새 비밀번호로 로그인 가능
유즈케이스에서 테스트 케이스로
기본 흐름 하나에 테스트 케이스 하나, 대안 흐름마다 하나, 예외 흐름마다 하나씩 만든다. 위 예시라면 최소 3개(기본, 링크 만료 대안, 미가입 예외)가 나온다. 다른 기법과 다른 점은 **각 케이스가 "값 하나 확인"이 아니라 "여러 단계를 거치는 시나리오 전체"**라는 것이다.
다른 기법과의 관계
유즈케이스 기반 테스트는 흔히 시스템·인수 레벨(모듈 1, 레슨 3)에서 쓴다 — 전체 흐름을 봐야 하기 때문이다. 흐름 안의 개별 단계(예: "새 비밀번호 입력"에서 8자 미만이면?)는 여전히 경계값 분석 같은 다른 기법으로 채운다. 즉 유즈케이스가 큰 뼈대를 잡고, 다른 기법들이 그 뼈대 안의 세부 조건을 채우는 관계다.
실무에서 왜 필요한가
값 단위 기법만으로 테스트 케이스를 짜면, 각 조건은 완벽히 검증되지만 정작 "실제 사용자가 처음부터 끝까지 이 기능을 쓸 수 있는가"는 놓칠 수 있다. 예를 들어 비밀번호 재설정의 "새 비밀번호 입력" 단계 자체는 완벽히 테스트했어도, 정작 "링크가 만료됐을 때 사용자가 다시 시도할 방법을 안내받는가"라는 흐름 자체가 빠져 있으면 사용자는 막다른 길에 갇힌다. 유즈케이스 기반 테스트는 이런 흐름 차원의 결함을 잡는다. 또한 E2E 자동화(모듈 13에서 다룬다) 시나리오를 짤 때 유즈케이스가 그대로 스크립트의 뼈대가 되는 경우가 많아 실무 활용도가 높다.
실습 과제
과제 1 — 유즈케이스 작성하기 (15분)
"온라인 주문 취소"에 대한 유즈케이스를 작성한다. 행위자, 사전조건, 기본 흐름을 쓰고, 대안 흐름 1개와 예외 흐름 1개를 추가한다. (힌트: 예외 흐름은 "이미 배송이 시작된 주문을 취소하려는 경우" 등을 생각해본다.)
과제 2 — 테스트 케이스 도출하기 (10분)
과제 1에서 쓴 유즈케이스에서 테스트 케이스를 최소 3개(기본 흐름 1개, 대안·예외 흐름 각 1개 이상) 도출해 표로 정리한다.
자가 체크리스트
- 유즈케이스의 구성 요소(행위자, 사전조건, 기본/대안/예외 흐름, 사후조건)를 설명할 수 있다
- 유즈케이스를 직접 작성할 수 있다
- 유즈케이스에서 대안·예외 흐름별로 테스트 케이스를 도출할 수 있다
- 유즈케이스 기반 테스트가 값 단위 기법과 어떻게 역할을 나눠 갖는지 설명할 수 있다
흔한 실수
- 기본 흐름(해피 패스)만 유즈케이스로 쓰고 대안·예외 흐름을 생략한다. 실무 결함의 상당수는 대안·예외 흐름에서 나온다 — 기본 흐름은 개발자도 이미 꼼꼼히 본 경로이기 때문이다.
- 유즈케이스와 사용자 스토리를 혼동한다. 사용자 스토리("~로서 ~하고 싶다")는 요구사항을 짧게 표현하는 형식이고, 유즈케이스는 그 목표를 달성하는 흐름 전체를 상세히 기술한다. 유즈케이스가 더 크고 구체적이다.
- 유즈케이스 안의 세부 값 조건까지 전부 유즈케이스로 풀려고 한다. "새 비밀번호가 8자 미만이면?"은 경계값 분석의 영역이다. 유즈케이스는 흐름의 뼈대를 잡는 데 쓰고, 세부는 다른 기법에 맡긴다.
참고 자료
- ISTQB Foundation Level Syllabus — Use Case Testing — 유즈케이스 기반 테스트의 공식 정의
- Alistair Cockburn, Writing Effective Use Cases — 유즈케이스 작성법의 대표적 참고서