테스팅 일반 원칙 (General testing principles) [Schneider 2006]

ISTQB (International Software Testing Qualifications Board) 에서 지난 40여 년간 테스팅 윈칙을 정제하여 아래 7개의 테스팅 일반 원칙으로 정의하였다.

테스팅은 결함이 존재한다는 것을 보여 준다 - Testing shows Presence of Defects

§   테스팅은 결함이 있다는 것을 보여줄 수 있다.

Testing can show you that defects are there.

§   테스팅이 결함이 없다는 것을 증명할 수는 없다.

Testing cannot prove that there are no defects.

§   결함은 소프트웨어에 남겨진 발견되지 않은 결함의 가능성을 줄인다.

Testing reduces the probability of undiscovered defects remaining in the software.

§   그러나 결함이 발견되지 않았더라도, 결함이 없다는 것은 아니다.

But, even if no defects are found, it is not a proof of correctness.

완벽한 테스팅은 불가능하다 - Exhaustive testing is impossible.

§   사소한 경우를 제외하고는 모든 입력 변수와 선행 조건의 조합 값을 고려한 전수 테스트는 불가능하다. 완벽한 테스팅 대신, 위험과 우선순위를 고려하여 테스팅 노력을 집중한다.

Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risk and priorities to focus testing efforts..

조기 테스팅 - Early Testing

§   테스팅 활동은 가능하면 소프트웨어 시스템 개발 생명주기에서 빨리 시작해야 한다.

Testing activities should start as early as possible in the software or system development life cycle

§   정의된 목표에 집중해야 한다.

They should be focused on defined Objectives

결함 집중 - Defect Clustering

§   일부 모듈이 운영 전 발견된 대부분의 결함을 가지고 있거나, 대부분의 운영 실패를 발생시킨다.

A small number of modules contain most of the defects discovered during pre-release testing, or show the most operational failures.

살충제 패러독스 - Pesticide Paradox

§   동일한 테스트가 반복된다면, 결국 같은 테스트케이스를 가지고 새로운 버그를 발견하지 못한다.

If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs.

§   문제를 해결하기 위해서는 테스트케이스를 정기적으로 검토하고, 수정하여야 하며, 새롭고 다른 테스트가 더 많은 잠재 결함을 찾도록 소프트웨어나 시스템의 다른 부분을 실행하도록 준비하여야 한다.

To overcome this effect, the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.

테스팅은 context 의존적이다 - Testing is  Context Dependent

§   테스팅은 상황에 따라 다르게 실시한다.

Testing is done differently in different contexts.

§   예를 들면, 안전이 중요한 소프트웨어는 이커머스 소프트웨어와 다르게 테스트하여야 한다.

For example, safety-critical software is tested differently from an e-commerce site.

오류 부재의 오해 - Absence-of-Errors Fallacy

§   개발한 시스템이 사용할 수 없고 사용자 기대와 요구 만족을 보장하지는 못하면, 결함을 발견하고 고쳤더라도 아무런 도움이 되지 않는다.

§   Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations