소프트웨어 테스팅에는 몇 가지 핵심 원칙이 있으며, 이를 이해하면 테스트 전략을 효과적으로 수립하고, 한계를 명확히 인식할 수 있다
1. 테스팅은 결함의 존재를 밝히는 활동이다 (Bug Detection)
- 테스팅은 결함이 있음을 증명할 수 있지만, 결함이 없음을 보장할 수 없다
- 결함이 발견되지 않았다고 해서 소프트웨어가 완벽하다는 의미는 아님
즉, 테스팅은 결함을 줄이는 과정이지, 결함이 없음을 증명하는 과정이 아님
2. 완벽한 테스팅은 불가능하다 (Impossible to Test Everything)
- 모든 기능을 100% 테스트하는 것은 현실적으로 불가능
- 테스트 기법, 우선순위 지정, 리스크 기반 테스팅을 활용하여 중요한 부분에 집중해야 함
즉, 모든 것을 테스트하려 하기보다는, 효율적으로 중요한 부분을 테스트하는 것이 중요
3. 조기 테스팅으로 시간과 비용을 절약할 수 있다 (Early Testing Saves Cost & Time)
- 개발 초기 단계에서 결함을 발견하면, 후반부에서 발생하는 장애를 줄일 수 있음
- 결함이 조기에 발견될수록 수정 비용이 줄어듦
즉, 개발 초기부터 정적 테스팅(문서 검토, 코드 리뷰)과 동적 테스팅을 병행하는 것이 중요
4. 결함은 집중된다 (Defect Clustering, 파레토 법칙 적용)
- 소프트웨어 결함의 대부분은 특정 모듈이나 컴포넌트에서 집중적으로 발생하는 경향이 있음
- 이 현상은 80:20 법칙(파레토 원리)에 해당
- 이전 테스트 및 운영 데이터를 분석하여 결함이 집중되는 영역을 우선적으로 테스트해야 함
즉, 모든 부분을 동일하게 테스트하기보다, 결함 발생 가능성이 높은 부분에 테스트를 집중해야 함
5. 테스트 효과는 줄어든다 (Pesticide Paradox, 살충제 패러독스)
- 같은 테스트를 반복하면, 결국 신규 결함을 발견하는 효과가 감소함
- 기존 테스트 케이스를 수정하거나 새로운 테스트를 추가하여 효과를 극대화해야 함
- 하지만 자동화된 리그레션 테스팅처럼 반복 테스트가 필요한 경우도 있음
즉, 테스트 케이스를 지속적으로 개선하지 않으면, 테스트 효과가 감소할 수 있음
6. 테스팅은 정황에 의존적이다 (Context-Dependent Testing)
- 모든 소프트웨어에 적용할 수 있는 하나의 테스트 전략은 없음
- 테스트 방식은 프로젝트 유형, 비즈니스 요구사항, 리스크 수준 등에 따라 달라짐
즉, 게임 소프트웨어, 금융 시스템, 의료 소프트웨어 등은 각각 다른 테스트 전략이 필요함
7. 결함-부재는 궤변이다 (Absence-of-Defects Fallacy)
- 결함을 모두 수정했다고 해서 소프트웨어가 성공적인 것은 아님
- 소프트웨어가 사용자 요구사항을 충족하지 않으면, 결함이 없어도 의미 없는 시스템이 될 수 있음
- 따라서 베리피케이션(요구사항 충족 여부)뿐만 아니라, 밸리데이션(사용자 기대 충족 여부)도 중요함
즉, 결함을 줄이는 것만이 아니라, 사용자의 실제 기대와 비즈니스 목표를 충족하는 것이 더 중요함
생각을 하자💡