(1주 4일차) QA의 헌법! 7가지 테스팅 원칙

 

안녕하세요, QA여행 ( https://qajourney.tistory.com/ ) 입니다.

챌린지 4일차에 오신 여러분을 환영합니다!

 

어제는 QA 엔지니어의 하루를 따라가며 실무의 생생한 모습을 엿보았죠.

정신없이 진행되는 테스트, 동료들과의 끊임없는 소통 속에서 QA는 어떤 기준과 철학을 가지고 일하는 걸까요?

오늘은 바로 그 길잡이가 되어주는, QA라면 반드시 마음에 새겨야 할 '7가지 테스팅 원칙'에 대해 알아보겠습니다.

이 원칙들은 ISTQB의 핵심이자, 우리의 모든 테스트 활동에 '왜?'라는 근거를 제공해 주는 든든한 뼈대입니다.

 

QA의 의사결정을 돕는 7가지 원칙

이 원칙들은 단순히 외워야 할 목록이 아닙니다.

제한된 시간과 자원 속에서 '어떻게 하면 더 효율적이고 효과적으로 테스트할 수 있을까?'라는 질문에 대한 답을 주는 실용적인 지침서입니다.

 

원칙 1: 테스팅은 '결함이 존재함'을 밝히는 활동이다.

(Testing shows the presence of defects)

테스트를 통해 수많은 버그를 찾아냈다고 해서, "이 소프트웨어에는 더 이상 버그가 없다"라고 증명할 수는 없습니다.

마치 의사가 건강검진을 통해 몇 가지 질병을 찾아냈다고 해서 그 환자가 '완벽하게 건강하다'고 말할 수 없는 것과 같습니다.

우리는 테스트를 통해 숨어있는 결함의 존재를 드러낼 뿐, 결함이 없음을 증명할 수는 없습니다.

이 원칙은 우리에게 겸손한 자세를 갖게 합니다.

 

원칙 2: 완벽한 테스팅(Exhaustive testing)은 불가능하다.

(Exhaustive testing is impossible)

간단한 이름 입력 필드 하나만 해도 테스트할 수 있는 경우의 수는 거의 무한대에 가깝습니다.

모든 입력값, 모든 조합, 모든 환경을 다 테스트하는 것은 현실적으로 불가능하며, 시간과 비용 측면에서도 비효율적입니다.

따라서 우리는 리스크 분석과 우선순위 설정을 통해 '어디에 집중할 것인지'를 현명하게 선택해야 합니다.

 

원칙 3: 조기 테스팅(Early testing)은 시간과 비용을 절약한다.

(Early testing saves time and money)

요구사항 단계는 비용이 매우 낮고, 배포 후 단계는 기하급수적으로 높아진다.

 

집을 짓기 전, 설계도 상의 오류를 수정하는 데는 종이와 연필만 있으면 되지만,

집을 다 지은 후에 벽을 허물고 다시 지으려면 엄청난 비용이 듭니다.

소프트웨어도 마찬가지입니다.

개발 초기 단계(요구사항 분석, 설계)에서 결함을 발견하면 수정 비용이 훨씬 저렴합니다.

이것이 바로 QA가 개발 초기 단계부터 적극적으로 참여해야 하는 이유입니다.

 

원칙 4: 결함은 특정 모듈에 집중되는 경향이 있다.

(Defects cluster together)

파레토 법칙(80/20 법칙)과 유사하게, 소프트웨어의 소수(20%) 모듈에서 대다수(80%)의 결함이 발견되는 경우가 많습니다.

복잡하고, 오래되었거나, 변경이 잦은 모듈에 결함이 몰려있는 것이죠.

이 원칙을 알면 우리는 결함이 집중될 것으로 예상되는 '핫스팟(Hot spot)'에 테스트 자원을 집중하여 효율성을 높일 수 있습니다.

 

원칙 5: 살충제 패러독스(Pesticide paradox)에 유의해야 한다.

(Beware of the pesticide paradox)

매번 똑같은 살충제를 뿌리면 벌레에게 내성이 생겨 더 이상 효과가 없어지는 것처럼,

매번 똑같은 테스트 케이스만 반복해서 실행하면 더 이상 새로운 결함을 찾아내지 못합니다.

따라서 우리는 기존 테스트 케이스를 주기적으로 검토하고, 새로운 테스트 케이스를 추가하며,

다른 관점에서 테스트를 시도하는 노력이 필요합니다.

 

원칙 6: 테스팅은 정황(Context)에 의존적이다.

(Testing is context-dependent)

은행 앱을 테스트하는 것과, 간단한 홍보용 웹사이트를 테스트하는 것은 접근 방식이 완전히 달라야 합니다.

은행 앱은 보안성과 정확성이 무엇보다 중요하고, 홍보 웹사이트는 사용성이나 다양한 브라우저 호환성이 더 중요할 수 있습니다.

이처럼 소프트웨어의 성격과 목적, 기술 스택 등 주어진 '정황'에 따라 테스트의 우선순위와 전략은 달라져야 합니다.

 

원칙 7: '오류-부재의 궤변'을 경계해야 한다.

(Absence-of-errors fallacy)

수많은 테스트를 통해 버그를 모두 잡았다고 해도,

그 소프트웨어가 사용자의 요구사항을 만족시키지 못하고 아무도 원하지 않는 기능이라면 아무런 가치가 없습니다.

즉, '결함이 없는 것'이 '품질이 높은 것'과 동의어는 아닙니다.

진정한 품질은 사용자의 필요를 충족시키고 가치를 제공하는 데서 나옵니다.

 

마무리하며

오늘 살펴본 7가지 원칙은 우리가 앞으로 마주할 수많은 테스트 상황에서

길을 잃지 않고 현명한 판단을 내릴 수 있도록 돕는 나침반과 같습니다.

지금 당장 모든 것을 외울 필요는 없습니다.

앞으로 챌린지를 진행하며 각 원칙이 실제 사례에 어떻게 녹아있는지 계속해서 보여드릴게요.

오늘도 한 걸음 더 성장하신 여러분을 응원합니다.

정말 수고 많으셨습니다.

 

내일 5일차에는 오늘 배운 7가지 원칙이 실제 업무 현장에서 어떻게 적용되는지,

생생한 사례를 통해 알아보는 시간을 갖겠습니다.

이론과 실전이 만나는 흥미로운 시간이 될 거예요!

그럼 내일 다시 뵙겠습니다!