개념
앞의 기법들(동등분할, 경계값, 상태전이, 결정테이블)은 입력값이나 조건 하나하나를 정교하게 파고든다. 유즈케이스 기반 테스트는 시야를 넓혀 사용자가 목표를 달성하기 위해 시스템과 주고받는 전체 흐름 을 본다.
값을 보는 눈과 여정을 보는 눈
비유를 하나 들어보자. 지하철역을 점검한다고 하자. 개찰구가 카드를 제대로 읽는지, 에스컬레이터가 도는지, 안내판 글자가 맞는지 — 설비를 하나씩 점검하는 것이 지금까지 배운 값 단위 기법이다. 유즈케이스 기반 테스트는 다른 질문을 한다. "승객이 입구로 들어와서 원하는 열차를 타고 목적지에 내리기까지 실제로 갈 수 있는가?"
설비가 전부 정상인데도 여정이 실패할 수 있다. 개찰구는 멀쩡하지만 그 앞에 계단만 있어서 유모차를 끌고는 못 올라간다든가, 환승 통로 안내가 끊겨서 중간에 길을 잃는다든가. 개별 부품의 결함이 아니라 부품 사이의 빈틈에서 생기는 실패 — 이것이 유즈케이스 기반 테스트가 잡으려는 대상이다.
| 값 단위 기법(동등분할·경계값 등) | 유즈케이스 기반 테스트 | |
|---|---|---|
| 질문 | 이 입력에 이 결과가 맞는가 | 사용자가 목표에 도달할 수 있는가 |
| 단위 | 필드 하나, 조건 하나 | 여러 화면·여러 단계를 거치는 흐름 |
| 놓치는 것 | 단계 사이의 연결, 안내, 되돌아가기 | 각 단계 안의 세부 값 조건 |
| 주로 쓰는 레벨 | 단위·통합 | 시스템·인수 (모듈 1, 레슨 3) |
두 눈은 경쟁 관계가 아니라 서로가 못 보는 곳을 보는 관계 다. 그래서 실무에서는 언제나 함께 쓴다.
유즈케이스의 구조
유즈케이스는 보통 이렇게 구성된다.
| 구성 요소 | 의미 | QA가 여기서 던질 질문 |
|---|---|---|
| 행위자(Actor) | 누가 이 목표를 가지고 있는가 | 행위자가 정말 한 종류인가? 신규·기존·소셜 가입자가 섞여 있지 않은가 |
| 사전조건(Precondition) | 시작 전에 만족해야 하는 상태 | 이 조건이 깨진 채로 진입하면 어떻게 되는가 |
| 기본 흐름(Main/Basic Flow) | 문제 없이 목표를 달성하는 정상 경로 | 몇 단계인가? 각 단계가 실패할 수 있는가 |
| 대안 흐름(Alternative Flow) | 갈라지지만 결국 목표는 달성하는 경로 | 문서에 적힌 것 말고 다른 길은 없는가 |
| 예외 흐름(Exception Flow) | 목표 달성에 실패하는 경로 | 실패한 사용자가 다음에 무엇을 할 수 있는가 |
| 사후조건(Postcondition) | 끝났을 때의 상태 | 흐름이 중간에 끊기면 상태가 어중간하게 남지 않는가 |
오른쪽 열이 이 표의 핵심이다. 유즈케이스 문서를 읽는 것과 유즈케이스로 테스트를 설계하는 것은 다른 일이다. 문서를 읽기만 하면 적힌 흐름을 그대로 따라가게 되고, 질문을 던지면 문서에 없는 흐름이 드러난다.
유즈케이스: 비밀번호 재설정
- 행위자: 비밀번호를 잊은 사용자
- 사전조건: 가입된 계정이 있다
- 기본 흐름: ① 이메일 입력 → ② 재설정 링크 수신 → ③ 링크 클릭 → ④ 새 비밀번호 입력 → ⑤ 재설정 완료
- 대안 흐름: ③에서 링크가 만료됐으면 → 재발송 안내 → ①로 돌아감
- 예외 흐름: ①에서 가입되지 않은 이메일이면 → "가입 정보 없음" 안내 (보안상 실제로는 "메일을 보냈습니다"로 동일하게 응답하는 경우가 많다 — 이 자체도 테스트 대상이다)
- 사후조건: 새 비밀번호로 로그인 가능
이 유즈케이스는 이 레슨 내내 예시로 다시 등장한다. 지금은 "잘 쓰인 유즈케이스"처럼 보이지만, 뒤의 사례 연구에서 여기에 뚫려 있는 구멍 이 실제 장애로 이어지는 모습을 보게 된다.
정상·대안·예외를 가르는 한 가지 질문
셋을 구분하는 기준은 딱 하나다. "이 경로의 끝에서 사용자가 원래 목표를 달성했는가?"
| 흐름 | 목표 달성 | 경로 | 비밀번호 재설정 예시 |
|---|---|---|---|
| 정상(Happy Path) | ⭕ | 가장 짧고 흔한 길 | 메일 링크로 바로 재설정 |
| 대안(Alternative) | ⭕ | 다른 길로 돌아서 도착 | 링크가 만료돼 재발송받아 재설정 |
| 예외(Exception) | ❌ | 도착하지 못함 | 잘못된 인증 코드를 5회 틀려 잠김 |
"성공이냐 실패냐"가 아니라 "목표에 도달했느냐" 로 판단한다는 점이 중요하다. 이 차이를 로그인 기능으로 대비해보면 선명해진다.
| 장면 | 어느 흐름인가 | 이유 |
|---|---|---|
| 이메일+비밀번호로 로그인 성공 | 정상 | 가장 표준적인 경로 |
| 카카오 계정으로 로그인 성공 | 대안 | 수단은 다르지만 "로그인된 상태"라는 목표는 같다 |
| 비밀번호를 한 번 틀린 뒤 다시 입력해 성공 | 대안 | 중간에 실패했어도 결국 도달했다 |
| 비밀번호를 계속 틀려 로그인 못 함 | 예외 | 목표에 도달하지 못했다 |
| 계정이 정지 상태라 진입 자체가 막힘 | 예외 | 사전조건이 깨진 채 목표 실패 |
여기서 자주 하는 착각이 있다. "에러 메시지가 뜨면 예외 흐름"이라고 생각하는 것이다. 위 표의 세 번째 줄을 보자. 비밀번호를 한 번 틀리면 빨간 에러 메시지가 뜨지만, 사용자는 다시 입력해서 결국 로그인한다. 목표를 달성했으므로 대안 흐름 이다. 에러 화면의 유무가 아니라 여정의 종착지 가 기준이다.
이 구분이 왜 중요한가? 테스트할 때 확인해야 할 것이 완전히 다르기 때문이다.
| 대안 흐름에서 확인할 것 | 예외 흐름에서 확인할 것 | |
|---|---|---|
| 결과 | 정상 흐름과 똑같은 최종 상태가 되는가 | 시스템이 안전한 상태로 남는가 |
| 데이터 | 다른 경로로 왔어도 데이터가 동일하게 쌓이는가 | 부분적으로 처리된 데이터가 남지 않는가 |
| 안내 | 돌아가는 길임을 사용자가 이해하는가 | 왜 실패했고 다음에 뭘 하면 되는지 알려주는가 |
| 대표 결함 | "이 경로로 오면 값 하나가 빠진다" | "실패했는데 돈은 빠져나갔다" |
대안 흐름의 대표 결함을 특히 기억해두자. 정상 흐름으로 도착했을 때는 채워지는 값이 대안 경로로 왔을 때만 비어 있는 결함 — 이것이 실무에서 가장 자주, 가장 늦게 발견되는 유형이다. 뒤의 사례 연구가 정확히 이 이야기다.
유즈케이스에서 테스트 케이스로
기본 흐름 하나에 테스트 케이스 하나, 대안 흐름마다 하나, 예외 흐름마다 하나씩 만든다. 위 예시라면 최소 3개(기본, 링크 만료 대안, 미가입 예외)가 나온다. 다른 기법과 다른 점은 각 케이스가 "값 하나 확인"이 아니라 "여러 단계를 거치는 시나리오 전체" 라는 것이다.
실제로 표로 옮기면 이렇게 된다.
| ID | 흐름 | 시나리오 | 기대 결과 |
|---|---|---|---|
| UC-PW-01 | 기본 | 가입 이메일 입력 → 링크 클릭 → 새 비밀번호 설정 | 재설정 완료, 새 비밀번호로 로그인됨 |
| UC-PW-02 | 대안 | 링크를 24시간 뒤 클릭 | 만료 안내 + 재발송 수단 제공, 재발송 후 재설정 성공 |
| UC-PW-03 | 대안 | 소셜 가입 계정 이메일로 요청 | 소셜 로그인 안내를 받고 로그인에 성공 |
| UC-PW-04 | 예외 | 미가입 이메일로 요청 | 계정 존재 여부가 노출되지 않는 동일 응답 |
| UC-PW-05 | 예외 | 재설정 도중 링크를 두 번 사용 | 두 번째 사용은 거부, 첫 비밀번호는 유지 |
기대 결과 열을 쓰는 방식에 주목하자. "정상 동작한다"가 아니라 사후조건을 문장으로 적는다. 유즈케이스에는 사후조건이 이미 명시되어 있으므로, 그것을 그대로 기대 결과로 옮기면 된다. 모듈 2에서 배운 "판정 가능한 기준"이 여기서 자연스럽게 이어진다.
한 가지 더. 흐름 하나가 반드시 테스트 케이스 하나인 것은 아니다. 흐름 안의 개별 단계 는 여전히 값 단위 기법으로 쪼갠다. UC-PW-01의 ④번 단계(새 비밀번호 입력)만 떼어놓고 보면 8자 경계, 문자 종류 조합, 이전 비밀번호와 동일한 경우 등 여러 케이스가 나온다. 유즈케이스는 "몇 개의 여정을 볼 것인가"를 정하고, 값 단위 기법은 "각 여정의 한 지점을 얼마나 촘촘히 볼 것인가"를 정한다.
유즈케이스가 놓치는 것 — 사용자는 순서대로 행동하지 않는다
여기가 이 레슨에서 가장 중요한 부분이다. 유즈케이스 문서는 거의 언제나 "사용자가 정해진 순서대로 행동한다" 를 암묵적으로 가정하고 쓰인다. ①→②→③→④→⑤. 하지만 실제 사용자는 이 순서를 지키지 않는다.
문서를 쓴 사람은 기획자이고, 기획자의 머릿속에는 정상적인 사용 장면이 들어 있다. 그래서 순서를 깨는 행동은 문서에 적히지 않는다. 적히지 않은 것은 개발자도 구현하지 않고, 문서만 보고 테스트하는 QA도 확인하지 않는다. 이 삼중의 공백을 메우는 것이 QA의 고유한 몫이다.
| 빈틈 유형 | 실제 장면 | 확인할 것 |
|---|---|---|
| 뒤로가기 | 결제 진행 중 브라우저 뒤로가기 → 다시 결제 | 주문이 두 건 생기는가? 이전 화면이 만료된 정보를 보여주는가 |
| 새로고침 | 주문 완료 화면에서 F5 | 결제가 다시 실행되는가? "이미 처리됨" 안내가 나오는가 |
| 여러 탭 동시 작업 | 탭 A에서 장바구니 비우고, 탭 B에서 그 상품 결제 | 없는 상품을 결제하려 할 때 무엇이 뜨는가 |
| 중단 후 복귀 | 결제 중 전화를 받고 30분 뒤 돌아옴 | 세션 만료 시 입력한 값이 사라지는가? 재고·쿠폰이 아직 유효한가 |
| 동시 실행 | 같은 계정으로 PC와 모바일에서 동시에 같은 작업 | 마지막 저장이 앞의 것을 덮어쓰는가 |
| 역방향 진입 | 완료 페이지 URL을 즐겨찾기해두고 직접 열기 | 단계를 건너뛴 접근이 차단되는가 |
| 중복 클릭 | 결제 버튼을 조급하게 두 번 누름 | 요청이 두 번 나가는가 |
이 표의 항목들은 유즈케이스 문서 어디에도 없지만, 운영 장애로 이어지는 비중은 대안·예외 흐름보다도 높다. 특히 결제·예약·신청처럼 되돌리기 어려운 작업에서 치명적이다. 주문이 두 건 생기면 사용자는 돈을 두 번 낸다.
그럼 어떻게 이 빈틈을 메우는가? 실무에서 쓰는 방법은 단순하다. 완성된 유즈케이스의 각 단계 옆에 세 가지 질문을 붙여본다.
- 여기서 사용자가 멈추면? (이탈·세션 만료·전화·배터리)
- 여기서 사용자가 되돌아가면? (뒤로가기·새로고침·닫았다 다시 열기)
- 여기서 같은 일이 두 번 일어나면? (더블클릭·두 탭·두 기기·재시도)
5단계짜리 유즈케이스라면 이 질문만으로 최대 15개의 확인 지점이 생긴다. 전부 테스트할 필요는 없다 — 되돌리기 어려운 단계(결제 승인, 재고 차감, 메일 발송)에 집중하면 된다. 어디에 집중할지 정하는 기준은 스테이지 2의 리스크 기반 테스트 에서 본격적으로 다룬다.
한 가지 덧붙이면, 이 영역은 탐색적 테스팅 이 가장 강점을 발휘하는 곳이기도 하다. 순서를 깨는 조합은 미리 다 적어둘 수 없기 때문에, 유즈케이스로 뼈대를 잡고 그 위에서 탐색적으로 흔들어보는 조합이 실무에서 가장 효과적이다.
유즈케이스와 사용자 스토리 — 애자일에서는 어떻게 하는가
"우리 회사는 유즈케이스 문서를 안 쓰는데요"라는 반응이 흔하다. 실제로 요즘 많은 팀은 유즈케이스 대신 사용자 스토리 를 쓴다. 그렇다고 이 레슨이 쓸모없어지는 것은 아니다 — 오히려 정보가 적기 때문에 QA가 할 일이 늘어난다.
| 유즈케이스 | 사용자 스토리 | |
|---|---|---|
| 형식 | 행위자·사전조건·흐름·사후조건의 구조화된 문서 | "~로서, ~하고 싶다, 왜냐하면 ~" 한 문장 |
| 분량 | 한 기능에 1~수 페이지 | 카드 한 장 |
| 담는 것 | 흐름 전체(순서·분기·예외) | 목표와 이유 |
| 빠진 것 | 작성·유지 비용이 큼 | 순서와 분기가 통째로 없음 |
| 보완 장치 | 문서 자체 | 수용 기준(Acceptance Criteria) |
핵심은 마지막 두 줄이다. 사용자 스토리는 일부러 흐름을 적지 않는다. 대화로 채우는 것을 전제하기 때문이다. 그 "대화"의 결과물이 수용 기준이고, 수용 기준을 쓰는 자리에 QA가 들어가야 한다는 것이 모듈 2에서 배운 내용이다.
실제로는 이렇게 한다. 스토리 카드를 받으면 머릿속에서 유즈케이스로 펼친다.
스토리: "구매자로서, 주문을 취소하고 싶다. 마음이 바뀔 수 있으니까."
이 한 문장에서 흐름을 뽑아내는 순서다.
- 행위자를 쪼갠다. "구매자"는 한 종류인가? 비회원 주문자, 대리 주문한 사람, 고객센터 상담원도 취소를 하지 않는가?
- 목표 달성 상태를 정의한다. "취소됐다"는 정확히 어떤 상태인가? 주문 상태 변경? 환불 완료? 재고 복구? 알림 발송? — 여기가 사후조건이 된다.
- 정상 흐름을 한 줄로 그린다. 주문 목록 → 취소 선택 → 사유 입력 → 확인 → 완료.
- "같은 목표에 도달하는 다른 길"을 찾는다. → 대안 흐름. 부분 취소, 고객센터를 통한 취소, 결제 수단별로 다른 환불 경로.
- "목표에 도달하지 못하는 경우"를 찾는다. → 예외 흐름. 이미 배송 시작, 이미 취소된 주문, 환불 계좌 오류.
- 각 단계에 앞 절의 세 가지 질문을 붙인다. → 순서를 깨는 경우.
이 여섯 단계를 거치면 카드 한 장이 테스트 케이스 10여 개로 펼쳐진다. 애자일에서 유즈케이스 기법이 사라진 게 아니라, 문서로 존재하던 것이 QA의 머릿속 절차로 옮겨간 것이다. 그리고 이 과정에서 나온 질문들이 곧 스프린트 플래닝에서 QA가 던질 질문이 된다 — "부분 취소도 이번 스토리에 포함인가요?" 같은 것들이다.
사례 연구 — 정상 흐름은 통과했는데
앞의 조각들을 하나의 이야기로 이어보자. 앞서 본 비밀번호 재설정 유즈케이스가 그대로 등장한다.
상황. 소셜 로그인(카카오·구글) 기능이 추가된 릴리즈였다. 신입 QA는 새로 추가된 소셜 로그인을 꼼꼼히 테스트했다. 카카오로 가입, 구글로 가입, 이미 있는 이메일과 겹칠 때, 소셜 계정 연동 해제까지 — 전부 통과했다. 기존 기능인 비밀번호 재설정은 회귀 테스트 목록에 있었고, 역시 통과였다. 릴리즈.
2주 뒤. 고객센터에서 문의가 쌓이기 시작했다.
"비밀번호 찾기를 눌렀는데 메일이 안 와요. 스팸함도 봤어요."
재현 시도. QA가 자기 테스트 계정으로 해봤다. 메일이 온다. 다른 계정으로 해봤다. 역시 온다. 재현이 안 된다. 그런데 문의한 사용자 이메일로 확인해보니 — 전부 카카오나 구글로 가입한 계정이었다.
원인. 소셜 가입 계정에는 애초에 비밀번호가 없다. 재설정 요청이 들어오면 서버는 "비밀번호 레코드가 없음"으로 판단해 메일 발송을 건너뛴다. 그런데 화면은 보안 정책상 계정 존재 여부를 노출하지 않기 위해 언제나 "메일을 보냈습니다"라고 응답한다. 두 정책이 각각은 옳은데, 겹치는 자리에서 사용자가 영원히 오지 않는 메일을 기다리는 상태 가 만들어졌다.
무엇을 놓쳤는가. 유즈케이스 문서로 돌아가보면 답이 보인다.
| 문서에 적힌 것 | 실제 세계 |
|---|---|
| 행위자: "비밀번호를 잊은 사용자" | 이메일 가입자 / 소셜 가입자 / 둘 다 연동한 사용자 |
| 사전조건: "가입된 계정이 있다" | 가입돼 있지만 비밀번호가 없는 계정이 존재한다 |
| 대안 흐름: 링크 만료 | 링크 만료 / 소셜 계정으로 로그인하기 |
행위자를 한 종류로 뭉뚱그린 것 이 출발점이었다. 소셜 로그인이 추가되면서 행위자가 사실상 세 종류로 쪼개졌는데, 비밀번호 재설정 유즈케이스는 갱신되지 않았다. QA는 "기존 기능이니 회귀 테스트만 하면 된다"고 판단했고, 회귀 테스트는 기존 유즈케이스의 정상 흐름 을 그대로 따라갔다. 정상 흐름은 아무 이상이 없었다.
어떻게 발견할 수 있었는가. 이 결함을 잡아내는 질문은 화려하지 않다.
"이번에 사용자가 계정을 만드는 방법이 하나 늘었는데, 계정을 다루는 다른 기능들의 행위자도 같이 늘어난 것 아닌가요?"
신규 기능이 기존 유즈케이스의 사전조건이나 행위자를 바꾸는지 를 확인하는 것 — 이것이 유즈케이스 관점의 회귀 테스트다. 바뀐 화면만 다시 보는 것이 회귀 테스트가 아니다.
결함 리포트에 무엇을 더 썼는가. QA는 같은 원리로 터질 다른 곳까지 함께 적었다.
함께 확인 필요: 소셜 가입 계정의 ①비밀번호 변경 화면 진입 ②계정 삭제 시 비밀번호 확인 절차 ③연동 해제 후 로그인 수단이 0개가 되는 경우
세 번째가 특히 중요하다. 연동을 해제하면 소셜 로그인도 안 되고 비밀번호도 없어서 어떤 방법으로도 로그인할 수 없는 계정 이 만들어진다. 유즈케이스로 사고하면 결함 하나를 잡는 데서 끝나지 않고 같은 빈틈에서 나올 다음 결함까지 짚어줄 수 있다.
다른 기법과의 관계
유즈케이스 기반 테스트는 흔히 시스템·인수 레벨(모듈 1, 레슨 3)에서 쓴다 — 전체 흐름을 봐야 하기 때문이다. 흐름 안의 개별 단계(예: "새 비밀번호 입력"에서 8자 미만이면?)는 여전히 경계값 분석 같은 다른 기법으로 채운다. 즉 유즈케이스가 큰 뼈대 를 잡고, 다른 기법들이 그 뼈대 안의 세부 조건 을 채우는 관계다.
| 기법 | 유즈케이스와의 관계 |
|---|---|
| 동등분할·경계값 (레슨 1) | 흐름 안의 한 입력 필드 를 촘촘히 쪼갠다 |
| 상태전이 (레슨 3) | 유즈케이스가 긴 시간에 걸쳐 상태를 바꿀 때(주문 상태 등) 흐름을 상태도로 다시 그린다 |
| 결정테이블 (레슨 3) | 한 단계에서 여러 조건이 조합 될 때(등급×쿠폰×배송지) 그 단계만 표로 푼다 |
| 페어와이즈 (레슨 5) | 대안 흐름의 경로 조합 이 폭발할 때 대표 조합만 고른다 |
| 경험 기반 (레슨 8) | 문서에 없는 순서 깨기·엣지 상황을 채운다 |
상태전이와의 관계 를 특히 헷갈려 하는 경우가 많은데, 구분은 간단하다. 유즈케이스는 한 사람의 한 번의 여정 을 본다. 상태전이는 객체 하나가 여러 여정을 거치며 갖는 상태의 변화 를 본다. 주문 하나가 결제→준비→배송→완료로 가는 것은 상태전이이고, 그중 "사용자가 주문을 취소하는" 한 번의 여정이 유즈케이스다.
실무에서 왜 필요한가
값 단위 기법만으로 테스트 케이스를 짜면, 각 조건은 완벽히 검증되지만 정작 "실제 사용자가 처음부터 끝까지 이 기능을 쓸 수 있는가"는 놓칠 수 있다. 예를 들어 비밀번호 재설정의 "새 비밀번호 입력" 단계 자체는 완벽히 테스트했어도, 정작 "링크가 만료됐을 때 사용자가 다시 시도할 방법을 안내받는가"라는 흐름 자체가 빠져 있으면 사용자는 막다른 길에 갇힌다. 유즈케이스 기반 테스트는 이런 흐름 차원의 결함 을 잡는다.
흐름 결함은 값 결함보다 늦게, 비싸게 발견된다
값 결함은 대개 개발자의 단위 테스트나 QA의 첫 라운드에서 걸린다. 반면 흐름 결함은 여러 조각이 다 만들어진 뒤에야 드러난다. 위 사례처럼 두 기능이 각각은 옳은데 겹치는 자리에서 생기는 결함은, 두 기능이 다 완성되기 전에는 존재하지도 않는다.
여기에 하나가 더해진다. 흐름 결함은 사용자가 신고하지 않는다. 버튼이 안 눌리면 사용자는 문의한다. 하지만 "메일을 보냈습니다"라고 나온 뒤 메일이 안 오면, 상당수 사용자는 문의하지 않고 그냥 떠난다. 겉으로는 성공한 것처럼 보이기 때문이다. 그래서 흐름 결함은 지표에도 잘 안 잡히고, 발견됐을 때는 이미 오래 방치된 상태 인 경우가 많다.
E2E 자동화의 뼈대가 그대로 나온다
E2E(end-to-end) 는 "끝에서 끝까지" 라는 뜻이다. 화면 한 조각이 아니라 사용자가 실제로 밟는 전체 흐름(검색 → 담기 → 결제 → 완료)을 처음부터 끝까지 한 번에 돌려 보는 시험을 가리킨다.
E2E 자동화(모듈 13에서 다룬다) 시나리오를 짤 때 유즈케이스가 그대로 스크립트의 뼈대가 된다. 자동화는 긴 흐름을 매번 반복 실행하는 데 강하고, 유즈케이스는 그 긴 흐름의 정의 그 자체이기 때문이다.
우선순위도 자연스럽게 정해진다. 기본 흐름은 자동화 1순위 다 — 릴리즈마다 반드시 돌아가야 하고, 매번 손으로 하기엔 아깝다. 대안 흐름은 사용 비중이 큰 것부터 추가한다. 반면 예외 흐름 중 일부는 자동화가 어렵거나(외부 결제사 실패 유도 등) 비용에 비해 가치가 낮아 수동으로 남긴다. 유즈케이스로 정리해두면 "무엇을 자동화하고 무엇을 남길 것인가" 라는 논의를 감이 아니라 목록 위에서 할 수 있다.
팀이 같은 언어로 말하게 된다
유즈케이스는 QA만의 산출물이 아니라는 점도 실무 가치가 크다. "UC-PW-03이 실패했다"는 말은 기획자·개발자·QA가 같은 장면을 떠올리게 한다. 반면 "비밀번호 관련 테스트가 하나 깨졌다"는 말은 서로 다른 것을 상상하게 만든다.
릴리즈 판단에서도 마찬가지다. "기본 흐름은 전부 통과, 대안 흐름 1건 실패" 는 Go/No-Go 회의에서 바로 쓸 수 있는 문장이다. 실패 건수만 세는 것보다 훨씬 많은 정보를 담고 있고, 무엇보다 그 실패가 사용자에게 어떤 장면인지 를 즉시 알 수 있다.
채용시장에서의 위치
유즈케이스 기반 테스트는 ISTQB Foundation Level의 명세 기반 기법 항목에 포함되어 있어 자격증 시험에 직접 출제된다. 하지만 면접에서 더 자주 나오는 형태는 실기형 질문이다.
- "회원가입 기능을 테스트한다면 어디서부터 시작하시겠어요?"
- "정상 흐름과 예외 흐름을 나눠서 설명해보세요."
- "이 기능에서 대안 흐름을 세 개만 들어보세요."
첫 번째 질문에서 면접관이 보는 것은 테스트 케이스를 몇 개 대는지가 아니라 순서가 있는지 다. "먼저 사용자가 이 기능으로 달성하려는 목표를 정의하고, 정상 흐름을 한 줄로 그린 다음, 같은 목표에 도달하는 다른 경로와 도달하지 못하는 경로로 나눠 넓혀갑니다" — 이렇게 절차로 답하면 지식이 아니라 방법을 가진 사람으로 보인다.
세 번째 질문은 정상과 대안의 구분을 정확히 아는지 보는 질문이다. 여기서 "비밀번호를 틀린 경우"라고 답하면 예외와 대안을 섞고 있다는 신호가 된다. "소셜 로그인처럼 수단이 다른 경로" 를 예로 들면 구분을 이해하고 있다는 것이 바로 드러난다. 여기에 "그리고 대안 흐름으로 왔을 때 정상 흐름과 동일한 최종 상태가 되는지를 특히 봅니다"까지 덧붙이면 실무 경험이 있는 답으로 읽힌다.