티스토리 뷰

책을 보다 보면, 가끔씩 너무나 자주 사용하면서도 너무나 쉽게 지나치고 있는 원리를 가르쳐 줄 때가 있다.


가능하다면 테스트 케이스에서 작성된 질문들은 “Yes”“Pass” 조건 소프트웨어가 설계한대로 동작하며 결함이 발견되지 않는 상태 - 을 가리키도록 작성되어야 한다.
어떠한 테스트 케이스에 “No”라고 대답한다는 것은 해당 테스트 케이스를 실행할 경우 문제가 발생한다는 이야기이며, 이러한 결함은 반드시 보고되어야 한다. 여기에는 여러가지 이유가 있지만 가장 직관적인 이유는, 일반적으로 우리는 심적으로 “Yes”“Pass”를 동일시하고(둘 다 긍정적인 의미이므로), 같은 방식으로 “No”“Fail”을 동일시 하기 때문이다.

또한, 동일한 컬럼 안에서 패스 처리된 모든 항목들을 한 군데에 묶음으로써, 테스터와 테스트 매니저 모두 완료된 테스트 스위트에서 실패 처리된 항목과 성공 처리된 항목들을 쉽게 식별할 수 있기 때문이다.

 

예를 들어, 다양한 인터페이스와 결합해 작은 창안에 텍스트로 설명을 해주는 툴팁 디스플레이를 커버하는 테스트 케이스가 있다고 가정해보자. 기본적인 테스트 케이스에는 툴팁 텍스트에 오탈자가 있는지의 내용이 포함될 것이다. 이를 위한 가장 직관적인 테스트 케이스는 다음과 같을 것이다.

 

텍스트에 오탈자가 포함되어 있는가?(Does the text contain typographical errors?)

 

이 질문에는 문제가 있어보이는데, 이는 이 항목을 패스 처리를 하려면 “No”라고 대답해야 한다는 것이다.
격무에 시달려 피곤하거나 지친 테스터라면, 이를 잘못 생각해 오탈자가 없다는 것을 "Yes"라고 표시해 결과적으로 실패했다고 처리할 수 있는 부분이다. 이러한 질문은 “Yes”가 곧 “Pass”를 가리킬 수 있도록 다음과 같이 표현되는 것이 좋다.

 

텍스트에 오타가 없는가?(Is the text free of typographical errors?)

 

보는 대로, 직접적인 화법을 사용한 테스팅은 매우 구조적이고 체계적이다. 이러한 직접적인 테스팅을 완료하고 나서, 혹은 이와 병행하여 조금 덜 구조적이긴 하지만 훨씬 직관적인 애드 혹 테스트(ad-hoc)를 같이 수행하는 것이 좋다.  

                                                                                                          from Game Testing All in One

'QA' 카테고리의 다른 글

리스크 기반 테스팅 - Part 2  (2) 2010.06.21
잘못된 애자일의 다섯 가지 증상  (16) 2010.05.27
누가 소프트웨어 품질을 책임질 것인가?  (2) 2010.04.28
생활 속의 QA - Early Testing  (4) 2010.04.20
Cloud QA  (0) 2010.03.22