Test Case

Test Case란 테스트 조건을 기반으로 개발 된, 사전 조건, 입력, 행동, 예상 결과와 사후 조건의 집합이라고 한다.

 

A set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions.

ISTQB Glossary

이게뭔.. ㄱ..소리야!

 

간단하게, 우리가 테스트 해야하는 제품이 요구사항 즉 명세 또는 기획 의도대로 만들어져 있는지 혹은 인수 할 수 있는 품질을 갖고 있는지를 확인하고자, 테스트 해야하는 케이스들의 입력 값, 실행 조건, 예상 결과를 집합한 문서라고 보면 될걱......

 

 

자 가령, 예를 들어 아래와 같이 username과 password를 받아 로그인하는 웹 페이지라고 테스트 케이스를 작성해보자.

html

<div>
  <label for="username">Username:</label>
  <input type="text" id="username" name="username" minlength="8"  maxlength="20" required />
</div>

<div>
  <label for="pass">Password</label>
  <input type="password" id="pass" name="password" minlength="8" required />
</div>

<input type="submit" value="Sign in" />

 

Username:

Password

 

간단하게나마 테스트 케이스를 작성해보자.

 

Test Case

구분	대분류	중분류	소분류	사전 조건	수행 절차	기대 결과	실제 결과
1	로그인	Username	입력		임의 값 입력 시도	입력 된 값 출력
2			최소		Username에 8자 미만 입력 시도	8자 미만 Validation 문구 출력
3			최대		username에 20자 이상 입력 시도	20 자 이상 입력이 불가능 함
4		Password	입력		임의의 값 입력 시도	Password 처리되어 * 로 출력 됨
5			최소		8자 미만	8자 미만 입력 Validation 문구 출력
6		Submit	Username 미 입력		1. Username 미 입력 2. 임의 Password 입력 2. Submit 선택	Username 미입력 Validation 출력
7			가입되지 않은 계정		1. Username에 가입되지 않은 Username 입력 2. 임의 Password 입력 3. Submit 선택	가입되지 않은 Username Validation 출력
8			Password 미 입력		1. 임의 Username 입력 2. Password 미 입력  3. Submit 선택	Password 미입력 Validation 출력
9			Password 틀림		1. 가입 된 Username 전체 입력 2. 틀린 Password 입력 3. Submit 선택	Password 틀림 Validation 출력
10			정상 로그인		1. 가입 된 Username 전체 입력 2. 해당 계정의 Password 입력 3. Submit 선택	로그인이 완료 됨

 

대충 쓴 내용인데, 생각보다 로그인에도 테스트 할게 많은데, 공백이 입력된다거나, 특수문자 등 입력되지 않아야 한다거나, 구현에 따라 계정이 잠겼다거나, 탈퇴된 계정들 그런 조건들도 있을 수 있다.

 

당연히 기능적인 것들은 저 내용에 추가되어야 할 것이다.

 

하지만, 우선순위에 따라 낮다고 판단되거나, 테스트 하기 좀 번거로운 것들은 나중에 시간이나면 하자..

입력 값이 가질 수 있는 값의 조합은 무한히 많기 때문에..

 

여튼 항목 하나하나 보자면,

 

1. 분류
   사실 테스트 하려는 항목의 분류다. 이건 개인적으로는 화면에서 컴포넌트 단위로 분류하는 것을 좋아한다.
   BDD의 경우 행동으로 하면 좋긴한데, UI단의 많으 변화들을 작성하기엔 BDD가 너무 많아질 수 있다.
   그렇다고 행동만 적기에는 UI가 변동할 개기의 행동들이 많은데 then 이 너무 많아지거나 행동 자체 하나하나가 많아질 수 있다고 판단해서 그렇게 사용한다.
2. 사전 조건
   액션을 하기 위해 필요한 사전에 필요한 또는 선행의 조건을 말한다. 가령 로그인이 아닌, Android 6.0에서 권한 팝업 창이 출력되는 것을 테스트 한다고 작성할 때, 이때 Android 6.0이라는 사전에 필요한 조건을 기술한다.
   사전 조건과 액션을 잘 구분해서 작성하는 것도 필요한 스킬인거 같다.
   
   
3. 수행 절차
   사전 조건이 갖춰지면 실제 행동을 해야하는 절차를 말한다. 
   행동 하나하나를 구분지어 설명해주면 좋다.
   ex) 1. 버튼을 선택한다. 2. 입력한다.
   
   
4. 기대 결과
   기획서 또는 오라클이라 할 만한 명세 문서에 따라 기능의 동작 할 행동에 대해 적는다.
   사전 조건이 갖춰진 상태로 수행 절차를 진행 했을 때, 유저에게 동작할 애플리케이션의 내용.
   
5. 실제 결과
   테스트 한 내용이 기대 결과와 같은지, 실패했는지 등을 기재하며, 내용으로는 Pass, Fail, Block, N/A 등이 있는데, 이건 회사마다 다를 수 있다.
   1. Pass는 테스트가 성공했음을,
   2. Fail은 실패를 의미하지만,
   3. Block은 Fail로 인해 테스트가 불가능한 항목을 표기할 때 쓴다.대략 예를 들어 "이용 약관에 내용을 확인해야하는 테스트"이지만, 선행 테스트 항목인 "이용 약관에 진입하는게 문제" 로 인해서 이용 약관을 들어갈 수 없기 때문에 Block 이 되는 것이다.
   4. N/A는 Not Available로 테스트 계획에 포함되어있으나, 테스트 항목이 제외되거나 스펙 아웃되거나 현재 빌드에 포함되지 못해 이번에 테스트가 불가능한 항목을 표기한다.

 

예전부터 많이 들었던 "테스트 케이스는 5살도 따라 할 수 있게 써야"한다. 말을 하지만

테스트 케이스에는 정답이 없는거 같아, 아직도 쓸때마다 어렵다. 

내가 테스트 하는 것이 리소스 상 얼마나 좋은 퀄리티를 갖고 있는지도 체크해야하고, 테스트 케이스에 경험을 녹여야 하기도하고..

 

쉬운게 어딨겠냐만서도 ㅎㅎ

 

 

 

 

QA 관련해서 얘기 나누는걸 좋아합니다. 언제든지 댓글 또는 문의 주세요.

물론, 글을 못써서 내용이 그지같을 수 있습니다.