테스팅 일반 원리 (7 Testing Principles)

선릉역 7번 출구 APEX 6층에 위치한 STA 교육센터에서 Software Testing Foundation (75차) 과정을 듣고 있다.

1일차 오전 수업 중에 김선준 컨설턴트님이 소개한 테스팅 일반 원리(7 Testing Principles)를 간략히 소개하고자 한다.

테스팅 일반 원리(7 Testing Principles)

  1. 테스팅은 결함이 존재함을 밝히는 것 (Testing shows presence of defects)
  2. 완벽한 테스팅은 불가함 (Exhaustive testing is imposible)
  3. 개발 초기에 테스팅을 시작해야 함 (Early testing)
  4. 결함에 집중해야 함 (Defect clustering)
  5. 살충제 패러독스 (Pesticide paradox) 방지 필요
  6. 테스팅은 정황(Context)에 의존적 (Testing is context dependent)
  7. 오류-부재의 궤변 (Absence-of-erros fallacy)

하나씩 순서대로 알아보자.

1. 테스팅은 결함이 존재함을 밝히는 것 (Testing shows presence of defects)

테스팅의 목적을 의미한다. 테스팅은 결함(defects 또는 faults)을 들춰내는 활동임을 기억하자.

2. 완벽한 테스팅은 불가함 (Exhaustive testing is imposible)

모든 자원을 사용해도 결함이 없는 테스팅은 수행이 불가. 무한 경로, 무한 입력, 무한 타이밍 등 때문에 100%(예: 윈도우즈 계산기 테스팅도 100% 완벽하게 할 수 없음. 왜냐하면 무한한 입력이 존재하기 때문)

3. 개발 초기에 테스팅을 시작해야 함 (Early testing)

이는 무엇보다 소프트웨어 개발 비용 때문임. 테스트를 초기에 해야 버그 수정에 드는 비용이 줄어듬. 소프트웨어 개발 생명 주기(Software Development Life Cycle)의 첫 단계인 요구사항 분석(Requirement Analysis) 때 테스트 생명 주기(Test Life Cycle)를 시작해야 함을 의미함.

테스트 생명 주기(Test Life Cycle)은 아래의 다섯 단계로 이루어짐.

A. Test Planning and Control

B. Test Analysis and Design

C. Test Implementation and Execution

D. Evaluating Exit Criteria and Reporting

E. Test Closure Activities

자세한 내용은 별개 포스팅 할 예정. 구글링 하면 많은 자료가 나올 것 같음. 구글만세 :-p

4. 결함에 집중해야 함 (Defect clustering)

결함이 발견되었거나 결함이 발견될 만한 영역에 집중해서 테스트를 수행해야 함. 결함이 발견된 곳 혹은 근방에 결함이 있을 확률이 높기 때문이다.

5. 살충제 패러독스 (Pesticide paradox) 방지 필요

살충제를 계속 사용하면 벌레가 살충제에 내성이 생겨 더이상 죽지 않는 것처럼 반복적으로 사용하는 테스트 케이스 또한 소프트웨어에서 발생하는 버그에 내성이 생길 수 있음.

따라서 결함이 나올법한 테스트 케이스(Test Cases)를 계속해서 만들어야 함. 이미 성공했던 테스트 케이스에만 의존하면 버그 또한 테스트 케이스에 내성이 생겨서 버그를 쉽게 찾을 수 없음.

주기적인 테스트 케이스의 업데이트를 해야 하는 이유이다.

6. 정황(Context)에 의존적 (Testing is context dependent)

테스팅은 무엇을 테스트하느냐에 따라 달라질 수 밖에 없음. 예를 들어 Remote Controller를 테스트 할 때와 원자력 발전소의 어떤 기능을 테스트하는 것은 테스팅 방법과 수준이 다름.

There is no one-size-fits-all solution in software testing.

7. 오류-부재의 궤변 (Absence-of-erros fallacy)

개발한 시스템의 사용자의 필요와 기대에 부응하지 못해 쓸모가 없다면 결함을 찾는 활동도 의미가 없음을 의마한다.

예를 들어, 어떤 소프트웨어를 테스트한 결과 결함이 없음이 밝혀지더라도 그 소프트웨어가 사용자의 요구사항을 만족하지 못한다면 소위 말하는 뻘짓을 했다고 볼 수 있음.

추가로 이 링크를 참고하면 여기서 설명한 내용을 이해하는 데 큰 도움이 된다.