swtest
테스팅의 일반적인 원리(General testing principles)
by Kitle · 2017. 06. 08.
다수의 테스팅 원리가 40년간 제안되어 왔고, 일반적인 테스팅의 가이드라인이 되었다 한다.
가장 많이 언급 되는 7가지 원리에 대해 알아보고, 그에대한 주관적인 분석과 탐구를 통해 그 뒷면까지 살펴보도록 하자.
Principle 1 Testing shows presence of defects.
테스팅은 결함 존재를 밝히는 것.
중요한 것은 테스팅 활동이 이 "결함"이 있다. 라는 것을 찾아가는 활동이라는 것이다. 테스터 입장에서는 어떠한 환경에서 어떻게 테스트를 진행하니 어떤 결함이 나오더라 를 밝히는 것이다. 결함이 전혀 발견되지 않아도 결함이 없음을 증명 할 수 없다.(이는 원리 2와 함께 생각해보자)
Principle 2 Exhaustive testing is impossible.
완벽한 테스팅은 불가능하다.
흔히 무한경로, 무한 입력값, 무한 타이밍. 을 예로 든다.
왠만큼 복잡한 일반적인 프로그램은 다양한 경로와, 다양한 진행 루트와, 다양한 분기(branch)와 다양한 타이밍 등 생각보다 input과 타이밍이 무한대에 가깝다.
예를들어 시간관련 프로그램이 있다. 이 프로그램은 1970-01-01 부터 2030-12-31 까지 지원한다고 치자. 모든 시간을 전부 테스트 할 수 있는가? 테스팅을 위해 50년을 소비할 수 있겠는가?
Principle 3 Early Testing
가능한 한 초기에 테스팅을 시작하라.
추후에 설명을 하겠지만, 초기에 발견된 결함이 수정하기에도 용이하며, 비용도 저렴하거니와, 추후에 나타나는 문제점을 대응하기도 수월해 진다.
늦게 시작한 테스팅은 비용도 비싸고 결함발견과 수정에도 더 많은 시간이 걸리며, 성급한 테스트와 부족한 시간은 좋은 소프트웨어의 품질을 보장하기 쉽지 않다.
Principle 4 Defect clustering
결함 집중
언뜻 보면 아주 당연한 원리이다. 결함은 일부의 모듈에 집중되기 마련이다. 복잡한 구조, 상호작용이 높은 인터페이스, 신규개발 모듈, 크기가 큰 모듈, 초보 개발자가 개발한 모듈.
이전 포스팅에 보면 결함의 원인이 결국 인간의 실수로 인해 야기된다 하였다. 난 이 원리를 두고 "콩심은데 콩나고 팥심은데 팥난다"라고 하고 싶다. 새로 개발된 부분에서 결함이 나오고, 복잡하게 구성된 모듈과 인터페이스연관 부분에서 결함이 날 수 밖에 없다. 그래서 우리는 결함이 발견되었을 때 가장 먼저 의심해볼 부분이 최근에 수정한 부분, 결함이 나왔던 부분, 결함이 나올것으로 예상되는 부분을 우선적으로 탐지해 볼 필요가 있다.
Priciple 5 Pesticide paradox
살충제 패러독스 현상.
살충제를 자꾸 뿌리면 내성이 생겨 더이상 벌레들이 죽지 않는 다는 것.
s/w testing에서는 이를 동일한 testcase(살충제)를 돌려 결함(bug)을 잡는 것을 반복하다보면 새로운 결함이 나오지 않는 다는 것을 설명한다.
그렇기 때문에 살충제도 "더 강력해진~" "새로운" 을 강조 하듯이, testcase도 더욱 더 새롭고 강력해 져야한다. 또한 testcase뿐 아니라 다른 테스팅
기법등을 통해서 해야한다.
단, 다양한 testcase와 많은 테스팅 방법을 빌드시마다 반복적(리그레션 테스팅)으로 수행 하여도 결함이 발견되지 않는다면 이를 왜 새로운 결함을
잡지 못할까? 로만 고민하지 말고, 이미 s/w 의 품질이 꽤 높게 형성된 경우일 수 있으니 이에 대한 날카로운 판단이 필요하다.
*testing을 통해 s/w가 품질만 좋아지는 것 같지만, 테스터/개발자의 s/w를 보는 시각도 길러준다.
전혀 생각지도 못한 루트에서 결함이 발견되면 테스터는 해당 시퀀스와 동작을 새로 조합해 보고,
테스터가 발견한 결함을 수정하면서 개발자는 결함을 보는 눈과 본인의 코딩/디버깅 능력이 향상돼 개발-s/w-테스팅 이 모두 성장하는 효과가 있다.
그러니 한번 구성되어 잘 발전되 가던 체제가 무너지면 그 손해가 막중하리라 예상된다.
Principle 6 Testing is context dependent
테스팅은 상황에 의존적이다.
로마에 가면 로마법을 따르 듯, 모든 s/w가 동일한 방법으로 테스팅 되지 않는다. 같은 결함이라도 보는 사람에 따라, 관점에 따라 우선순위와 등급이
다르며 도메인이 달라지면 테스트 기법이나 툴, 방법이 상이한 경우도 있다. 어떤 대상을 테스팅 하느냐에 따라 테스팅은 달라진다.
Principle 7 Absence-of-error fallacy.
오류-부재의 궤변.
사용자 기대에 부흥하지 못하고 사용성이 떨어지는 s/w는 결함이 거의 없더라도 테스팅 활동의 의미가 없다. 사용자 및 비즈니스의 요구를 충족하는 s/w와 그에따른 적절한 테스팅을 말하고 있다.