원리1 - 테스팅은 결함이 존재함을 밝히는 활동이다.
테스팅은 소프트웨어에 잠재적으로 존재하는 결함을 줄일 수는 있지만, 결함이 전혀 발견되지 않은 경우라도 해당
소프트웨어에 결함이 없다고 증명할 수는 없다.
즉 테스팅은 결함이 존재함을 밝히는 것이다.
원리2 - 완벽한 테스팅은 불가능하다.
모든 가능성(입력과 사전 조건의 모든 조합)을 테스팅하는 것은 지극히 간단한 소프트웨어를 제외하고는 가능하지 않다. 일반적으로 완벽한 테스팅이 불가능한 이유는 다음과 같다.
- 한 프로그램 내의 내부조건이 무수히 많을 수 있음 (무한 경로)
- 입력이 가질 수 있는 모든 값의 조합이 무수히 많음 (무한 입력값)
- GUI 이벤트 발생 순서에 대한 조합도 무수히 많음 (무한 타이밍)
따라서 완벽한 테스팅보다는, 테스팅 대상의 리스크 분석을 토대로 테스트 활동의 노력을 차별화하는 것이 옳다.
우주항공, 의료 등 안전이 최우선인 소프트웨어를 개발하고 테스팅 할 때는 테스팅의 완벽함이 요구될 수 있겠지만, 이는 불가능한 목표이므로 일반적인 소프트웨어 테스팅보다 더 많은 노력과 리소스를 투입하여 강도 높게 수행하는 것이지 실제로 완벽한 테스트가 수행되는 것은 아니다.
원리3 - 결함 집중
출시 전 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보이며, 이러한 결함의 집중은 대부분 운영상의 장애를 초래한다. 일반적으로 결함이 집중될 수 있는 모듈들은 다음과 같다.
- 자체적으로 복잡한 구조를 가지고 있는 모듈
- 소프트웨어나 시스템의 다른 부분 또는 다른 모듈과 다량의 복잡한 상호 작용을 하는 모듈
- 개발 난이도가 높거나 최신 기술을 사용한 모듈
- 기존에 개발된 것을 재사용하지 않고 새롭게 개발한 모듈
- 크기가 큰 모듈
- 경험이 미흡한 개발팀에서 개발한 모듈
원리4 - 살충제 패러독스
동일한 테스트케이스로 동일한 테스트를 반복적으로 수행한다면, 나중에는 더 이상 새로운 결함을 찾아내지 못한다. 시스템에 잠재된 보다 많은 결함을 발견하기 위해서는 테스트케이스를 정기적으로 리뷰하고 개선할 필요가 있다.
공식적인 기법을 적용하여 설계된 테스트케이스 역시 반복적으로 수행되면 새로운 결함을 지속적으로 발견할 가능성은 낮아진다. 이런 경우, 해당 기법을 다른 모듈 또는 다른 시각에서 재적용시켜 테스트케이스를 업데이트하는 노력과 탐색적 테스팅, JIT 테스팅 등의 경험기반접근법을 통해 새로운 테스트케이스를 추가하는 것이 필요하다.
원리5 - 테스팅은 정황에 의존적이다.
테스팅은 정황에 따라 다르게 진행된다. 예를 들어, 안전-최우선 소프트웨어를 테스트하는 경우, 전자상거래 사이트를 테스트할 때와는 다른 방식으로 진행해야 한다.
이때, 정황과 도메인(분야)에 따라 다르게 테스팅을 진행해야 하지만 아래와 같이 모든 테스팅에서 변하지 않는 사항도 존재한다.
- 테스트 주요활동에 대한 테스트 프로젝트 계획
- 표준적인 기법 적용
- 독립적 테스트 환경
- 효율적/효과적 테스트 팀 조직
- 정식 리포팅 등
원리6 - 오류-부재의 궤변
개발된 시스템이 사용자의 필요와 기대에 부응하지 못하고 사용성이 현저히 낮다면 결함을 찾고 수정하는 과정은 아무 소용없다. 사용자 또는 비즈니스의 요구를 충족시켜주지 못한다면, 설사 결함을 모두 발견하여 제거하였다고 하더라도 품질이 높다고 볼 수는 없다.
원리5 - 테스팅은 정황에 의존적이다.
'품질 > 품질통제' 카테고리의 다른 글
| 의사결정 테이블 방식 (0) | 2021.12.13 |
|---|---|
| 리스크 분석 위험/품질요소를 고려해 기능테스트케이스 작업 후 테스트 진행하도록 하겠습니다. (0) | 2021.12.10 |
| 테스트 디자인이란 (0) | 2021.08.10 |
| 신규제품 버전 확인회귀 (임시)양식. (0) | 2021.08.06 |
| 결함 심각도 구분 기준 (0) | 2021.08.05 |
