소프트웨어 테스팅은 무작위 활동이 아닙니다.
이는 정해진 목표와 전략에 따라 움직이는 체계적인 공학 활동입니다.
그 중심에는 수십 년간 쌓아온 경험과 지혜가 담긴 ‘기본 원칙’들이 있습니다.
ISTQB와 같은 국제 표준에서도 강조하는 이 ‘소프트웨어 테스팅의 7가지 원칙’을 알아봅니다.
이 원칙들은 QA 엔지니어가 더 현명한 의사결정을 내리도록 돕는 훌륭한 나침반입니다.
Q. 원칙 1: 테스팅은 ‘결함이 존재함’을 밝히는 활동이다?
네, 맞습니다.
테스트의 목적은 소프트웨어에 결함이 ‘없음’을 증명하는 것이 아닙니다.
오직 숨어있는 결함이 ‘있음’을 드러내는 것입니다.
아무리 많은 테스트를 통과했더라도 마찬가지입니다.
아직 발견되지 않은 결함이 존재할 수 있다는 겸손한 자세가 필요합니다.
우리는 완벽함을 증명하는 것이 아닙니다.
제품 출시의 위험(risk)을 줄여나가는 것입니다.
이 첫 번째 ‘테스팅 원칙’은 QA의 기본적인 마음가짐을 정의합니다.
Q. 원칙 2: ‘완벽한 테스팅(Exhaustive Testing)’은 불가능하다?
네, 현실적으로 불가능합니다.
입력값, 실행 순서, 사용 환경 등 모든 경우의 수를 테스트하는 것은 아닙니다.
이는 엄청난 시간과 비용 낭비로 이어질 수 있습니다.
실제 예시:
이름을 입력하는 간단한 입력창 하나만 생각해 봅시다.
한글, 영어, 숫자, 특수문자를 각각 몇 글자까지 입력할 수 있을까요?
이 모든 조합을 고려하면 경우의 수는 무한에 가깝습니다.
따라서 우리는 ‘리스크 분석’과 ‘우선순위 설정’을 해야 합니다.
이를 통해 가장 중요하고 위험도가 높은 영역에 한정된 테스트 노력을 집중해야 합니다.
이 ‘소프트웨어 테스팅 원칙’은 우리에게 ‘선택과 집중’의 중요성을 알려줍니다.
Q. 원칙 3: 테스팅은 ‘개발 초기에’ 시작해야 한다?
네, 무조건 빠를수록 좋습니다.
이는 ‘Shift Left’ 원칙과도 정확히 일치합니다.
개발의 초기 단계, 즉 요구사항 분석이나 설계 단계에서 발견된 결함은 간단히 해결됩니다.
보통 문서 몇 줄을 고치는 것으로 충분합니다.
하지만 모든 개발이 끝난 후반부에 발견된 동일한 결함은 다릅니다.
이미 만들어진 수많은 코드를 수정하고, 처음부터 다시 테스트해야 합니다.
이 과정에서 훨씬 더 큰 비용이 발생합니다.
Q. 원칙 4: ‘결함은 특정 모듈에 집중’되는 경향이 있다?
네, 그렇습니다.
파레토 법칙(80/20 법칙)처럼, 대부분의 결함은 전체 소프트웨어의 아주 작은 일부에서 발견됩니다.
즉, 소수의 특정 모듈에 결함이 집중되는 경향이 있습니다.
QA 적용 팁:
보통 시스템의 복잡도가 높거나, 최근 변경이 잦았거나, 새로운 기술이 적용된 모듈에 버그가 집중될 확률이 높습니다.
전문 QA는 이러한 ‘결함 집중’ 영역을 데이터에 기반하여 식별해야 합니다.
그리고 해당 부분에 대한 테스트를 다른 부분보다 더 강화하는 전략을 사용해야 합니다.
Q. 원칙 5: ‘살충제 패러독스(Pesticide Paradox)’란 무엇인가요?
똑같은 살충제를 계속 뿌리면 벌레에게 내성이 생겨 더 이상 효과가 없어지는 현상입니다.
소프트웨어 테스팅도 마찬가지입니다.
‘똑같은 테스트 케이스’를 반복적으로 계속 실행하면, 더 이상 새로운 종류의 버그를 발견할 수 없게 됩니다.
우리의 테스트가 그 버그들에 ‘내성’을 갖게 된 것입니다.
QA 적용 팁:
이 패러독스를 피하기 위해, QA는 기존의 테스트 케이스를 주기적으로 검토하고 개선해야 합니다.
항상 새로운 데이터 조합을 사용하려는 노력이 필요합니다.
또한, ‘탐색적 테스팅’과 같은 다른 접근법을 병행하여 테스트의 신선도를 유지해야 합니다.
이를 통해 새로운 유형의 결함을 찾아낼 수 있습니다.
Q. 원칙 6: 테스팅은 ‘상황에 의존적’이다?
네, 모든 상황에 적용할 수 있는 단 하나의 완벽한 테스트 전략은 존재하지 않습니다.
예를 들어, 생명과 직결된 의료 기기 소프트웨어의 테스트 전략이 있습니다.
그리고 간단한 이벤트 홍보용 웹사이트의 테스트 전략이 있습니다.
이 둘은 완전히 달라야 합니다.
전자는 안전성과 정확성에 모든 것을 집중해야 합니다.
후자는 다양한 브라우저 호환성에 더 집중해야 할 것입니다.
프로젝트의 성격, 리스크, 제약 조건 등 주어진 ‘상황’에 맞게 테스트 전략은 항상 다르게 수립되어야 합니다.
Q. 원칙 7: ‘오류 부재의 궤변(Absence-of-Errors Fallacy)’은 무엇인가요?
소프트웨어에서 버그를 하나도 발견하지 못했다고 해서, 그 소프트웨어가 사용자의 요구를 만족시키는 ‘좋은’ 소프트웨어라고 착각해서는 안 된다는 의미입니다.
버그는 없지만, 정작 사용자가 전혀 원하지 않는 기능일 수 있습니다.
혹은, 사용하기에 너무나 불편해서 아무도 쓰지 않을 수도 있습니다.
이런 제품은 시장에서 실패한 것입니다.
QA 적용 팁:
QA는 결함을 찾아내는 활동(Verification)뿐만 아니라, ‘우리가 올바른 제품을 만들고 있는가(Validation)’를 항상 함께 고민해야 합니다.
이것이 바로 이 ‘테스팅 원칙’이 주는 교훈입니다.
결론: 현명한 테스터를 위한 지침
‘소프트웨어 테스팅의 7가지 원칙’은 반드시 지켜야 할 엄격한 규칙이 아닙니다.
우리가 더 현명한 테스트 관련 의사결정을 내릴 수 있도록 돕는 ‘가이드 철학’입니다.
이 원칙들을 마음속에 새겨두면, 한정된 시간과 자원 속에서 어떻게 테스트하는 것이 가장 효과적인지 판단할 수 있습니다.
그리고 테스트의 가치와 한계를 팀원들에게 설득력 있게 전달하는 데 큰 도움이 될 것입니다.