답변.

검증과 유효성 검사는 제품이 기대와 요구 사항에 부합하는지를 정의하는 테스트의 두 가지 주요 개념입니다.

문제의 역사:

소프트웨어 엔지니어링에서 제품의 명세와 일치하는 검증(제품의 명세 준수)과 사용자의 기대와 일치하는 유효성 검사(사용자의 기대 준수)를 설명하기 위해 개념이 나뉘어졌습니다.

문제:

전문가들이 이러한 용어를 혼동하여 접근 방식을 잘못 적용합니다: 명세서에 따라 테스트만 하고 사용자 경험을 무시하거나, 반대로 "올바른/편리함" 논리에만 의존하여 형식적인 요구 사항을 잊어버립니다.

해결책:

검증 (우리가 제품을 올바르게 만들고 있는가?) — 제품이 모든 명세 요구 사항(명세서, 문서)에 부합하는지 확인합니다.
유효성 검사 (우리가 올바른 제품을 만들고 있는가?) — 제품이 사용자 문제를 해결하고 실제 기대에 부합하는지 확인합니다.
두 가지 접근 방식을 모두 사용합니다: 명세서에 따라 검증하고, "실제" 탐색 테스트, 사용자 시나리오, 수용 테스트를 통해 유효성 검사를 진행합니다.

주요 특징:

함정 질문.

"제품이 검증을 통과했지만 유효성 검사를 실패했다"는 의미는 무엇인가요?

제품은 명세서와 일치하지만, 불편하고 사용자의 문제를 해결하지 못하며 시장에서 필요하지 않습니다.

유효성 검사를 검증보다 먼저 시작할 수 있나요?

아니요, 기본 요구 사항이 먼저 확인되어야 하며, 그렇지 않으면 불완전한 기능이 사용자 경험을 평가할 수 없게 됩니다.

사용 편의성 부족은 검증 시 버그로 간주되나요?

아니요, 이는 사용자 시나리오의 유효성 검사 단계에서만 드러나는 UX문제입니다.

문서 요구 사항만을 준수하는지 테스트했습니다. 출시 후 사용자가 주문 과정의 논리를 이해하지 못하는 것이 밝혀졌습니다. 명세서에 명시된 테스트 케이스와는 형식적으로 일치했지만 말이죠.

장점:

단점:

탐색 테스트를 사용하고 실제 사용자와 함께 UX 테스트를 조직했습니다. 불편함을 발견하고 주문 프로세스를 개선했습니다. 결과적으로 긍정적인 피드백과 높은 전환율을 얻었습니다.

장점:

단점: