[QA Basics] 테스트 원칙

테스트는 “결함 제거”를 넘어서, “리스크 관리와 사용자 신뢰 확보”를 위한 필수 활동이다.

소프트웨어 테스트는 몇 가지 기본 철학을 바탕으로 합니다.
국제적으로 가장 많이 인용되는 ISTQB의 7가지 원칙은 테스트 활동의 핵심 가이드라인입니다.

테스팅은 결함의 존재를 보여줄 뿐, 무결성을 증명하지 못한다
- 테스트는 “버그가 있다”는 증거는 줄 수 있지만
  “버그가 전혀 없다”는 걸 보장할 수는 없다.
완벽한 테스팅은 불가능하다
- 모든 입력·경우의 수를 전부 확인할 수 없음
- 위험 기반 테스트, 우선순위 설정이 필요하다.
초기 테스팅은 결함 발견 비용을 줄인다
- 요구사항·설계 단계에서 테스트를 시작할수록 결함을 수정하는 비용이 크게 줄어든다.
결함은 특정 부분에 집중된다 (결함 집중 현상)
- 전체 코드 중 일부 모듈/기능에 결함이 몰리는 경향이 있다.
- 위험도가 높은 영역에 테스트를 집중해야 한다.
살충제 패러독스
- 같은 테스트를 반복하면 새로운 결함 발견 효과가 줄어든다.
- 테스트 케이스는 주기적으로 개선·보완해야 한다.
테스팅은 상황에 의존한다
- 금융 앱, 게임, 임베디드 시스템처럼 도메인마다 요구되는 테스트 방식이 다르다.
오류 부재의 궤변
- 결함이 없더라도 요구사항을 충족하지 못하면 품질이 낮다.
- 즉, “올바른 제품”을 만드는 것이 목표이지
  단순히 “버그 없는 코드”가 목표는 아니다.

테스트의 원칙은 “모든 결함을 없애는 것”이 아니라,
“효율적으로 리스크를 줄이고, 사용자 요구를 충족하는 것”에 초점이 있다.

결함 존재 증명 (원칙 1)
- “버그 없음”을 목표로 하지 않고, 위험도 높은 영역 우선 탐색
- 예: 결제 모듈, 로그인 보안 기능 집중 테스트
완벽한 테스팅 불가능 (원칙 2)
- 전체 케이스 대신 경계값·대표값 중심으로 테스트 설계
- 예: 입력값이 0, 최대치, 공백일 때만 우선 검증
초기 테스팅 (원칙 3)
- 기획서 리뷰 단계에서 QA 참여
- 예: 요구사항 문서에서 모호한 부분을 미리 지적
결함 집중 (원칙 4)
- 과거에 결함이 많이 나온 모듈에 회귀 테스트 집중
- 예: 버전업 때마다 자주 깨지는 기능 자동화로 커버
살충제 패러독스 (원칙 5)
- 테스트 케이스를 주기적으로 업데이트
- 예: 신규 기능 추가 시 기존 케이스에 새로운 시나리오 반영
상황 의존성 (원칙 6)
- 도메인에 맞는 기법 선택
- 예: 금융권 → 보안 테스트 강화, 게임 → 성능·동시접속 테스트 강화
오류 부재의 궤변 (원칙 7)
- 단순히 “버그 없음” 보고 대신, 사용자 요구 충족 여부를 점검
- 예: 앱이 오류 없이 실행돼도 UX가 불편하면 품질 부족으로 판단

테스트 원칙은 QA가 한정된 시간과 자원 안에서
무엇을, 어떻게, 어디에 집중해야 하는지 방향을 제시하는 가이드이다.

meowdule