블랙박스 테스트 설계 기법 4가지
1️⃣ Equivalence Partitioning and Boundary Value Analysis
2️⃣ Decision Table and State Transition Testing
3️⃣ Scenario Testing
1️⃣ Equivalence Partitioning and Boundary Value Analysis
동등 분할 및 경계 값 분석
제목을 보고 어떤 내용일지 먼저 생각해보자.
테스트 설계는 테스트를 좀 더 효율적으로 수행하기 위한 방법이다. 이러한 설계 방법 중에서 동등 분할 방식 및 경계 값 분석을 통해 테스트를 설계하고자 한다. 그렇다면 이 방법이 무엇인지 알아보도록 한다.
동등 분할 (Equivalence Partitioning)
동등 분할은 말 그대로 무언가를 나눈다, 즉 구간을 나눈다는 의미이다. 정의를 보면, 입력 데이터를 동일 동작이 예상되는 동등 클래스(Equivalent Class)로 나누는 것이다. 같은 구간 안에서는 동일한 동작을 하기 때문에, 전체 클래스를 테스트하는 것이 아닌 각 클래스의 대표값 하나 혹은 두 개를 선택하여 테스트하는 방식이다.
예시 - 성적 관리 기능
성적을 부여할 때 점수 구간에 따라 학점을 부여한다고 가정하자.
이 4개의 구간이 각각의 동등 클래스가 된다. 어떤 입력값을 넣든 해당 구간에 맞는 학점이 출력되는 동일한 동작을 하게 된다. 각 클래스에서 대표값을 선정하면 50점, 75점, 85점, 95점이 된다. 이를 기준으로 예상 출력값과 실제 실행 결과를 비교를 해보자.
예상 출력값은 코드를 보고 만드는 것이 아니다. 블랙박스 테스트의 요구사항이나 설계 스펙에 미리 명시되어 있어야 하는 부분이며, 스펙을 통해 테스트 케이스를 만들 수 있다.
실제로 소프트웨어를 동적으로 실행하면서 점수를 입력해보고 결과를 확인한다. 예상 출력값과 실행 결과가 일치하는지를 보게 되며, 불일치하면 그 부분이 결함/버그가 된다. 프로그램을 잘못 만든 것이거나, 스펙을 잘못 작성한 것이다.
클래스 커버리지
여기서 중요한 개념이 클래스 커버리지이다. 위 예시에서 성적 관리는 4개의 클래스로 나뉘었다. 요구사항을 100% 만족하는지 테스트하려면 4개의 클래스를 모두 테스트해야 하며, 이 경우 클래스 커버리지는 100%가 된다. 만약 테스터가 테스트 케이스를 3개만 만들었다면 커버리지는 75%가 된다. 일반적으로 요구사항은 100% 커버리지를 만족해야 한다.
예시 - 택배 예약 시스템
택배 예약 시스템에 입력되는 변수 몇 가지를 생각해보자. 택배 무게, 배송 지역, 배송 기간(익일/일반), 이러한 입력 변수들에 대해 동등 분할을 시행하고자 한다. 이때 클래스 커버리지 100%를 만족하는 최소 개수의 테스트 케이스를 작성해보자.
참고로 테스트 케이스가 많아질수록 좋은 것이 아니다. 테스트의 커버리지를 높이는 것이 더 중요하며, 케이스 개수를 줄이면서도 커버리지를 높이는 것이 핵심이다. 요구사항 명세서에 명시된 동등 클래스를 확인할 수 있다. 택배 무게는 5개, 배송 지역은 3개, 배송 기간은 2개의 클래스로 나뉘며 총 10개의 클래스가 존재한다. 이 10개의 클래스를 만족하는 최소 개수의 테스트 케이스를 구성하면 오른쪽과 같은 결과가 나온다.
택배 무게 5개의 클래스 대표값을 임의로 넣고, 배송 지역 A, B, C 세 클래스를 순서대로 배치한다. 배송 기간은 2개의 클래스를 만족해야 하므로, 노란색으로 표시된 영역처럼 임의로 값을 넣어 커버리지를 채울 수 있다.
이렇게 하면 전체 클래스 10개를 테스트 케이스 5개만으로 모두 커버하게 되어, 클래스 커버리지 = 10/10 × 100% = 100% 를 달성할 수 있다. 이것이 바로 동등 분할의 실제 적용 방식이다.
경계 값 분석 (Boundary Value Analysis)
경계 값 분석은 경계값을 기준으로 테스트하는 기법이다. 데이터에는 항상 시작과 끝이 존재하는데, 그 시작과 끝 주변에서 오류가 많이 발생한다는 점에 착안한 기법이다.
예를 들어 컵이 120도까지 열을 견딜 수 있다고 하면, 120도 이상이 되었을 때 컵이 깨질 수 있다. 이처럼 한계 범위를 벗어나는 경계 주변에서 문제가 많이 발생한다는 것이 이 기법의 핵심 아이디어이다.
동등 분할과 마찬가지로 입력 데이터를 동일 동작이 예상되는 동등 클래스로 분할하되, 동등 분할이 클래스 내의 대표값을 선정하는 것과 달리, 경계 값 분석은 각 클래스의 상한 및 하한 경계 값을 선택하여 테스트한다.
예시 - 성적 관리 기능
성적 관리에서 허용 범위는 0점~100점이다. 이 양 끝값을 기준으로 경계에 해당하는 값들을 테스트한다. 65점, 70점처럼 중간값이 아닌, 양 끝에서 살짝 벗어나는 값들을 중심으로 테스트한다. 1번과 5번의 경우 예상 출력값은 "점수 범위 초과" 경고여야 하지만, 실행 결과는 F와 A로 전혀 다른 값이 나왔다. 예상과 실행 결과 간에 차이가 발생했으므로 이는 Defect, 즉 버그가 된다.
테스트는 효율을 목표로 한다. 모든 경우를 테스트할 수는 없기 때문에, 경계 값 분석은 경계 중심으로 테스트해보자는 중요한 아이디어를 담고 있다.
[참고] 경계 값 설정 기준
경계 값을 설정할 때는 데이터의 형태에 따라 설정 기준이 달라질 수 있다. 크게 세 가지 경우로 나누어 살펴보자.
입력 조건이 값의 범위를 명시하고 있는 경우 : 성적 데이터처럼 특정 범위를 가지고 있거나, 온도의 범위와 같이 a 이상 b 이하로 범위가 정해져 있는 경우이다.
입력값이 최대/최소와 같이 특정 값을 명시하고 있는 경우 : 범위가 아닌 최댓값 또는 최솟값이 명시되어 있는 경우이다.
입력이 배열, 순서 파일, 리스트와 같이 순서를 가지고 있는 경우 : 데이터가 순서를 가진 구조로 이루어져 있는 경우이다.
각각의 경우에 어떻게 경계 값을 설정하는지 이어서 알아보자.
경계 값 설정 기준별 상세 내용
1) 입력 조건이 값의 범위를 명시하고 있는 경우
입력값이 0~10과 같이 값의 범위가 명시된 경우, 범위를 약간씩 벗어나는 값을 테스트 케이스로 선정한다. 범위가 a부터 b 사이라고 했을 때 경계는 a와 b이므로, a-1, a+1, b-1, b+1을 중심으로 테스트한다. 살짝 벗어나는 범위부터 오버플로우가 발생하기 때문이다.
2) 입력값이 최대/최소와 같이 특정 값을 명시하고 있는 경우
최댓값보다 약간 큰 값(max+1), 최솟값보다 약간 작은 값(min-1), 그리고 최댓값과 최솟값 자체를 중심으로 경계 테스트를 수행한다.
3) 입력이 배열, 순서 파일, 리스트와 같이 순서를 가지고 있는 경우
순서의 집합이 여러 개인 경우로, 첫 번째 요소와 마지막 요소를 중심으로 테스트 케이스를 선정한다. 예를 들어 배열이 {1, 2, 3, 4, 5, 6, 7, 8, 9}인 경우 Array[0]과 Array[9]를 중심으로 테스트한다. 배열의 크기가 10일 때 Array[11]에 접근하면 out of bound, 즉 범위를 벗어났다는 예외 오류가 발생하게 되며, 이를 중심으로 테스트를 수행하는 것이다.
이처럼 경계 값 설정 기준은 데이터의 형태에 따라 조금씩 달라진다는 점을 기억해두자.
[참고] 2-Value 경계 값 분석
2-Value 경계 값 분석은 클래스의 상한과 하한에서 유효한 경계 값을 먼저 찾고, 그 경계에 가장 가까운 비유효한 경계 값을 선택하여 테스트하는 방식이다. 즉, 상한쪽에 2개, 하한쪽에 2개의 값을 선정하여 테스트한다.
예시를 통해 살펴보자. 80~89점 구간의 성적은 B이다. 이 클래스의 경계는 80과 89가 된다.
하한 경계에서는 유효한 경계 값인 80을 먼저 선정하고, 경계를 벗어난 가장 가까운 비유효한 값인 79를 함께 선정한다.
상한 경계에서는 유효한 경계 값인 89를 선정하고, 경계를 벗어난 가장 가까운 비유효한 값인 90을 함께 선정한다.
이렇게 하한에서 {79, 80}, 상한에서 {89, 90}, 총 4개의 값을 경계 중심으로 테스트하는 것이 2-Value 경계 값 분석의 핵심 개념이다.
예시 - 택배 예약 시스템의 경계 값 분석 적용
앞서 5개의 클래스로 나뉜 택배 무게에 대해 2-Value 경계 값 분석을 적용해보자. 각 클래스의 하한과 상한에서 유효한 값과 가장 가까운 비유효한 값을 각각 선정한다.
예를 들어 0 초과 3 미만 구간에서 하한쪽 유효한 값은 경계 안에 있어야 하므로 0.1이 되고, 가장 가까운 비유효한 값은 0이 된다. 상한쪽에서 유효한 값은 3보다 작아야 하므로 2.9가 되고, 경계를 벗어난 비유효한 값은 3이 된다.
또한 7 이상 15 미만 구간에서 하한쪽 유효한 값은 7이고 가장 가까운 비유효한 값은 6.9이다. 상한쪽 유효한 값은 15 미만이므로 14.9가 된다.
이처럼 각 클래스의 경계를 중심으로 하한과 상한의 2-Value 방식으로 테스트하면 경계 값을 중심으로 효율적인 테스트가 가능하다. 지금까지 동일한 동등 클래스 개념을 활용하여 동등 분할과 경계 값 분석, 두 가지 테스트 설계 기법에 대해 살펴보았다.
2️⃣ Decision Table and State Transition Testing
결정 테이블 테스팅 (Decision Table Testing)
결정 테이블 테스팅은 입/출력 값이 True/False로 결정될 수 있는 경우, 입력 조건의 모든 조합에 대해 각각의 조합을 기준으로 테스트하는 방식이다.
결정 테이블 테스팅의 예시 - 로그인 기능
로그인 기능을 예제로 살펴보자. 사용자는 아이디와 비밀번호를 입력해야 하며, 각각 유효한 경우와 그렇지 않은 경우가 존재한다. 이에 따른 예상 출력값은 로그인 성공, 잘못된 아이디 경고, 잘못된 비밀번호 경고로 나뉜다.
케이스 1은 유효한 아이디와 비밀번호를 모두 입력한 경우로, 로그인이 성공해야 하므로 True이고 나머지 경고는 모두 False여야 한다.
케이스 2는 유효한 아이디를 입력했지만 비밀번호가 유효하지 않은 경우이다. 로그인은 실패해야 하고, 아이디는 유효하므로 아이디 경고는 False, 비밀번호 경고는 True가 나와야 한다.
케이스 3과 4는 아이디가 유효하지 않은 경우이다. 이미 아이디가 잘못 입력되었기 때문에 잘못된 비밀번호 경고는 발생 자체가 불가능하다. 시스템마다 조금씩 다를 수 있지만, 여기서는 그렇게 동작한다고 가정한다.
이처럼 입/출력에 대해 True인 경우와 False인 경우의 케이스를 나누어 모든 조합을 기준으로 테스트하는 것이 결정 테이블 테스팅이다.
예시 - 쇼핑몰 시스템의 상품 검색 기능에 대한 결정 테이블 테스팅 적용 (1/2)
쇼핑몰의 상품 검색 기능은 사용자가 상품명 또는 상품 번호를 구분 인자로 선택하고, 검색어 키워드를 입력하면 해당 상품을 표시하는 기능이다. 이 기능에 결정 테이블 테스팅을 적용하여 테스트 케이스를 만들어보자.
입력값은 크게 두 가지이다. 콤보박스에서 선택하는 구분 인자(상품명/상품 번호)와 검색어 키워드이다. 이 두 가지 입력값에 대해 유효한 경우와 유효하지 않은 경우를 True/False로 나누면 총 4가지 조합이 나온다.케이스 1은 유효한 구분 인자를 선택하고 유효한 키워드를 입력한 경우로, 검색 결과가 표시되어야 하므로 True이고 잘못된 키워드 경고는 False이다.
케이스 2는 유효한 구분 인자를 선택했지만 유효하지 않은 키워드를 입력한 경우로, 검색 결과는 False이고 잘못된 키워드 경고가 True로 나와야 한다.
케이스 3과 4는 구분 인자가 유효하지 않은 경우인데, 이는 발생할 수 없는 조합이다. 구분 인자는 사용자가 직접 타이핑하는 것이 아니라 콤보박스 형태로 상품명 또는 상품 번호 중 하나를 무조건 선택하게 되어 있기 때문이다. 따라서 유효하지 않은 구분 인자가 입력되는 케이스 자체가 발생할 수 없다.
결국 유효한 테스트 케이스는 1번과 2번이며, 이 두 가지를 기준으로 테스트 케이스를 작성하게 된다.
예시 - 쇼핑몰 시스템의 상품 검색 기능에 대한 결정 테이블 테스팅 적용 (2/2)
앞서 도출한 유효 구분과 유효 키워드 2가지 조합에 실제 데이터를 대입하여 테스트 케이스를 작성해보자.
1번과 2번은 유효한 구분과 유효한 키워드를 입력한 경우로, 각각 상품명과 상품번호에 대한 검색 결과가 정상적으로 표시된다. 3번은 유효한 구분을 선택했지만 특수 기호가 포함된 키워드를 입력한 경우이고, 4번은 영문이 허용되지 않는 상품번호 검색에 영문이 포함된 키워드를 입력한 경우로, 각각 잘못된 키워드 경고가 출력되어야 한다.
이처럼 True/False로 유효한 경우와 그렇지 않은 경우를 구분하고, 실제 데이터를 대입하여 테스트 케이스를 만들어 검증하는 방식이 결정 테이블 테스팅이다.
상태 전이 테스팅 (State Transition Testing)
상태 전이 테스팅은 시스템이 여러 상태를 가질 때, 그 상태가 이벤트에 의해 바뀌는 것을 중심으로 테스트하는 기법이다. 예를 들어 ON/OFF 상태, READY/RUNNING 상태처럼 시스템이 특정 상태를 가지고, 이벤트에 의해 상태가 변할 때 이를 "전이(Transition)"가 발생한다고 표현한다. 이러한 상태와 이벤트, 전이의 조합을 선택하여 테스트하는 방식이다.
상태 전이 테스팅 예시 - 스위치 ON/OFF 기능
스위치 ON/OFF 기능을 생각해보자. ON과 OFF, 2가지 상태가 존재하며 스위치를 한 번 누르면 ON, 한 번 더 누르면 OFF가 된다.
이를 상태 전이도로 표현하면 OFF 상태에서 스위치를 켜는 이벤트가 발생하면 ON 상태가 되고, 반대로 스위치를 끄는 이벤트가 발생하면 OFF 상태로 돌아온다. 전이의 방향은 OFF → ON, ON → OFF, 2가지로 표현된다.
이를 테스트 케이스로 작성하면 다음과 같다.
테스트는 시작 상태에서 이벤트를 주었을 때 종료 상태가 올바르게 전이되는지를 확인하는 것이다. 이름만 들으면 어렵게 느껴질 수 있지만 원리는 간단한 테스팅 기법이다. 다만 실제 시스템의 상태는 훨씬 복잡하기 때문에 테스트 케이스의 수도 그만큼 많아지게 된다.
[참고] 전이 스위치(State Transition) 레벨 N 예시
전이 스위치 레벨은 상태가 전이(Transition)되는 횟수에 따라 레벨 0부터 N까지로 표현하는 방식이다. 이때 주의할 점은 레벨이 0부터 시작한다는 것이다. 상태가 1번 바뀌면 레벨 0, 2번 바뀌면 레벨 1이 되며, 전이 횟수에서 -1을 하면 전이 스위치 레벨이 된다.
상태 전이도에는 OFF, READY, IDLE, RUN 4개의 상태가 존재하며, 6개의 이벤트에 의해 전이가 발생한다. 이를 전이 트리로 표현하면 OFF 상태에서 이벤트 ①에 의해 READY로 전이되고, READY 상태에서는 이벤트 ②로 OFF, 이벤트 ③으로 IDLE, 이벤트 ⑤로 RUN으로 전이될 수 있다. 이처럼 각 상태에서 갈 수 있는 경우들을 계층적으로 표현한 것이 전이 트리이다.
전이 스위치 레벨 0은 상태가 1번 전이된 경우로, OFF→READY, READY→OFF, IDLE→RUN, RUN→READY 등이 해당된다. 전이 스위치 레벨 1은 상태가 2번 전이된 경우로, READY→RUN→READY, READY→OFF→READY 등이 해당된다.
택배 예약 시스템의 상태 전이 테스팅 적용 (1/2)
택배 예약 시스템을 예시로 상태 전이 테스팅을 적용해보자. 택배 예약 시스템의 상태는 크게 4가지로 나뉜다.
대기 : 택배 접수 전의 초기 상태
택배 접수 : 사용자가 택배를 선택한 상태
무게 측정 : 접수 확인 후 무게를 측정하는 상태
운송장 출력 : 무게 측정 후 운송장을 출력하는 상태
이 4개의 상태는 택배 선택, 접수 취소, 접수 확인, 무게 측정 취소, 운송장 확인, 출력 취소, 접수 완료 등의 이벤트에 의해 전이(Transition)가 발생한다.
여기서 전이 스위치 레벨 1을 만족하는 테스트 케이스를 작성해보자. 전이 스위치 레벨 1은 전이가 2번 발생한 경우이다. 예를 들어 대기 → 택배 접수 → 무게 측정과 같이 2번의 전이가 이루어지는 경우가 이에 해당한다. 만약 전이 스위치 레벨 2를 만족하려면 전이가 3번 발생해야 하므로, 위 과정에서 운송장 출력까지 추가된 대기 → 택배 접수 → 무게 측정 → 운송장 출력이 해당된다. 여기서는 전이 스위치 레벨 1을 만족하는 테스트 케이스를 작성해 볼 예정이다.
택배 예약 시스템의 상태 전이 테스팅 적용 (2/2)
앞서 살펴본 상태 전이도를 전이 트리로 표현해보자. 대기, 택배 접수, 무게 측정 상태에서 출발하여 전이 스위치 레벨 1을 만족하는 전이 트리이다.
대기 상태에서 사용자가 택배 선택 이벤트를 누르면 택배 접수 상태가 된다. 여기서 접수 취소를 누르면 다시 대기 상태로 돌아가고, 접수 확인을 누르면 무게 측정 상태로 이동한다. 택배 접수 상태에서 접수 취소를 누르면 대기로 가고, 다시 택배 선택을 누르면 택배 접수 상태로 돌아온다. 또한 택배 접수 상태에서 접수 확인을 누르면 무게 측정으로 가고, 무게 측정 취소를 누르면 다시 택배 접수 상태로 돌아간다.
전이 스위치 레벨 1을 만족하려면 전이가 2번 발생해야 하므로, 1st 상태 → 이벤트 → 2nd 상태 → 이벤트 → 3rd 상태의 흐름으로 테스트 케이스를 작성하면 된다.
각각의 행 하나하나가 하나의 테스트 케이스가 된다. 이처럼 상태 전이 테스팅은 시스템이 복잡한 상태를 가질 때, 그 상태들이 이벤트에 의해 전이되는 과정을 중심으로 테스트 케이스를 체계적으로 만들어 검증하는 기법이다.
3️⃣ Scenario Testing
시나리오 테스팅 (Scenario Testing)
시나리오 테스팅은 마지막으로 살펴볼 블랙박스 테스팅 기법이다. 이름에서도 알 수 있듯이, 시스템을 실제로 사용하는 사용자의 입장에서 테스트를 설계하는 방식이다.
사용자가 시스템을 사용하는 다양한 경우들이 곧 시나리오가 된다. 이 흐름을 기본 흐름과 대체 흐름으로 나누어 테스트한다. 기본 흐름이란 가장 정상적으로 수행되는 흐름을 뜻하고, 대체 흐름이란 사용자가 잘못 선택하거나 예외적인 상황이 발생하는 케이스들을 의미한다. 모든 흐름이 항상 정상적이지는 않기 때문에, 이러한 다양한 흐름을 시나리오 형태로 정의하여 테스트해보는 것이다.
예시 — 비밀번호 변경 기능
비밀번호 변경 기능을 예로 들어보자. 사용자가 정상적으로 비밀번호를 변경하는 경우가 기본 흐름이 된다. 대체 흐름으로는 다음과 같은 케이스들이 있다.
기존 비밀번호를 잘못 입력하는 경우
신규 비밀번호를 8자 미만으로 입력하는 경우
신규 비밀번호를 기존 비밀번호와 동일하게 입력하는 경우
신규 비밀번호와 재입력한 비밀번호가 일치하지 않는 경우
비밀번호 변경이라는 기능 하나만 보더라도 이처럼 다양한 흐름이 존재한다. 시나리오 테스팅은 이러한 케이스들을 모두 시나리오로 만들어 테스트해보는 방식이다.
시나리오 테스팅은 주로 최종 사용자 입장에서 테스트하는 인수 테스트나 시스템 테스트 단계에서 일반적으로 적용된다.
ATM 시스템의 현금 인출 기능에 대한 시나리오 테스팅 적용 (1/4)
ATM 시스템의 현금 인출 기능에 시나리오 테스팅을 적용해보자. 이때 중요한 것은 기본 흐름과 대체 흐름을 시나리오로 도출하는 것이다.
이 시나리오는 어디서 나올까? 당연히 사용자의 요구사항을 정의한 문서, 예를 들어 Use Case 정의서, Description, 요구사항 명세서 등에 명시되어 있으며, 이를 기반으로 테스트를 수행한다.
현금 인출 기능에서 발생할 수 있는 시나리오는 다음과 같다.
기본 흐름은 성공적으로 현금을 인출하는 경우이다. 대체 흐름으로는 A은행 카드를 넣어야 하는데 B은행 카드를 넣거나 현금 인출이 허용되지 않은 카드를 사용하는 경우, 비밀번호 오류가 3회 발생하여 거래가 정지되는 경우, 출금 대신 입금이나 송금을 선택하는 경우, ATM 기기의 잔액이 부족한 경우, 1일 한도를 초과하는 경우, 고객 계좌 잔액이 부족한 경우 등이 있다. 이 외에도 다양한 케이스가 존재할 수 있으며, 이러한 시나리오들을 요구사항 정의 문서에서 도출하여 테스트 케이스를 작성해 볼 것이다.
ATM 시스템의 현금 인출 기능에 대한 시나리오 테스팅 적용 (2/4)
앞서 도출한 시나리오를 이벤트 다이어그램으로 도식화한 예제이다. 다이어그램에서 U는 사용자(User), S는 시스템(System)을 의미한다.
기본 흐름은 다음과 같다. 사용자가 카드를 삽입하면(U1) 시스템이 카드를 승인하고(S1.1), 사용자가 비밀번호를 입력하여(U2) 정확히 일치하면 시스템이 승인한다(S2.1). 이후 사용자가 출금을 선택하고(U3.1) 출금액을 입력하면(U4) 시스템이 적절한 현금을 인출한다(S4.1). 그 다음 현금 지급(S5) → 잔액 표시(S6) → 영수증 출력(S7) → 카드 배출(S8) → 사용자 카드 제거(U5) 순으로 흐름이 이어지며 종료된다.
대체 흐름으로는 다음과 같은 케이스들이 발생할 수 있다.
카드 삽입 시 유효하지 않은 카드인 경우 시스템이 카드를 거부한다(S1.2).
비밀번호가 부정확한 경우(S2.2) 재입력 기회가 주어지며, 3회 부정확할 경우(S2.3) 카드가 정지되고(S3) 거래가 종료된다.
출금 대신 입금 또는 송금을 선택한 경우(U3.2) 해당 업무가 진행되고(S9) 종료된다.
출금액 입력 후 ATM 기기 잔액이 부족하거나(S4.2), 1일 한도를 초과하거나(S4.3), 고객 계좌 잔액이 부족한 경우(S4.4) 이전 단계로 돌아가 재입력을 유도한다.
이처럼 하나의 기능에서도 다양한 시나리오 케이스가 도출될 수 있으며, 이를 이벤트 다이어그램으로 시각화하면 흐름을 보다 명확하게 파악할 수 있다.
테스트 케이스 #1 — 현금 인출 성공 (기본 흐름)
테스트 케이스 #1은 현금 인출이 성공하는 기본 흐름이다. 이벤트 다이어그램에서 U1부터 U5까지 진행되는 경로가 모두 정상적으로 수행되는 케이스이다.
입력값은 유효한 카드, 정확한 비밀번호, 충분한 ATM 잔액, 충분한 고객 계좌 잔액, 그리고 정상적인 출금액으로 구성되며, 모든 조건이 충족되었을 때 현금 인출이 성공적으로 완료되는 것이 예상 결과이다.
테스트 케이스 #2 — 비밀번호 입력 오류 3회 (대체 흐름)
테스트 케이스 #2는 비밀번호 입력 오류가 3회 발생하는 대체 흐름이다. 시나리오 실행 경로를 보면 U2에서 비밀번호를 두 번 잘못 입력하고, 세 번째 입력하는 순간 거래가 정지되는 시나리오이다.
입력값은 유효한 카드이지만 유효하지 않은 비밀번호이며, 예상되는 결과는 다음과 같다.
비밀번호를 잘못 입력했을 때 비밀번호가 올바르지 않다는 메시지와 함께 재입력 창을 화면에 표시한다.
세 번째로 잘못 입력했을 때는 카드 거래를 중지하고 은행 담당자 연락처를 화면에 표시한다.
이처럼 시나리오 테스팅은 사용자 관점에서 시스템을 사용하면서 생길 수 있는 다양한 시나리오를 테스트 케이스로 만들어 직접 테스트해보는 기법이다. 현업에서도 실제 프로덕트를 완성한 후 인수 테스트를 진행할 때 반드시 적용되는 기법인 만큼, 그 개념을 잘 이해해두는 것이 중요하다.
