1.3 테스팅의 일반적인 원리(General testing principles)
다수의 테스팅 원리가 지난 40여 년간 제안되어 왔으며 테스팅 전체에 대한 일반적인 가이드라인 역할을 해오고 있다.
원리 1 - 테스팅은 결함이 존재함을 밝히는 것(Testing shows presence of defects)
테스팅은 결함이 존재함을 드러내지만, 결함이 없다는 것을 증명할 수는 없다. 테스팅은 소프트웨어에 잔존하는 결함을 간과할 가능성을 줄이지만, 결함이 전혀 발견되지 않은 경우라도 결함이 없이 완전하다는 것을 증명하지는 못한다. 이는 소프트웨어 테스팅이 결함을 발견하는 메커니즘이라는 정의를 뒷받침하는 원리이다.
Testing can show that defects are presence, but 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.
원리 2 - 완벽한 테스팅은 불가능(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.
- 한 프로그램 내의 내부조건이 무수히 많을 수 있음(무한 경로)
- 입력이 가질 수 있는 모든 값의 조합이 무수히 많음(무한 입력값)
- GUI 이벤트 발생 순서에 대한 조합도 무수히 많음(무한 타이밍)
따라서 완벽한 테스팅 대신에, 리스크분석과 결정된 우선순위에 따라 테스팅 활동 노력을 집중시켜야 한다. (Risk-based testing)
완벽한 테스팅은 우주항공, 의료 등 안전이 최우선인(Safety critical) 소프트웨어를 개발할 때 고려할 수 있으나 실제로 완벽한 것은 아니고 강력한 테스팅으로 보면 된다. 대부분의 일반 소프트웨어는 완벽한 테스팅의 대상이 아니며 이런 경우 완벽하게 테스팅 하려는 시도는 불필요한 시간과 자원의 낭비로 볼 수 있다.
원리 3 - 개발 초기에 테스팅 시작(Early Testing)
테스팅 활동은 소프트웨어나 시스템 개발 수명주기에서 가능한 한 초기에 시작 되어야 하며, 정의된 테스팅 목표에 중점을 두어야 한다.
Testing activities should start as early as possible in the software or system development life cycle, and should be focused on defined objectives.
개발 초기에 테스팅을 시작한다는 것의 의미는 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근하는 것을 고려하는 것은 물론, 요구사항 분석서와 설계(기준)서 등의 개발 중간산출물을 분석하여 테스트 케이스를 도출하는 과정을 통해 결함을 발견하는 것을 말한다.
개발 과정에서 조기 테스트 설계(Early test design)를 하면, 코딩(Coding)이 끝나자마자 개발 초기부터 준비된 테스트 케이스를 테스트 레벨별로 실행하게 되므로 테스팅 결과를 단시간에 알 수 있고 테스팅 기간을 단축할 수 있다. 코딩에서의 재작업을 줄여 개발 기간을 단축할 수 있는 것은 물론, 개발 후반부에 발견될 결함을 "예방"할 수 있다. 이밖에도 시스템 테스팅을 독립적인 테스팅 팀에서 수행할 경우, 리뷰 및 인스펙션 미팅 등을 통해 테스트 대상 제품에 대해 정확하고 깊이 있게 파악한 후 테스팅을 수행할 수 있다는 장점이 있다.
개발 초기에 테스팅을 시작하는 것이 비즈니스적인 관점에서 쉽게 결정하여 투자할 수 있는 성격은 아니다. 그러나 적절하고 능력 있는 테스트 전문가를 개발 초기에 투입하여 절차에 따라 체계적으로 테스팅을 수행할 경우, 같은 수준 또는 더 높은 수준의 품질을 확보하면서 개발 프로젝트 기간을 전체적으로 단축시킬 수 있는 효과를 기대할 수 있다.
원리 4 - 결함 집중(Defect Clustering)
출시 전의 테스팅 기간 동안 적은 수의 모듈에서 대다수의 결함이 발견되거나, 대다수의 운영상의 장애가 나타난다.
A small number of modules contain most of the defects discovered during pre-release testing, or show the most operational failures.
일반적으로 다음과 같은 모듈에서 결함과 장애가 집중되는 현상을 발견할 수 있다.
- 자체적으로 복잡한 구조를 가지고 있는 모듈
- 소프트웨어나 시스템의 다른 부분 또는 다른 모듈과 복잡하고 많은 상호 작용을 하는 모듈(복잡한 인터페이스)
- 개발에 난이도가 높거나 최신 기술을 사용한 모듈
- 기존에 개발된 것을 재사용하지 않고 새롭게 개발된 모듈
- 크기가 큰 모듈
- 경험이 미흡한 개발팀에서 개발한 모듈
원리 5 - 살충제 패러독스(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 "pesticide paradox", 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.
테스트 케이스가 공식적인 기법을 사용하여 도출된 경우 테스트 케이스가 정형화되어 시간이 지날수록 새로운 결함을 발견하게 될 가능성이 낮아진다. 이런 경우, 해당 기법을 다른 모듈에 또는 다른 시각에서 재적용시켜 테스트 케이스를 업데이트하는 노력과, 탐색적 테스팅(Exploratory testing), JIT 테스팅(Just-in-time testing) 등의 경험기반 기법 또는 접근법을 통해 새로운 테스트 케이스를 더하고 늘려가는 것이 필요하다. 이때 새로운 테스트 케이스는 경험적으로 결함이 발견되었거나 발견될 가능성이 높은 모듈 또는 기능을 테스트 하거나, 비정상적인 기능 수행이나 입력 값으로 테스트하는 것 등을 의미한다.
원리 6 - 테스팅은 정황에 의존적(Testing is context dependent)
테스팅은 정황에 따라 다르게 진행된다. 예를 들어, 안전-최우선 소프트웨어를 테스트하는 경우, 전자 상거래 사이트를 테스트할 때와는 다르게 진행해야 한다.
Testing is done differently in diffenrent contexts. For example, safety-critical software is tested differently from an e-commerce site.
이때, 정황과 도메인 분야에 따라 다르게 테스팅을 진행해야 하지만 아래와 같이 모든 테스팅에서 변하지 않는 사항도 존재한다.
- 테스트 수명주기에 따른 테스트 프로젝트 계획(Life cycle, planning)
- 표준적인 기법 적용(Technique)
- 독립적 테스트 환경(Environment)
- 효율적/효과적 테스트 팀 조직(Organization)
- 정식 리포팅(Formal reporting) 등
원리 7 - 오류-부재의 궤변(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.
위 테스팅의 일반적인 원리를 정리해 보면, 소프트웨어 테스팅은 결함이 존재함을 밝히고 사용자와 비즈니스의 요구사항에 따라 테스트 대상 제품이 개발 되었는지 확인하는 것이고, 완벽한 테스팅이 불가능하므로 리스크 기반으로 결함이 집중되어 있을 만한 곳을 예측하여 가능한 개발 초기에 테스팅을 수행하는 것이다. 테스팅 시 테스트 대상 제품의 특성과 테스트 요구사항 등 테스트 정황을 반영하여 테스트를 설계하고 도출한 테스트 케이스는 지속적으로 업데이트하고 새로운 테스트 케이스를 추가하여 지속적으로 결함을 발견할 수 있도록 한다.
이외에도
소프트웨어 테스팅은 위험을 수반하는 훈련이다.
소프트웨어 테스터가 배워야 할 한가지 중요한 개념은 많은 영역의 테스트 대상을 테스트 가능한 범위로 축소하는 방법이다. 이렇게 하려면 무엇이 중요하고 무엇이 중요하지 않은지에 대하여 현명하게 판단하는 방법을 알아야 한다.
발견한 모든 버그를 수정할 수 없다.
소프트웨어 테스트 작업의 실상 중 하나는 버그를 찾아내기 위해 기울였던 많은 노력에도 불구하고 발견된 버그를 모두 수정할 수 없다는 사실이다.
버그를 수정하지 않기로 결정하는 이유는 아래와 같다.
- 쫓기는 작업 일정
- 진짜 버그가 아닌 경우
- 고치기 위험한 버그
- 고칠 가치가 없는 버그
"Effective" Testing and "Efficient" Testing
Why?
- 모든 결함을 발견하는 것은 불가능할 뿐 아니라 모든 것을 테스트하기에는 시간, 자금, 인력이 언제나 부족하다. 따라서 Must E&E
Effective
- 계획되었거나 원했던(decided or desired) 테스트 결과 산출
- 효과적 테스터는 테스팅 노력으로 부터 어떤 결과를 도출할 것인지를 결정함
- "Risk based testing"
Efficient
- 원했던(desired) 테스트 결과 산출을 생산적 (효율적)으로 수행
- 효율적 테스터는 이용가능한 리소스(시간, 비용, 인력)을 적절하고 현명하게 배치한다.
[출처] [ISTQB] 3. 테스팅 기본 원칙들|작성자 dejavu_blog