소프트웨어 테스트의 기본 원칙

1) 테스트는 결함의 존재만 보여준다

• 테스트로 “버그가 있다”는 건 입증 가능하지만, “버그가 없다”는 건 증명 불가.
  예) 100건 통과해도 숨은 결함이 있을 수 있음.

2) 완전(전수) 테스트는 불가능

• 모든 입력/경로/조합을 전부 검증하는 건 현실적으로 불가 → 우선순위/리스크 기반으로 선택.
  예) 경계값·핵심 시나리오부터.

3) 초기(조기) 테스트

• 결함은 빠를수록 고치기 싸고 쉽다. 요구/설계 단계부터 리뷰·테스트 시작.
  예) 요구 명세 리뷰로 결함을 개발 전 제거.

4) 결함 집중(파레토)

• 소수의 모듈/기능에 결함이 집중되는 경향(80/20).
  예) 변경 잦은 모듈에 테스트를 더 집중.

5) 살충제 패러독스

• 같은 테스트만 반복하면 새 결함을 못 잡는다 → 테스트 케이스를 주기적으로 갱신.
  예) 새 경계·조합·데이터로 보강.

6) 테스트는 문맥(컨텍스트) 의존

• 안전/금융/임베디드 vs. 웹 서비스는 기준·기법·엄격도가 다르다.
  예) 항공 SW는 MC/DC, 일반 웹은 기능/회귀 자동화 중심.

7) 에러 부재의 궤변(Absence-of-errors fallacy)

• 결함을 많이 고쳤어도 사용자 요구에 맞지 않으면 실패.
  예) 성능·사용성 요구 미충족이면 “정확하지만 쓸모없는” 제품.