스크립티트 테스팅과 탐색적 테스팅의 고찰

현대의 소프트웨어 테스팅 패러다임을 크게 두 개로 나누면,

스크립티드 테스팅(Scripted Testing)과 탐색적 테스팅 (Exploratory Testing)으로 나눌 수 있다.

스크립티드 테스팅은 다음과 같은 사상에 의거해 수행한다.

1. 실행 이전에 계획을 세우고, 계획된 대로 진행한다.
2. 테스트에 반복성, 객관성, 감사성을 적용한다. (from Lee Copeland)
3. 테스트를 준비하고, 준비한 테스트를 실행한다.

탐색적 테스팅은 직관적(intuitive) 테스팅으로 불리며 다음과 같은 사상에 의거해 수행한다.

1. 근거로 삼을 아무런 테스트 베이시스가 없다.
2. 구조적인 테스트 프로세스를 따르지 않는다.
3. 테스터의 경험과 직관만이 사용된다.
4. 계속적으로 테스트 케이스가 변경된다.

즉, 스크립티드 테스팅과 탐색적 테스팅을 비교하면 다음과 같을 것이다.

1. 준비성: S 테스팅은 대단히 많은 준비를 요구하나, E 테스팅은 즉시에 수행한다.
2. 근거: S 테스팅은 잘 작성된 요구사항을 근거로 하며, E 테스팅은 테스터의 경험과 지식, 직관을 주로 사용한다.
3. 모델 사용: S 테스팅은 요구사항이나 잘 작성된 모델 문서를 사용하지만, E 테스팅은 테스터가 테스트 대상을 탐색하면서 모델을 만든다.
4. 사전 조건: S 테스팅을 하려면 잘 정의된 요구사항과 문서를 요구한다. E 테스팅은 문서 없이 심지어 테스트 대상만 존재한 경우에 사용된다.

이렇게 비교하면 결론적으로, S 테스팅은 조직의 역량과 프로젝트의 단계별 준비가 잘 된 상황에 사용할 수 있을 것이며, E 테스팅은 아무런 준비가 없는 상태에서 테스터가 투입되거나 그 보다 더 열악한 환경에 사용할 수 있을 것이다.

또한, E 테스팅이라고 해도 구체적인 방법론을 제시하는 것이 아닌 순전히 맨파워에 의존적이라는 인상을 주기 때문에 사람마다 제각각 다른 결과를 낸다는 어려움이 있을 수 있다. 또, 테스터 임의로 수행하는 테스트에 대해서 E 테스팅이라고 주장해도 사실이 그러한지 아니면 Ad hoc인지를 판단할 방법이 없다.

그렇다면, 현실적으로도 그렇게 하고 있지만 이 두가지 사상을 함께 사용하는 방법으로 테스트를 수행하는 것이 정답이라는 결론에 이르게 된다.

1. 가장 이상적인 조합: 프로젝트가 단계별로 수행되고 있어서 각 단계마다 결함이 걸러지며, 산출물 또한 산출되어 있어서 테스터가 이를 근거로 S 테스팅을 수행할 수 있음. 또한, 테스터 중에는 이 프로젝트를 경험해 보았거나 사용된 기술에 대한 이해가 있어서, S 테스팅을 수행하고 난 이후에 E 테스팅을 수행할 여력이 됨.
2. 그 다음으로 이상적인 조합: 프로젝트가 단계별로 수행되고 있지만 각 단계마다의 산출물이 갈수록 구체적이지 않고, 산출되지 않음. 최초에 나와있는 산출물을 이용해 테스터는 S 테스팅을 수행하며, 경험이 있는 테스터가 있어서 부분적으로 E 테스팅을 수행함.
3. 대다수 많은 조합: 프로젝트가 단계별로 수행되지 않고, 테스터가 이용할 수 있는 산출물은 제한적임. S 테스팅을 수행할 수 있는 개발 단계나 산출물이 없기 때문에, 경험있는 테스터가 E 테스팅을 수행함. 일부 정형화된 테스트 케이스에 대해서는 경험 없는 테스터가 투입되어 반복 수행함.
4. 나쁜 징조가 보이는 조합: 프로젝트가 단계별로 수행되지 않고, 테스터가 이용할 수 있는 산출물이 없음. 테스터 또한 이 프로젝트에 대한 경험이 없어서 임의적으로 테스팅이 수행됨. 외부에서 보기에는 E 테스팅과 다를 것이 없으나, E 테스팅 조차도 잘 수행되어도 이를 외부에서 판단할 근거가 없기 때문에, 이 테스트는 자의적이고 임의적으로 수행되며, 어떤 상황에 잘 대응되는 테스트라 보기 힘듦.
5. 매우 나쁜 조합: 프로젝트가 임의로 수행되어 어떻게든 빌드 산출물이 작성되었고, 이에 대한 테스팅 책임은 전적으로 테스터에게 있다고 모든 구성원들이 생각함. 테스터의 역량, 정책, 산출물의 가용성 등이 부족하기 때문에, 테스팅은 구체적인 결과나 개선의 의미보다는 단순히 수행했으나 어떤 정보 획득이나 개선에 대한 증거 확보의 의미는 없음. 특히, 상황에 맞는 테스팅이 아니며, 테스팅 자체가 품질 향상을 위한 유일한 방법으로 여겨짐.

쥔장은 스크립티트 테스팅에 대한 지지자이다. 하지만, 돌이켜보면 반드시 이것만 사용하거나 이것만 사용할 수 있었던 것은 아니었다. 스크립티드 테스팅의 수행 이후의 결과에 대한 대응으로 몇가지 임의적으로 테스팅을 수행해 보고, 정보를 더 획득한 이후에는 이 테스팅을 개정해서 수행했었기 때문에, 이 자체가 S 테스팅과 E 테스팅의 결합으로 생각된다. 단순히 계획이 있다 없다의 문제라기 보다는 거시적 관점에서 테스팅을 보고, 현재 상태에 대한 판단을 통해 더 나아질 수 있는 무언가를 추구하는 것이 S 테스팅 vs E 테스팅을 올바르게 이해하는 관점이 아닌가 싶다.

쥔장이 특히 스크립티드 테스팅의 가치를 높이 평가하는 이유는 테스팅의 프로세스성, 즉 반복적으로 수행하다보면 맞는 기대 동작에 대한 습득이 자연스럽게 되어, 이후의 테스팅 수행에서 옳고 그름에 대한 판단이 가능하리라는 기대 때문이다. 물론 E 테스팅에서도 이것이 가능하겠으나, 경험이 없고 프로세스적 사고에 대한, 공식적인 QA 활동에 대한 경험이 없는 인력은 E 테스팅의 정수를 깨닫지 못하고 임의로 수행할 위험성이 있기 때문이다. 즉, 쥔장은 오해의 소지가 많은 E 테스팅 보다는 어떤 간략화된 절차를 따름으로서 생기는 이득에 초보 테스터들이 집중하는 것이 낫다는 판단이다. (또한 정식의, 매우 성공적이었던 practice를 알지 못하면, 자신감을 가지지 못해, 카운터 파트에 이를 강제, 설득하지 못하는 문제도 있다.)

또한, S 테스팅이든 E 테스팅이든 간에 가장 중요한 문제는 기대 동작, 기대 행동을 사전에 정의하는 문제이다. 이것을 어떤 방법을 동원해 도달하는 가가 이 두가지 사상을 나눈다고도 볼 수 있다. 당신은 해당 소프트웨어나 시스템의 올바른 동작을 어떻게 획득할 것인가?(test oracle?) 어려운 문제이다. 테스터가 해당 프로젝트의 이전 프로젝트에 참여해서 경험을 가지고 있다면 베스트이다. 하지만, 그렇지 않은 상황의 경우는? 대안으로는 유사 프로젝트의 경험을 셰어받거나 유사 제품을 동작시키면서, 어떤 mental model을 테스터가 수립하는 것이다. 구체적으로는 프로젝트마다 다르겠으나 테스팅을 수행하기 이전에 전략의 관점에서 이러한 문제들이 결정되어야 한다고 본다.

이 글로 인해서 조금이나마, 테스팅의 관점과 사고에 대해서 고민하는 분들에게 도움이 되었기를 빈다!