이 포스트는 “지식 제로부터 배우는 소프트웨어 테스트”를 읽고 학습한 내용입니다.

탐색적 테스트

지난 포스트에서 소개한 화이트 박스 테스트와 블랙 박스 테스트는 테스트 케이스 기반 테스트이다.
좀 더 쉽게 설명하면 테스트 케이스를 설계하고 테스트를 진행하는 형태의 테스트 방식이다.
이번에 소개하는 탐색적 테스트는 생각하며 테스트 하기 방식이다.

지난 포스트에서 “똑똑하지 않은 테스트를 시간만 많이 들인다고 소프트웨어 품질이 올라가지는 않는다”고 이야기 하자마자 보다 똑똑하게 테스트 하는 방법에 대해서 소개를 하고 있다.

탐색적 테스트란?

말 그대로 탐색 하면서 테스트를 진행하는 것이다. 반복하지만 생각하면서 테스트 하기 이다.
이 테스트 기법의 핵심은 소프트웨어의 특정 부분에 버그들이 집중되어 분포한다 라는 특성을 이용한 테스트 기법이다.

탐색적 테스트는 1983년에 Cem Kaner 교수가 제안한 방법인데, 그는 저자의 스승이라고 한다.
그는 이렇게 말했다.
탐색적 테스트는 소프트웨어 테스트 이해와 테스트 설계와
테스트 실행을 동시에 수행하는 테스트이다.

이 책에서는 테스트 케이스 실행으로 발견할 수 있는 버그는 전체의 50% 이하 일 것이라고 한다.
그럴 거라면 차라리 테스트 케이스를 일일이 사전에 작성하는 것보다는 생각하면서 소프트웨어를 테스트 하는 것이 낫다.

테스트 케이스 기반 테스트의 단점

1. 프로젝트 초기 단계에 테스트 케이스를 작성하려고 해도 대상이 되는 소프트웨어가 없으므로 어림짐작으로 케이스를 작성하는 경우가 많다. 최악의 경우 요구 사항을 나열 해 놓은 테스트 케이스가 작성된다. ( 우리 프로젝트의 경우 그런 경우가 많았다. )
   요구사항이 명확치 않으므로 경계값 또한 모호하여 제대로 된 경계값 분석 조차 이루어지지 않는다.

2. 너무 이른 테스트 케이스 작성은 소프트웨어 테스트 공수의 현저한 증가를 가져온다.

3. 테스트 케이스 기반 테스트는 아래 두 가지가 결여되어 있다.
   가. 테스트를 실행하면서 어딘가 다른 부분에 문제가 없는지를 생각 해 보고 그 곳을 테스트 하는 것
   나. 소프트웨어에서 약한 부분을 발견 했다면 그곳의 집중적 테스트
   결과적으로 중요도나, 심각도, 버그 분포에 대한 고려가 없는 테스트이므로 비효율적이다.

탐색적 테스트 수행 방법

1. 기준(Criteria)의 결정
   탐색적 테스트 수행 전에 어떤 소프트웨어야 하는지에 관한 기준을 정해야 한다. 아래 표는 해당 예이다.
   

2. 탐색적 테스트 수행
   탐색적 테스트 수행은 아래의 다섯 가지 단계로 이루어진다.
   가. 대상 소프트웨어를 정함.
   나. 기능을 목록화 함.
   다. 해당 기능들을 조사하여 약한 부분을 발견.
   라. 각 기능을 테스트 하고 버그를 기록
   마. 계속적인 테스트 실행

탐색적 테스트의 단점

비기능 요구 테스트에 어울리지 않는다. 예외가 있다면 사용성(Usability)테스트이다.

테스트의 효율을 극대화 하기 위해서는..

일반적인(기술적인 이해도나 깊이가 없는) 테스터가 탐색적 테스트를 수행 하였을 경우에는 코드 커버리지가 테스트 케이스 기반의 테스트나 별반 차이가 없다.

하지만 일반적인 테스터에게 개발자가 프로그램의 구조를 설명해 주고 테스트를 하면 아래와 같은 그래프가 나온다.

따라서 탐색적 테스트 + 기술을 갖춘 테스트 담당자의 조합이라면 짧은 시간에 최대의 결과를 얻을 수 있다.

결론

소프트웨어 설계 회의 시에 테스터를 참석 시키거나, 소프트웨어 설계가 완료 되었을 때 테스터에게 그 구조에 대해서 자세히 설명 해 준다면 탐색적 테스트를 수행하여 보다 나은 품질의 소프트웨어를 얻을 수 있다.또한 테스트의 스타일과 방법은 다양하다. 그 스타일과 방법을 적재적소에 적용할 수 있는가가 테스트의 성과를 좌우한다.