1-3. 테스팅의 일반적인 원리

테스팅의 일반적인 원리

1. 원리 1 - 테스팅은 결함이 존재함이 밝히는 활동이다.(Testing shows presence of defects.)

- 테스팅은 결함이 존재함을 밝히는 것

- 테스팅은 소프트웨어에 잠재적으로 존재하는 결함을 줄일 수 있음

- 결함이 전혀 발견되지 않은 경우라도 해당 소프트웨어에 결함이 없다고 증명할 수는 없음

2. 원리 2 - 완벽한 테스팅은 불가능 하다.(Exhaustive testing is impossible.)

- 모든 가능성(입력과 사전 조건의 모든 조합)을 테스팅하는 것은 지극히 간단한 소프트웨어를 제외하고는 가능하지 않음

- 완벽한 테스팅이 불가능한 이유: 무한 경로(내부조건이 많음), 무한 입력값(입력값의 조합이 많음), 

무한 타이밍(GUI 이벤트 발생 순서에 대한 조합이 많음)

3. 원리 3 - 테스팅을 개발 초기에 시작한다.(Early Testing)

- 테스트 활동은 소프트웨어나 시스템 개발 수명주기에서 가능한 초기에 시작 되어야 하고, 설정한 테스트 목표에 집중

1) 개발 초기에 테스팅을 시작하는 것의 의미

- 개발 시작과 동시에 테스트를 계획

- 전략적 접근을 고려

- 개발산출물(요구분석서, 설계서)을 분석하여 테스트 케이스 도출 과정을 통해 결함을 발견하는 것

- 명세기반기법을 이용해 체계적인 테스트 케이스를 도출, 문서상의 결함을 발견, 리뷰 미팅에 참석하여 인시던트를 알리고, 실제 결함 여부를 결정

2) 개발 초기에 테스팅 수행의 효과, 장점

- 개발과정에서 조기 테스트를 설계하면, 코딩이 끝나자마자 개발초기부터 준비된 테스트케이스를 테스트 레벨별로 실행가능

- 테스팅 결과를 단기간에 알 수 있고 전체 테스팅 기간을 단축 할 수 있음

- 코딩에서의 재작업을 줄여 개발 기간을 단축할 수 있음

- 개발 후반부에 발견될 결함을 예방할 수 있음

- 객관적인 시각에서 리뷰 및 인스펙션 미팅을 통해 테스트 대상 제품을 정확하고 깊이 파악한 후 테스팅을 수행할 수 있음

- 개발 초기에 테스트 전문가을 투입하여 절차에 따라 체계적으로 테스팅을 수행할 경우 동일하거나 높은 수준의 품질을 확보하면서 개발 프로젝트 기간을 전체적으로 단축시킬 수 있는 효과를 기대할 수 있음

- 개발 수명주기의 마지막 단계나 출시 이후 발견된 결함을 수정하기 위한 인적 물적 자원이 조기 테스팅에 비해 월등히 높음

4. 원리 4 - 결함 집중(Defect Clustering.) 

- 출시전 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임

- 개발자, 기능에 따라서 결함이 집중될 수 있음

1) 결함이 집중될 수 있는 모듈

- 자체적으로 복잡한 구조를 가지고 있는 모듈

- 소프트웨어나 시스템의 다른 부분 또는 다른 모듈과 다량의 복잡한  상호 작용을 하는 모듈(복잡한 인터페이스)

- 개발 난이도가 높거나 최신 기술을 사용한 모듈

- 기존에 개발된 것을 재사용하지 않고 새롭게 개발한 모듈

- 크기가 큰 모듈

- 경험이 미흡한 개발팀에서 개발한 모듈

5. 원리 5 - 살충제 패러독스(Pesticide Paradox)

- 동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행한다면, 나중에는 더 이상 새로운 결함을 찾아내지 못함

- 잠재된 많은 결함을 발견하기 위해서는 테스트 케이스를 정기적인 리뷰, 개선이 필요

- 테스트 케이스를 업데이트 하는 노력과 경험 기반 접근법(탐색적 테스팅, JIT 테스팅 등)을 통해 새로운 테스트 케이스를 추가하는 것이 필요

- 소프트웨어 또는 시스템의 다른 부분을 새롭고 다른 시각으로 테스트 하는 것이 필요

6. 원리 6 - 테스팅은 정황에 의존적이다.(Testing is context dependent.)

- 정황과 도메인(분야)에 따라 다르게 테스팅을 진행해야 함 (소프트웨어의 종류에 따라...)

1) 모든 테스팅에서 변하지 않는 사항

- 테스트 주요 활동에 대한 테스트 프로젝트 계획

- 표준적인 기법 적용(Technique)

- 독립적 테스트 환경

- 효율적 / 효과적 테스트 된 팀 조직

- 정식 리포팅 등

7. 원리 7 - 오류 - 부재의 궤변(Absence of error fallacy)

- 사용자 또는 비즈니스의 요구를 충족시켜주지 못한다면, 결함이 모두 발견하여 제거하였다고 하더라도 품질이 높다고 볼 수 없음

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

- 오류가 없다는 것이 제품이 올바로 동작한다는 것을 의미하는 것은 아님

- 요구사항에 부합하여 오류가 없어야만 함