유스케이스의 본질
- 유스케이스는 사용자의 관점에서 시스템의 동작을 명세하는 실용적인 방법. 유스케이스는 시스템에 의해 수행되는 일련의 액션들(a sequence of actions)이며, 이 액션들이 함께 시스템 사용자에게 가치를 주는 어떤 결과를 만들어 냄
- 각 유스케이스는 해당 유스케이스가 성공적으로 동작하기 위해 충족되어야 하는 사전조건(pre-conditions)을 가짐. 예를 들어, 정상적인 은행 계정과 자동입출금기(ATM) 없이는 현금 인출이 불가능
- 각 유스케이스는 해당 유스케이스가 완수된 후의 관측가능한 결과와 시스템 최종 상태인 사후조건(post-conditions)으로 종결된다. 예를 들어, 인출 후에는 은행 계정에서 인출된 금액 만큼이 차감되고 ATM이 다음 거래를 위한 준비가 되어 가용해야 함
- 유스케이스가 주 흐름(가장 가능성 높은 시나리오)를 가짐(예, ATM으로부터 성공적으로 현금 인출이 됨). 유스케이스가 또한 대안 흐름을 포함할 수도 있음(예, 사용자의 은행 카드를 인식 못하여 인출이 거부되거나, ATM에 충분한 현금이 없어서 인출이 거부되거나, 또는 은행 계좌 잔고가 부족해서 인출이 거부됨)
- 유스케이스가 공용/공통의 부분을 가지고 있을 수도 있음(예, 여러 유스케이스에서 재사용되는 일련의 단계들)
유스케이스와 테스팅
- 유스케이스 테스팅은 전통적 테스트케이스 설계 기법(예, 기능 명세 분석, 소프트웨어 경로 분석, 경계값 분석)과 다른 새로운 관점을 제공하고 타 기법에서 보기 어려운 테스트케이스들을 식별한다.
- 유스케이스가 시스템을 관통하는 “프로세스 흐름”을 기술하므로, 유스케이스로부터 도출된 테스트케이스는 시스템의 실 사용 동안의 프로세스 흐름에 있는 결함들을 발견하는데 유용하다. 또한 여러 다른 기능들의 상호작용과 간섭에 의해 야기된 통합 버그(기능을 개별적으로 테스팅 해서는 찾기 어려운 버그)를 찾는데 도움을 준다.
- 유스케이스 방법이 전통적 테스트케이스 설계 기법들을 대신하기 보다는 보완함
유스케이스 예
유스케이스명: 제품 선택하기
유스케이스 기술: 이 유스케이스가 신규 품목(a line item)을 추가하고 주문할 제품을 선택함으로써 발주서(a purchase order: PO)를 작성함. PO가 여러 품목을 포함할 수 있으며, PO 상의 각 품목은 해당 PO가 가는 납품업자(Vendor)의 특정 제품의 수량을 주문함(아래 그림 참조)
[발주 시스템의 예]
사전조건: 상태가 “진행 중”인 열려 있는 PO가 이미 존재해야 하며, 이 PO가 유효한 Vendor ID 번호와 유일한 PO 번호를 가져야 함. 사용자가 유효한 User ID#와 패스워드를 입력했으며, PO에 접근하여 품목을 추가/변경하는 것이 허용됨.
기존 PO 상의 품목 수가 25가 되어서는 안됨(조직의 비즈니스 정책이 PO당 품목 수를 25 이하로 제한). 제품 번호가 기존 각 품목 상에서 유일해야 함(하나의 PO 내에 중복 제품이 불가한 것도 비즈니스 정책).
시스템이 해당 납품업자의 정확한 제품 목록에 접근할 수 있어야 함.
사후조건: 해당 PO가 여전히 존재하고 열려 있어야 함. 이 PO로 신규 품목이 추가되었고(다음 순차 품목 번호가 할당됨), 이 품목을 위한 정확한 제품이 선택됨(유스케이스가 중도 포기되지 않은 경우라면).
시스템이 제품 선택 후의 다음 단계(동일 품목 상에 주문할 수량을 입력하고, 해당 주문을 위한 충분한 재고가 수중에 있는지 확인)로 이동할 수 있는 올바른 상태에 남아야 함.
제품 번호는 동일 PO 상의 다른 품목의 기존 제품 번호와 중복될 수 없으며, 선택된/입력된 제품이 해당 납품업자의 유효한 제품이어야 함.
만약 제품이 선택되지 않았다면(예, 사용자가 프로세스를 중도 포기) 원래의 PO가 그 애초 상태로부터 변경이 없어야 함.
적절한 경우 에러 메시지가 발행되고, 유스케이스가 실행된 후에 시스템이 다음 입력 명령어를 받아들일 준비 상태로 대기함.
이벤트 흐름: 간결성을 위해 아래 유스케이스가 완전하지는 않음(일부 대안들이 배제됨). 사용자 액션은 “U”로 시작하는 식별자가 주어지고, 시스템 액션은 “S”로 시작하는 식별자를 가짐. 아래 각 액션의 끝에 있는 괄호 안 식별자들은 이 유스케이스에서 가능한 다음 액션을 가리킴. 예를 들어, 사용자 액션 U1에 대응해 시스템이 액션 S1.1 또는 S1.2를 취할 수 있음
| 사용자 | 시스템 | |
| U1 PO로 새로운 품목이 추가되는걸 요청한다. [S1.1, S1.2] | S1.1 새 품목을 추가하고, PO 내에 다음 순차 품목 번호를 할당한다. [U2.1, U2.2]또는S1.2 새 품목이 추가될 수 없음을 명시한다(PO가 이미 25개 품목을 포함). 유스케이스로부터 빠져 나온다. | |
| U2.1 해당 PO가 가는 납품업자에 의해 공급되는 제품 목록을 요청한다. [S2]또는U2.2 해당 품목으로 특정 제품 번호를 직접 입력한다. [S3.1, S3.2] | S2 해당 납품업자를 위한 제품 목록을 제공한다. [U3.1, U3.2] | |
| S3.1 선택된/입력된 제품 번호가 유효한 것인지 검증한다. 사용자가 눈으로 검증할 수 있도록 이 제품에 대한 기술을 화면에 표시한다. [U4]또는S3.2 입력된 제품 번호를 거부한다. [U2.1, U2.2] | ||
| U3.1 납품업자의 목록으로부터 의도한 제품을 선택한다. [S3.1, S3.2]또는U3.2 납품업자의 제품 중에 요구에 맞는 적합한 것이 없다고 결정한다. 사용자가 프로세스를 중단한다. 유스케이스로부터 빠져 나온다. | ||
| U4 화면에 표시된 반응과 사용자가 주문하려고 의도했던 것을 비교함으로써 올바른 제품이 선택/입력 되었음을 확인한다. [S4.1, S4.2] | S4.1 (목록을 통해 선택된 또는 직접 입력된) 제품 번호가 동일 PO의 다른 품목 상의 어떤 제품 번호와도 중복되지 않음을 검증한다. 유스케이스로부터 빠져 나온다.또는S4.2 제품 번호가 중복이라면, 이를 거부한다. [U2.1, U2.2] |
테스트케이스를 어떻게 도출하는가
유스케이스로부터 테스트케이스를 도출하기에 앞서 정확성과 완전성 측면에서 유스케이스를 세심히 검토하는 것이 중요. 만약 모호함, 비일관성, 누락 등이 발견되면 유스케이스 개발자가 이를 반영할 필요가 있음
테스트케이스는 유스케이스의 경로를 횡단함으로써 도출됨. 먼저 유스케이스의 주 흐름 경로(가장 많이 사용될 가능성이 높은 경로)를 찾는다. 위 예에서는 PO에 새 품목을 추가하고 목록에서 올바른 제품을 선택하는 프로세스가 여기 해당됨(이 시나리오가 정확하게 동작하는지 확인하기 위해 아래와 같은 테스트케이스를 작성)
첫 테스트케이스를 얻은 후에는 주요 대안 경로(사용자가 해당 유스케이스에서 취할 수 있는 다른 경로들)를 찾는다. 현실에서 대안의 수가 대개 무수하므로 사용 빈도, 리스크, 복잡성 등에 기반해 가장 유용한 것들만 선택하고, 이 선택된 경로들 각각을 위한 테스트 케이스를 생성한다.
| 테스트케이스명 | 제품 선택하기 – 정상적 주 흐름 프로세스 |
| 유스케이스명 | 제품 선택하기 |
| 실행될 유스케이스 경로 | [U1 -> S1.1 -> U2.1 -> S2 -> U3.1 -> S3.1 -> U4 -> S4.1] |
| 입력 데이터 | Product ID# 554875(바하마 정어리, 6 온스 크기) |
| 초기 조건 | PO # 6135527가 이미 열려 있고 Vendor ID# 42296를 위해 표시된다.User ID# 443이 이 PO 상에서 작업하는 것이 허용된다.이 PO에 이미 7개 품목이 붙어 있다. |
| 테스트 단계 | 진행에 앞서 초기 조건이 충족되었는지 확인한다.위에 제시된 유스케이스의 단계들을 따라 간다.실제 결과를 아래의 예상 결과와 비교한다.테스트 로그에 테스트케이스 ID#, 날짜와 시간, 실제 결과를 기록한다. |
| 예상 결과 | PO # 6135527가 여전히 열려 있고 Vendor ID# 42296가 표시된다.사용자 ID# 443이 해당 PO 상에서 작업하는 것이 여전히 허용된다.이 PO에 이제 8개의 품목이 붙어 있다.바하마 정어리 6온스 크기의 새로운 품목이 만들어졌다.새 품목에 품목 번호 8이 할당되었다.시스템이 다음 활동(주문할 바하마 정어리의 수량 설정)으로 넘어갈 준비가 되어 있다. |
아래 그림에서 검은 화살표가 위 테스트케이스에 의해 실행되는 주 흐름 유스케이스 경로를 나타낸다.
[모든 잠재적 사용자 액션과 시스템 액션을 보여주는 유스케이스 이벤트 흐름]
부정적 테스트케이스 예
뭔가 잘못될 수 있는 경우(예, 입력 데이터가 유효하지 않거나 유스케이스의 사전조건이 충족되지 않는 상황)도 고려해야 함
부정적 테스팅을 위한 두 가지 가능성이 존재:
1) 유효하지 않은 사용자 액션을 포함하는 유스케이스의 적법한 경로가 실행되도록 하는 테스트케이스 생성. 사용자가 입력한 제품 번호가 유효하지 않아 거부되는 아래의 부정적 테스트케이스 예가 여기에 해당됨(유스케이스에서 단계 S3.2)
2) 유스케이스에 제시되지 않은 입력을 시도하는 테스트케이스 생성. 유스케이스 사전조건을 의도적으로 위반하는 경우 또는 어떤 단계에서 예상 못한 잘못된 입력이 있는 경우 등이 여기 포함됨. 예를 들어, PO 상태가 “진행 중”이 아니고 “닫힘” 같은 뭔가 다른 상태라면 어떻게 되는가? 이 PO에 여전히 새 품목을 추가할 수 있는가?
아래의 부정적 테스트케이스 예가 유스케이스를 횡단하는 완전한 경로를 실행하지는 않는다. 즉, 단계 S3.2 이후에 여전히 출구 전략이 필요. 예, [U2.1 -> S2 ->U3.2]
| 테스트케이스명 | 제품 선택하기 – 유효하지 않은 제품 코드 입력 |
| 유스케이스명 | 제품 선택하기 |
| 실행될 유스케이스 경로 | [U1 -> S1.1 -> U2.2 -> S3.2] |
| 입력 데이터 | Product ID# 545875(바하마 정어리, 6 온스 크기)(사실 정확한 데이터는 Product ID# 554875) |
| 초기 조건 | PO # 6135527가 이미 열려 있고 Vendor ID# 42296를 위해 표시된다.User ID# 443이 이 PO 상에서 작업하는 것이 허용된다.이 PO에 이미 7개 품목이 붙어 있다.Product ID# 545875가 해당 납품업자의 유효한 제품 번호가 아니다. |
| 테스트 단계 | 진행 전에 초기 조건이 충족되었는지 확인한다.위에 제시된 대로 유스케이스를 횡단하는 단계들을 따라 간다.실제 결과를 아래의 예상 결과와 비교한다.테스트 로그에 테스트케이스 ID#, 날짜와 시간, 실제 결과를 기록한다. |
| 예상 결과 | PO # 6135527가 여전히 열려 있고 Vendor ID# 42296가 표시된다.User ID# 443이 이 PO상에서 작업하는 것이 여전히 허용된다.동일한 7개 품목이 여전히 이 PO에 붙어 있다.추가된 새로운 품목이 없다.에러 메시지 “Invalid Product ID#: Please re-enter or abort.”가 표시된다.시스템이 다음 활동(예, 다음 품목 추가나 또는 PO 닫기 같은 기타 다른 액션)으로 넘어갈 준비가 되어 있다. |
리스크 우선순위화(Risk Prioritization)
- 위의 간단한 유스케이스 예도 충분히 분석을 하면 십여 개의 테스트케이스가 도출될 수 있음. 즉, 구축할 수 있는 테스트케이스 수가 대개는 감당하기 버거울 정도로 많다.
- 보통은 모든 테스트케이스를 일일이 실행할 시간이 없으며, 일부 테스트케이스는 실제 그럴만한 가치가 없기도 하다.
- 테스트케이스를 구축하고 실행하는데 드는 비용을 결함을 발견할 가능성(또한 해당 결함의 중요도)과 견주어 가늠하면 사용하지 않을 테스트케이스를 선별해 낼 수 있음
- 유스케이스에서 자주 쓰이고 중요하고 복잡한 경로는 여러 테스트케이스에 의해 실행되어야 하고, 반면 사용 빈도와 리스크가 낮고 단순한 경로는 단일 테스트케이스에 의해 커버되거나 또는 시간 및 자원 제약으로 인해 테스트 되지 않을 수도 있다.
어떤 테스트케이스가 커버되지 못했는가?
- 완벽한 테스트케이스 설계 기법이 있을 수 없으며, 따라서 일부 테스트케이스가 포함되지 못하게 된다. 유스케이스가 다루지 않는 일부 영역들이 있기 때문에 위 샘플 유스케이스의 분석에서도 중요한 테스트케이스들이 일부 빠져 있음
- 이렇게 누락된 테스트케이스의 예를 두 가지만 들어보자면:
1) PO에 품목을 추가하려 하는데 데이터베이스가 이미 물리적으로 가득 차 있다면 무슨 일이 생기나?
2) 다른 워크스테이션에서 작업 중인 두 명의 사용자가 동시에 동일 PO로 품목을 추가하려 하면 무슨 일이 생기나? - 이런 테스트케이스를 식별하기 위해 테스트케이스 설계의 동료 검토(a peer review)를 수행하고, 또한 유스케이스 분석과 다른 테스트케이스 설계 기법(예, 원인-결과 그래프, 상태 전이 다이어그램, 통계적 샘플링, 직교 배열)을 균형 있게 활용할 필요가 있다.