SW 테스팅의 일반적인 원리 7가지와 실전 적용법

소프트웨어 품질을 높이려면 단순히 테스트 케이스를 많이 실행하는 것보다 테스팅의 일반적인 원리를 이해하는 것이 먼저입니다. 이 글에서는 ISTQB에서 다루는 테스팅의 7가지 원리를 초보자도 이해할 수 있도록 사례 중심으로 풀어보고, 실제 프로젝트와 테스트자동화에 어떻게 적용할 수 있는지 정리합니다.

왜 테스팅의 원리를 먼저 알아야 할까?

많은 초보자는 테스팅을 “개발이 끝난 뒤 오류를 찾는 작업” 정도로 이해합니다. 하지만 실제 현장에서 테스팅은 단순한 버그 찾기가 아니라, 제품 리스크를 줄이고 의사결정을 돕는 활동에 가깝습니다.

예를 들어 쇼핑몰 결제 시스템을 개발한다고 가정해 보겠습니다. 화면 버튼이 정상적으로 눌리는지 확인하는 것도 중요하지만, 더 중요한 것은 다음과 같은 질문입니다.

• 사용자가 결제 중 네트워크가 끊기면 어떻게 되는가?
• 중복 결제가 발생할 가능성은 없는가?
• 쿠폰, 포인트, 카드 할인 조합에서 계산 오류가 생기지 않는가?
• 장애가 발생했을 때 주문 상태는 안전하게 복구되는가?

이런 질문에 답하려면 무작정 테스트를 많이 하는 방식만으로는 부족합니다. 테스팅의 일반적인 원리를 알고 있어야 어떤 테스트를 우선해야 하는지, 어디에 리소스를 집중해야 하는지 판단할 수 있습니다.

원리 1: 테스팅은 결함이 존재함을 밝히는 것

첫 번째 원리는 “테스팅은 결함이 있음을 보여줄 수는 있지만, 결함이 없음을 증명할 수는 없다”는 것입니다.

예를 들어 로그인 기능을 테스트한다고 해보겠습니다. 올바른 아이디와 비밀번호로 로그인되는지 확인했고, 잘못된 비밀번호를 입력했을 때 오류 메시지도 확인했습니다. 그렇다고 해서 로그인 기능에 결함이 전혀 없다고 말할 수 있을까요? 아닙니다.

다음과 같은 결함은 여전히 숨어 있을 수 있습니다.

• 특정 특수문자가 포함된 비밀번호에서 오류 발생
• 동시에 여러 기기에서 로그인할 때 세션 충돌
• 비밀번호 재설정 링크 만료 처리 오류
• 소셜 로그인과 일반 로그인 계정 연결 문제

즉, 테스팅은 “문제가 없다”를 증명하는 활동이 아니라 “문제가 있는 부분을 발견하고 리스크를 줄이는 활동”입니다. 이 원리를 이해하면 테스트 결과를 해석하는 태도가 달라집니다.

“테스트를 통과했으니 완벽하다”가 아니라 “현재 설계한 테스트 범위에서는 치명적인 문제가 발견되지 않았다”라고 표현하는 것이 더 정확합니다.

원리 2: 완벽한 테스팅은 불가능하다

두 번째 원리는 완벽한 테스팅은 불가능하다는 것입니다. 모든 입력값, 모든 조합, 모든 환경을 테스트하는 것은 현실적으로 불가능합니다.

간단한 예로 회원가입 화면을 생각해 보겠습니다. 이름, 이메일, 비밀번호, 휴대폰 번호, 추천인 코드, 약관 동의 여부가 있다고 할 때 가능한 조합은 매우 많습니다. 여기에 브라우저, 운영체제, 모바일 기기, 네트워크 상태까지 포함하면 테스트 경우의 수는 폭발적으로 증가합니다.

따라서 실무에서는 “전부 테스트하자”가 아니라 “위험도가 높은 부분을 우선 테스트하자”는 접근이 필요합니다.

예를 들어 금융 앱에서는 버튼 색상보다 다음 영역이 훨씬 중요합니다.

• 송금 금액 계산
• 계좌 잔액 반영
• 인증 실패 처리
• 중복 요청 방지
• 거래 내역 저장

완벽한 테스팅이 불가능하다는 사실은 포기가 아니라 전략의 출발점입니다. 제한된 시간과 인력 안에서 무엇을 먼저 검증할지 결정하는 것이 좋은 테스팅의 핵심입니다.

원리 3: 개발 초기에 테스팅을 시작해야 한다

세 번째 원리는 개발 초기에 테스팅을 시작해야 한다는 것입니다. 많은 프로젝트에서 테스트는 개발이 끝난 뒤 QA 단계에서 시작된다고 생각하지만, 결함은 늦게 발견될수록 수정 비용이 커집니다.

예를 들어 요구사항 단계에서 “회원은 주문을 취소할 수 있다”라는 문장이 있다고 해보겠습니다. 이 문장은 단순해 보이지만 실제로는 여러 질문을 포함합니다.

• 결제 전 주문도 취소 가능한가?
• 배송 준비 중에도 취소 가능한가?
• 이미 배송된 주문은 반품으로 처리해야 하는가?
• 쿠폰을 사용한 주문 취소 시 쿠폰은 복구되는가?
• 부분 취소가 가능한가?

이 질문을 개발 완료 후에 발견하면 기능 구조를 다시 바꿔야 할 수 있습니다. 반면 요구사항 리뷰 단계에서 발견하면 문서 수정만으로 큰 문제를 예방할 수 있습니다.

초기 테스팅은 꼭 코드를 실행하는 것만 의미하지 않습니다. 다음 활동도 모두 테스팅의 일부입니다.

• 요구사항 리뷰
• 화면 설계서 검토
• API 명세 검토
• 데이터 흐름 검토
• 예외 상황 도출
• 사용자 시나리오 검토

초보자라면 “테스트는 언제 시작해야 하나?”라는 질문에 “요구사항이 보이는 순간부터”라고 기억하면 좋습니다.

원리 4: 결함 집중은 실제 프로젝트에서 자주 발생한다

네 번째 원리는 결함 집중입니다. 결함은 전체 시스템에 균등하게 퍼져 있기보다 특정 모듈이나 기능에 집중되는 경향이 있습니다.

예를 들어 온라인 교육 플랫폼에서 다음과 같은 기능이 있다고 가정해 보겠습니다.

• 회원가입
• 강의 목록 조회
• 동영상 재생
• 수강권 결제
• 쿠폰 적용
• 진도율 저장
• 수료증 발급

이 중 결함이 가장 많이 발생하는 영역은 단순 목록 조회보다는 결제, 쿠폰, 진도율 저장처럼 조건이 복잡하고 외부 시스템과 연동되는 부분일 가능성이 큽니다.

실제 프로젝트에서도 버그 리포트를 분석해 보면 특정 기능, 특정 개발 영역, 특정 변경 이력에서 결함이 반복적으로 발생하는 경우가 많습니다. 이때 중요한 것은 “모든 영역을 동일한 강도로 테스트하는 것”이 아니라 “결함이 집중되는 영역을 찾아 테스트 강도를 높이는 것”입니다.

사례 분석 관점에서 보면, 결함 집중 원리는 테스트 우선순위를 정하는 데 매우 유용합니다.

• 최근 변경된 기능인가?
• 요구사항이 자주 바뀌었는가?
• 개발자가 어렵다고 말한 영역인가?
• 외부 API나 결제 시스템과 연결되는가?
• 장애 발생 시 사용자 피해가 큰가?

이 질문에 많이 해당할수록 더 깊게 테스트해야 합니다.

원리 5: 살충제 패러독스와 테스트 케이스의 노후화

다섯 번째 원리는 살충제 패러독스입니다. 같은 살충제를 계속 사용하면 해충이 내성을 갖듯이, 같은 테스트 케이스만 반복하면 새로운 결함을 발견하기 어려워진다는 의미입니다.

예를 들어 매번 로그인 테스트를 다음 순서로만 수행한다고 해보겠습니다.

1. 정상 아이디 입력 2. 정상 비밀번호 입력 3. 로그인 버튼 클릭 4. 메인 화면 진입 확인

이 테스트는 기본 동작 확인에는 유용하지만 시간이 지나면 새로운 결함을 찾는 힘이 약해집니다. 특히 기능이 변경되었는데도 테스트 케이스를 업데이트하지 않으면 테스트는 형식적인 절차가 됩니다.

살충제 패러독스를 피하려면 테스트 케이스를 주기적으로 개선해야 합니다.

• 최근 발생한 운영 장애를 테스트 케이스에 반영
• 사용자 문의가 많은 시나리오 추가
• 경계값과 예외값 보강
• 새로운 브라우저나 디바이스 환경 반영
• 테스트자동화 스크립트의 검증 포인트 점검

특히 테스트자동화에서는 이 원리가 더 중요합니다. 자동화된 테스트가 매일 통과하더라도 검증 내용이 오래되었거나 핵심 리스크를 반영하지 못하면 품질 보증 효과가 떨어집니다. 자동화는 “반복 실행”의 도구이지, “항상 충분한 검증”을 보장하는 마법이 아닙니다.

원리 6: 테스팅은 정황에 의존적이다

여섯 번째 원리는 테스팅은 정황에 의존적이라는 것입니다. 모든 프로젝트에 동일한 테스트 전략을 적용할 수는 없습니다.

예를 들어 게임 앱, 병원 예약 시스템, 인터넷뱅킹, 사내 관리자 페이지는 모두 테스트 방식이 달라야 합니다.

게임 앱에서는 사용자 경험, 성능, 다양한 기기 호환성이 중요할 수 있습니다. 반면 인터넷뱅킹에서는 보안, 거래 정확성, 인증, 장애 복구가 훨씬 중요합니다. 병원 예약 시스템에서는 개인정보 보호와 예약 충돌 방지가 핵심일 수 있습니다.

즉, 좋은 테스팅은 “많이 테스트하는 것”이 아니라 “상황에 맞게 테스트하는 것”입니다.

정황을 판단할 때는 다음 요소를 고려해야 합니다.

• 서비스의 비즈니스 중요도
• 장애 발생 시 피해 규모
• 사용자 수와 사용 환경
• 법적·보안 요구사항
• 개발 일정과 배포 주기
• 기존 결함 이력
• 테스트 인력과 도구 수준

초보자가 흔히 하는 실수는 다른 회사나 다른 프로젝트의 테스트 체크리스트를 그대로 가져오는 것입니다. 참고는 가능하지만, 반드시 현재 제품의 맥락에 맞게 조정해야 합니다.

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

일곱 번째 원리는 오류-부재의 궤변입니다. 결함을 많이 제거했다고 해서 사용자가 원하는 제품이 되는 것은 아니라는 뜻입니다.

예를 들어 어떤 배달 앱이 기술적으로는 오류 없이 동작한다고 해보겠습니다. 앱이 멈추지 않고, 결제도 되고, 주문도 정상적으로 접수됩니다. 하지만 사용자가 원하는 가게를 찾기 어렵고, 배달 예상 시간이 부정확하며, 쿠폰 적용 방법이 복잡하다면 좋은 제품이라고 보기 어렵습니다.

즉, 버그가 없다는 것과 가치 있는 제품이라는 것은 다릅니다.

이 원리는 QA와 테스터에게 중요한 시사점을 줍니다. 테스트는 단순히 명세서대로 동작하는지 확인하는 데 그치지 않고, 사용자의 목적이 실제로 달성되는지도 살펴야 합니다.

예를 들어 다음 질문을 던져볼 수 있습니다.

• 사용자가 이 기능을 쉽게 이해할 수 있는가?
• 실제 업무 흐름과 맞는가?
• 불필요하게 많은 단계를 요구하지 않는가?
• 오류 메시지가 사용자의 다음 행동을 안내하는가?
• 기능은 정상이어도 사용자 경험상 불편한 부분은 없는가?

오류-부재의 궤변을 이해하면 테스팅의 관점이 “결함 찾기”에서 “제품 가치 검증”으로 확장됩니다.

테스트자동화와 7가지 원리의 연결

최근 많은 팀이 테스트자동화를 도입하고 있습니다. 배포 주기가 짧아지고, 애자일과 DevOps 환경에서 반복 테스트가 많아졌기 때문입니다. 하지만 자동화 도입이 곧 좋은 테스팅을 의미하지는 않습니다.

테스트자동화에도 테스팅의 7가지 원리는 그대로 적용됩니다.

예를 들어 자동화 테스트가 500개 있다고 해도, 중요한 결제 시나리오를 검증하지 못하면 품질 리스크는 여전히 큽니다. 반대로 자동화 테스트 수는 적어도 핵심 사용자 흐름과 회귀 위험이 높은 기능을 잘 검증한다면 더 효과적일 수 있습니다.

자동화 적용 시 원리별로 생각해보면 다음과 같습니다.

• 결함 존재 증명: 자동화는 결함 발견 가능성을 높일 뿐, 무결함을 증명하지 않는다.
• 완벽한 테스팅 불가능: 모든 케이스를 자동화하려 하지 말고 우선순위를 정해야 한다.
• 조기 테스팅: 단위 테스트, API 테스트를 개발 초기에 연결해야 한다.
• 결함 집중: 결함이 반복되는 모듈부터 자동화 우선순위를 둔다.
• 살충제 패러독스: 자동화 스크립트도 주기적으로 갱신해야 한다.
• 정황 의존성: UI 자동화, API 자동화, 성능 테스트 중 무엇이 필요한지 프로젝트별로 다르다.
• 오류-부재의 궤변: 자동화 통과가 사용자 만족을 보장하지 않는다.

따라서 테스트자동화는 원리를 대체하는 도구가 아니라, 원리를 실천하기 위한 수단으로 이해해야 합니다.

실전 적용 방법: 프로젝트에서 어떻게 써먹을까?

테스팅의 일반적인 원리를 실제 업무에 적용하려면 추상적인 개념을 행동으로 바꾸는 것이 중요합니다. 다음은 초보자도 바로 적용할 수 있는 방법입니다.

첫째, 테스트 시작 전에 리스크 목록을 작성합니다. 기능별로 장애가 발생했을 때의 영향도를 간단히 표시합니다. 예를 들어 “결제 실패”, “중복 주문”, “개인정보 노출”처럼 사용자 피해가 큰 항목은 우선순위를 높입니다.

둘째, 요구사항 리뷰 단계에서 테스트 관점의 질문을 던집니다. “정상 동작”뿐 아니라 “예외 상황”을 반드시 확인해야 합니다.

셋째, 테스트 케이스를 작성할 때 정상 흐름, 예외 흐름, 경계값을 구분합니다. 단순히 화면이 열리는지만 확인하면 중요한 결함을 놓칠 수 있습니다.

넷째, 결함 데이터를 누적하고 분석합니다. 어느 기능에서 버그가 많이 나오는지, 어떤 유형의 결함이 반복되는지 확인하면 다음 테스트 계획의 품질이 올라갑니다.

다섯째, 자동화할 테스트와 수동으로 확인할 테스트를 구분합니다. 반복적이고 결과가 명확한 테스트는 자동화에 적합하지만, 사용성이나 탐색적 테스트는 사람의 판단이 필요합니다.

실무에서 추천하는 적용 순서는 다음과 같습니다.

1. 핵심 사용자 시나리오 선정 2. 리스크 높은 기능 식별 3. 요구사항의 모호한 부분 질문 4. 정상·예외·경계 테스트 설계 5. 반복 회귀 테스트 자동화 6. 결함 이력 기반 테스트 보강 7. 배포 후 사용자 피드백 반영

이 과정을 반복하면 단순히 테스트를 수행하는 수준을 넘어, 제품 품질을 개선하는 테스팅 체계를 만들 수 있습니다.

바로 활용할 수 있는 체크리스트

아래 체크리스트는 테스트 계획, 테스트 케이스 리뷰, QA 시작 전 점검에 활용할 수 있습니다.

• [ ] 이 테스트는 어떤 리스크를 줄이기 위한 것인가?
• [ ] 테스트 통과를 “결함 없음”으로 과장해서 해석하고 있지 않은가?
• [ ] 모든 케이스를 테스트하려는 비현실적인 계획을 세우고 있지 않은가?
• [ ] 요구사항 단계에서 예외 상황을 충분히 질문했는가?
• [ ] 최근 변경된 기능과 결함이 많았던 영역을 우선 검증하는가?
• [ ] 오래된 테스트 케이스를 그대로 반복하고 있지 않은가?
• [ ] 현재 프로젝트의 도메인과 사용자 환경에 맞는 테스트 전략인가?
• [ ] 기능은 정상이어도 사용자 목적 달성에 문제가 없는지 확인했는가?
• [ ] 자동화 테스트의 검증 포인트가 실제 리스크와 연결되어 있는가?
• [ ] 테스트 결과를 다음 배포나 개선 활동에 반영하고 있는가?

이 체크리스트는 초보자뿐 아니라 테스트 리더가 팀의 테스트 성숙도를 점검할 때도 유용합니다.

주의할 점: 초보자가 자주 빠지는 함정

테스팅을 처음 배우는 사람은 몇 가지 오해에 빠지기 쉽습니다.

첫 번째는 테스트 케이스 수가 많을수록 좋은 테스트라고 생각하는 것입니다. 물론 테스트 케이스 수는 일정 부분 의미가 있지만, 더 중요한 것은 테스트가 실제 리스크를 다루고 있는지입니다. 중요하지 않은 케이스 100개보다 치명적인 결함을 찾을 수 있는 케이스 10개가 더 가치 있을 수 있습니다.

두 번째는 테스트자동화를 도입하면 QA 문제가 해결된다고 믿는 것입니다. 자동화는 반복 작업을 줄이고 회귀 테스트 효율을 높여주지만, 무엇을 검증할지 결정하는 것은 여전히 사람의 몫입니다.

세 번째는 개발 완료 후에만 테스트를 시작하는 습관입니다. 요구사항 오류, 설계 오류는 코드가 완성된 뒤 발견하면 수정 비용이 커집니다. 가능하면 기획 리뷰, 설계 리뷰, API 명세 검토부터 테스트 관점을 넣어야 합니다.

네 번째는 결함이 없으면 좋은 제품이라고 판단하는 것입니다. 사용자가 실제로 원하는 흐름과 맞지 않으면 오류가 없어도 실패한 제품이 될 수 있습니다.

다섯 번째는 프로젝트 정황을 무시하고 동일한 테스트 전략을 반복하는 것입니다. 사내 관리자 페이지와 금융 거래 시스템은 테스트 깊이와 우선순위가 달라야 합니다.

사례 분석: 쇼핑몰 결제 기능에 7가지 원리 적용하기

쇼핑몰 결제 기능은 테스팅의 7가지 원리를 설명하기 좋은 사례입니다. 결제는 사용자 피해와 매출 손실로 바로 이어질 수 있기 때문에 리스크가 높은 기능입니다.

먼저 원리 1에 따라, 테스트는 결제 기능이 완벽하다는 것을 증명하는 것이 아니라 결함을 발견하고 리스크를 낮추는 활동으로 접근해야 합니다. 정상 결제 한 번 성공했다고 충분하지 않습니다.

원리 2를 적용하면 모든 카드사, 모든 쿠폰, 모든 배송지, 모든 디바이스 조합을 테스트할 수 없다는 현실을 인정해야 합니다. 대신 사용량이 많은 결제 수단, 할인 조합, 장애 영향도가 큰 시나리오를 우선합니다.

원리 3에 따라 요구사항 단계에서 “결제 실패 시 주문 상태는 어떻게 되는가?”, “카드 승인 후 주문 생성에 실패하면 어떻게 복구하는가?” 같은 질문을 미리 해야 합니다.

원리 4의 결함 집중 관점에서는 쿠폰, 포인트, 카드 할인, 재고 차감, 주문 생성이 만나는 지점에 테스트를 집중해야 합니다. 이런 복합 영역에서 결함이 자주 발생합니다.

원리 5에 따라 매번 같은 정상 결제 시나리오만 반복하면 안 됩니다. 승인 지연, 중복 클릭, 네트워크 끊김, 결제 취소, 부분 취소 등 새로운 케이스를 지속적으로 추가해야 합니다.

원리 6에 따라 결제 기능은 일반 게시판 기능보다 훨씬 엄격한 테스트가 필요합니다. 금전 거래와 연결되기 때문에 정확성, 복구 가능성, 로그 추적성이 중요합니다.

마지막으로 원리 7을 적용하면 결제가 기술적으로 성공하더라도 사용자가 할인 적용 여부를 이해하지 못하거나 결제 완료 화면에서 주문 정보를 확인하기 어렵다면 개선이 필요합니다.

이처럼 7가지 원리는 이론이 아니라 실제 기능의 테스트 전략을 세우는 기준이 됩니다.

자주 묻는 질문

Q1. 테스팅의 7가지 원리는 초보자도 꼭 외워야 하나요?

단순 암기보다 중요한 것은 각 원리가 어떤 의사결정에 쓰이는지 이해하는 것입니다. 예를 들어 “완벽한 테스팅은 불가능하다”는 원리는 테스트 범위를 줄이라는 뜻이 아니라, 리스크 기반으로 우선순위를 정하라는 의미입니다. 실무에서는 원리를 외우는 것보다 테스트 계획을 세울 때 자연스럽게 적용하는 능력이 더 중요합니다.

Q2. 테스트자동화를 많이 하면 완벽한 테스팅에 가까워질 수 있나요?

테스트자동화는 반복 테스트를 빠르고 안정적으로 수행하게 해주지만 완벽한 테스팅을 가능하게 하지는 않습니다. 자동화할 수 없는 사용성 평가, 탐색적 테스트, 비즈니스 관점 검토도 필요합니다. 또한 자동화 스크립트가 오래되면 살충제 패러독스처럼 새로운 결함을 잘 찾지 못할 수 있으므로 정기적인 개선이 필요합니다.

Q3. 개발 초기에 테스팅을 시작한다는 것은 구체적으로 무엇을 의미하나요?

코드를 실행하기 전부터 테스트 관점으로 요구사항과 설계를 검토하는 것을 의미합니다. 예를 들어 기획서에서 예외 상황을 질문하고, 화면 설계서에서 누락된 상태값을 찾고, API 명세에서 오류 응답을 확인하는 활동이 포함됩니다. 이렇게 하면 개발 후반에 큰 구조 변경이 필요한 결함을 줄일 수 있습니다.

Q4. 결함 집중 원리는 어떻게 확인할 수 있나요?

버그 관리 도구나 이슈 기록을 분석하면 확인할 수 있습니다. 특정 기능에서 결함이 반복적으로 발생하거나, 특정 변경 이후 장애가 자주 발생한다면 결함 집중 영역일 가능성이 높습니다. 이런 영역은 다음 테스트 사이클에서 우선순위를 높이고, 회귀 테스트나 자동화 대상으로 검토하는 것이 좋습니다.

Q5. 오류-부재의 궤변은 QA에게 어떤 의미가 있나요?

QA가 단순히 “명세서대로 동작한다”만 확인해서는 부족하다는 의미입니다. 사용자가 실제 목적을 달성할 수 있는지, 흐름이 자연스러운지, 오류 메시지가 충분한지까지 살펴야 합니다. 특히 서비스 품질이 중요한 제품에서는 기능 정확성과 사용자 경험을 함께 검증해야 합니다.

앞으로 테스팅에서 중요해질 흐름

최근 소프트웨어 개발은 빠른 배포와 지속적 개선을 중심으로 움직이고 있습니다. 이 흐름에서 테스팅은 마지막 검문소가 아니라 개발 전 과정에 녹아드는 활동으로 바뀌고 있습니다.

특히 다음 흐름이 중요해지고 있습니다.

• CI/CD 파이프라인 안에서 자동화 테스트 실행
• 요구사항 단계부터 QA가 참여하는 시프트 레프트 테스트
• 운영 데이터와 사용자 피드백을 반영한 테스트 개선
• 결함 이력 기반의 리스크 중심 테스트
• API 테스트와 단위 테스트의 중요성 증가
• 단순 기능 검증을 넘어 사용성, 보안, 성능까지 포함하는 품질 관점 확대

이런 변화 속에서도 테스팅의 일반적인 원리 7가지는 여전히 유효합니다. 도구와 방법론은 바뀌어도, 결함을 바라보는 관점과 리스크를 줄이는 사고방식은 변하지 않기 때문입니다.

마무리 표

항목	정리
핵심 주제	SW 테스팅의 일반적인 원리 7가지와 실전 적용 방법
가장 중요한 관점	테스팅은 무결함 증명이 아니라 결함 발견과 리스크 감소 활동
초보자가 기억할 점	완벽한 테스팅은 불가능하므로 우선순위와 정황 판단이 중요
실무 적용 포인트	요구사항 단계부터 테스트 관점으로 질문하고, 결함 집중 영역을 우선 검증
테스트자동화 활용법	반복 회귀 테스트에는 효과적이지만 주기적인 케이스 개선이 필요
주의할 점	테스트 통과를 제품 성공으로 착각하지 말고 사용자 가치까지 확인
참고 기준	ISTQB에서 제시하는 테스팅의 일반적인 원리