테스트의 설계를 하기 위해서는 테스트 재료(테스트 베이시스)를 이용한다. 하지만 이를 테스트 케이스 등에 적용하기 위해서는 "분석" 이라는 과정이 필요하다.
테스트 베이시스에 따라 분석하는 방법은 여러가지 방법이 있는데 오늘은 필자가 직접 만든 방법을 소개하고저 한다.
필자가 일하는 곳에서의 사양서는 화면 베이스로 작성된다. 업의 특성상 Flow가 짧고 많은 선택 요소들이 있는게 특징이다.
이런 화면 베이스의 사양을 분석하는 방법은 여러가지가 있지만, 필자는 2가지 관점으로 분류를 하겠다.
- 어떤 Action시의 환경 및 정황(Environment & Context)
- 발생 가능한 Action
예를들어 아주 간단한 로그인 모듈에 대한 기능을 보도록 하자.

환경 및 정황 측면에서 발생할 수 있는 경우를 생각
- 네트워크가 끊어졌다(또는 연결되었다, 약하다)
- OS의 언어가 일본어, 영어, 한국어, 중국어
발생 가능한 Action에 대하여 생각
- 메일을 입력한다 (또는 안한다)
- 메일 어드레스를 입력하지 않고 임의의 문자를 입력한다(또는 정상적인 이메일을 입력한다)
- 미등록 이메일을 입력한다. (또는 등록된 이메일을 입력한다)
- 패스워드를 입력한다.(또는 안한다)
- 패스워드를 틀리게 입력한다(또는 맞게 입력한다)
- 패스워드를 잊어버린 사람을 클릭
- 회원등록을 클릭
※로그인 클릭은 모든 동작에서 필요하므로 표현하지 않음
Action 자체를 더 보강하려면 특수문자 대응 등에 대한 Action도 추가할 수 있지만 여기에서는 좀 간단하게 만들겠다.
필자는 정리를 위해 마인드 맵 소프트웨어의 한 종류인 Freemind를 이용하겠다. 다음과 같이 정리해 보자.
Level1카테고리에 "환경 및 정황" 과 각 Action을 두었는데 이 때 액션은 Yes, No로 구분될 수 있도록 기술하는 것이 좋다.
이제 각 Lever1의 카테고리에 대한 종속 관계를 적용하여 재정립한다.
패스워드 의 판단은 메일 입력란에 제대로 입력이 되었다는 것을 전제로 하여야 하기 때문에 '패스워드란에 입력' 을 '미등록 메일 어드레스 입력=Yes' 밑으로 이동하겠다.
각 가지 끝에다가 번호를 매겼는데, 번호가 있는 가지가 있고 없는 가지가 있다.
체크해야 할 기본 Action 으로서 branch 중에 "Yes"가 있는 branch 이고 여기에 번호를 붙인 것이다.
그러면 기본 동작을 도출하여 보자.
| 번호 | 동작 | 시나리오 |
| 1 | 메일 입력란에 입력 : Yes 메일 어드레스 형식으로 입력 : No | 메일 입력란에 메일 어드레스 형식이 아닌 임의의 문자를 입력하고 로그인 클릭 |
| 2 | 메일 입력란에 입력 : Yes 메일 어드레스 형식으로 입력 : Yes 미등록 어드레스 입력 : Yes | 메일 입력란에 등록되지 않은 메일 주소를 입력하고 로그인 클릭 |
| 3 | 메일 입력란에 입력 : Yes 메일 어드레스 형식으로 입력 : Yes 미등록 어드레스 입력 : No 패스워드 란에 패스워드 입력 : No | 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 아무것도 입력하지 않고 로그인 클릭 |
| 4 | 메일 입력란에 입력 : Yes 메일 어드레스 형식으로 입력 : Yes 미등록 어드레스 입력 : No 패스워드 란에 패스워드 입력 : Yes 패스워드 란에 틀린 패스워드 입력 : No | 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 맞는 패스워드를 입력하고 로그인 클릭 |
| 5 | 메일 입력란에 입력 : Yes 메일 어드레스 형식으로 입력 : Yes 미등록 어드레스 입력 : No 패스워드 란에 패스워드 입력 : Yes 패스워드 란에 틀린 패스워드 입력 : Yes | 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 틀린 패스워드(임의의 문자)를 입력하고 로그인 클릭 |
| 6 | 회원등록 버튼 클릭 : Yes | 회원버튼 클릭 |
| 7 | '패스워드를 잊어버린 분...' 클릭 : Yes | '패스워드를 잊어버린 분...' 클릭 |
이때 1, 2번 케이스 에서 패스워드 란에 대한 입력은 결과에 큰 영향을 미치는 못하기 때문에 자연스레 빠진 것이며 만일 보강을 하고 싶다면 1,2번 케이스에 보강을 해 주면 된다.
예를 들어 1번 케이스는 다음과 같이 보강이 가능할 것이다.
"메일 입력란에 메일어드레스 형식이 아닌 임의의 문자를 입력하고 패스워드 란에도 임의의 문자 입력 후 로그인 클릭"
위와 같이 도출된 결과를 필자는 Basic "Action" 체크 목록으로 활용한다.
이제 "환경 및 정황" 을 연계 시켜 생각해 보자
OS및 네트워크 연결상태를 "환경 및 정황" 의 Factor로 잡았으며 이 Factor들과 위 도출된 Action들과의 조합이 "통합" 테스트 케이스로 활용될 수 있다.
PairWise 조합으로 통합 케이스를 생성해 보자
| Action | 3,4,5 |
| OS언어 | 영어, 중국어, 한국어,일본어 |
| 네트워크 상태 | Yes, 약함, No(Not Connected) |
1번, 2번 Action 은 환경의 영향을 많이 받지 않을 것으로 판단되어 제외 했다.
6번, 7번 Action 은 단순 클릭이기 때문에 역시 환경의 영향을 받지 않을 것이라 생각되어 제외 했다.
결과는
| Case # | Action | OS | 네트워크 상태 | 완성 시나리오 |
| 1 | 5 | 영어 | Yes | 영문OS 네트워크가 잘 연결된 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 틀린 패스워드(임의의 문자)를 입력하고 로그인 클릭 |
| 2 | 3 | 영어 | No | 영문OS 네트워크가 끊긴 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 아무것도 입력하지 않고 로그인 클릭 |
| 3 | 4 | 영어 | Weak | 영문OS 네트워크가 약한 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 맞는 패스워드를 입력하고 로그인 클릭 |
| 4 | 4 | 일본어 | Weak | 일본어OS 네트워크가 약한 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 맞는 패스워드를 입력하고 로그인 클릭 |
| 5 | 3 | 일본어 | Yes | 일본어OS 네트워크가 잘 연결된 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 아무것도 입력하지 않고 로그인 클릭 |
| 6 | 5 | 일본어 | No | 일본어OS 네트워크가 끊긴 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 틀린 패스워드(임의의 문자)를 입력하고 로그인 클릭 |
| 7 | 5 | 중국어 | Weak | 중국어OS 네트워크가 끊긴 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 맞는 패스워드를 입력하고 로그인 클릭 |
| 8 | 4 | 중국어 | No | 중국어OS 네트워크가 끊긴 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 맞는 패스워드를 입력하고 로그인 클릭 |
| 9 | 3 | 중국어 | Yes | 중국어OS 네트워크가 잘 연결된 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 아무것도 입력하지 않고 로그인 클릭 |
| 10 | 3 | 한국어 | Weak | 한국어OS 네트워크가 약한 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 아무것도 입력하지 않고 로그인 클릭 |
| 11 | 4 | 한국어 | Yes | 한국어OS 네트워크가 잘 연결된 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 맞는 패스워드를 입력하고 로그인 클릭 |
| 12 | 5 | 한국어 | No | 한국어OS 네트워크가 끊긴 상태에서 메일 입력란에 등록된 메일 어드레스를 입력하고 패스워드 란에 틀린 패스워드(임의의 문자)를 입력하고 로그인 클릭 |
수행 순서는 일단 기본 Action 1,2,6,7을 수행하고 "환경 및 정황" 을 통합한 테스트를 진행하면 된다.
이 방법을 현장에 적용 할 때 생각해야 할 변수가 3가지가 있다.
- "환경 및 정황" 과 Action에 종속성이 발생할 때이다. 이 경우에는 PairWise를 적용시에 조건을 걸어 주어야 한다. 때로는 "환경 및 정황" 의 Factor사이에서도 종속성이 발생할 경우가 있다. 이에 대한 고찰은 여러분들에게 숙제로 남기겠다.
- Basic 케이스와 통합된 케이스 도출 과정에서 Factor 선정시에 현실성 있는 Factor를 골라야 한다. 이를 위해서는 테스트 대상에 대하여 지식이 필수.
- 도출된 통합 케이스도 전부 수행할 필요가 있을까? 이는 단순히 논리적인 조합 결과에 불과하다. 여기에서 실제로 일어날 가능성이 적은 것은 가능하면 제외한다. (물론 완벽한 테스팅을 원하면 포함시킨다)

덧글