(스크랩/번역/오역주의) 웹 사이트 테스팅에서 테스트 확인과 검증

출처 : https://www.lambdatest.com/blog/test-verification-vs-validation-in-website-testing/

Test Verification vs Validation in Website Testing

 

 

Verification 과 Validation 은 조직 또는 고객을 위해 웹 사이트를 개발할 때 전체 팀과 함께 테스터가 수행해야 하는 모든 필수 테스트 활동을 총체적으로 정의하는 중요한 테스트 활동입니다

테스터, 특히 업계 초년생에게 웹사이트 테스트에서 테스트 Validation과 Verification의 차이를 이해하는 것은 다소 복잡해 보일 수 있습니다.

왜냐하면 둘 다 웹사이트가 올바른 방식으로 개발되고 있는지 확인하는 것을 수반하기 때문입니다.

이것이 제가 프로젝트를 수행하는 팀들 사이에서 많은 애매모호함을 관찰한 이유이기도 합니다.

이 글은 웹 사이트 테스트에서 테스트 검증과 검증의 차이를 명확히 하기 위한 저의 시도입니다.

이제 다음 기사에서 검증 및 검증 테스트란 무엇인지 자세히 알아보겠습니다.

크로스 브라우저 테스트 시나리오를 사용하여 차이점을 설명하겠습니다.

시작하기 전에 테스트 검증과 검증 사이의 주요 차이점을 강조하고자 합니다.

Verification 테스트에는 팀이 올바른 접근 방식을 따르고 있는지, 설계, SRS 문서 등과 관련될 수 있는지 확인하는 작업이 포함되며, Validation 테스트에는 완성된 제품이 고객의 모든 요구를 충족하는지 여부를 확인하는 작업이 포함됩니다. 필요한 모든 브라우저와 장치를 지원하는지 여부처럼요.

Verification 테스트란?

웹 사이트나 애플리케이션 개발을 시작하기 전에, 이해관계자나 고객은 원하는 애플리케이션의 사양으로 구성된 상세 문서를 보냅니다. 그러나 우리는 종종 문서 검토를 무시하고 개발 중에 중요한 기능을 놓치는 경향이 있습니다. 여기에는 웹 사이트가 특정 브라우저 또는 장치를 지원해야 하는 것과 같은 사양이 포함될 수 있습니다.

검증 테스트는 개발 단계에서 체결된 작업 산출물이 고객이 명시한 요건을 충족하는지 여부를 파악하는 과정입니다. 한마디로 일이 제대로 진행되고 있는지 점검하는 것이죠.

검증 테스트를 시작하는 데 필요한 단계는 다음 문서를 보면 알 수 있습니다.

테스트 검증의 중요성
웹 사이트 간 호환성을 테스트할 때 검증 테스트는 프로세스를 수행하기 위해 필수적입니다.

• 단일 페이지 웹 응용 프로그램을 구축한다고 가정합니다.
• 검증 테스트는 웹 페이지가 모든 구성 요소를 갖추고 있는지 또는 SRS에 언급된 모든 브라우저를 지원하는지 확인하는 것입니다.
• 검증 테스트 중에 웹 응용 프로그램에서 이상이 발견되면 다음 테스트 단계에서 심각한 버그가 발생합니다. 따라서 이후 단계에서 버그 수가 감소하는지 확인하기 위해 테스트 검증을 수행합니다.
• 테스트 검증은 "웹 사이트를 올바르게 개발하고 있습니까?"라는 매우 기본적인 질문에 대한 유일한 대답입니다.
• 개발 수명 주기의 각 단계에서 검증 테스트는 웹 애플리케이션의 완전성, 정확성 및 일관성을 입증합니다.
• 초기에 제품을 검증하면 더 잘 이해할 수 있습니다. 검증 테스트뿐만 아니라 개발 중 버그 발생 가능성까지 줄여줍니다.
• 실패 가능성을 줄이고 고객의 요구에 따라 제품을 만드는 데 도움이 됩니다.

테스트 검증이란?

웹 애플리케이션 테스트를 하는 동안 주된 목적은 품질을 확인하는 것입니다. 새로운 버그가 발견될 때마다, 개발자들은 버그를 고칩니다. 이후 버그가 지속되는지 확인하기 위해 다시 한번 테스트를 실행합니다. 테스트 검증의 목적은 웹 사이트가 의도된 모든 기능을 수행하는지, 최종 사용자 또는 이해 관계자의 요구를 충족하는지 여부를 확인하는 것이죠.

검증 테스트는 개발 후뿐 아니라 검증 테스트가 완료된 후 수행됩니다. 유닛 테스트, 시스템 테스트, 인수 및 통합 테스트 등 널리 사용되는 필수 테스트 절차는 모두 검증 테스트 범주에 속합니다. 다음 다이어그램을 참조하여 작동 방식을 이해할 수 있습니다.

테스트 검증의 중요성

제품은 개발된 애플리케이션이 아닌 펜과 종이만 포함되기 때문에 검증 테스트를 통과할 수 있습니다. 단, 검증 테스트를 통과한 일부 포인트는 실제 제품에서 구현 시 실패할 수 있습니다. 검증 테스트는 다음과 같은 이유로 중요합니다.

• 검증 테스트 시 누락된 결함은 검증 테스트 시 버그로 잡힐 수 있습니다. 예를 들어, 여러 브라우저에서 보조 CSS 기능을 지원합니다. 이는 유효성 검사를 수행한 후에만 테스트할 수 있습니다.
• 유효성 검사는 하중 시험, 수용 시험, 유닛 시험 등과 같은 여러 단계로 이루어집니다. 따라서 웹 애플리케이션은 모든 필수 테스트 단계를 거칩니다.
• 유효성 검사는 개발 후 완제품이 고객의 모든 요구사항을 충족하는지 확인합니다.
  웹 사이트가 특정 운영 체제의 특정 브라우저에서 완벽하게 실행된다고 가정해 보겠습니다. 그러나 검증 테스트 과정에서 개념이 잘못 이해되었습니다. 기능이 구현되고 검증 테스트가 수행되면 검사자는 실제 결과와 예상 결과의 기능적 차이를 이해할 수 있습니다.

둘의 차이점을 깊이 파헤쳐 보면 이제 우리는 두 가지 용어, 즉 테스트 검증과 테스트 검증이 무엇을 의미하는지 잘 이해했습니다!

이제 둘 사이의 차이점을 더 깊이 파고들어야 봅시다.

테스트 Verification vs Validation – 목표는 무엇인가?

 

검증과 검증을 비교할 때 핵심 중 하나가 목적입니다. 검증 테스트의 목적은 개발이 시작되기 전에 계획된 웹 애플리케이션이 고객의 사양을 충족하는지 확인하는 것입니다. 유효성 검사는 개발이 완료된 후 완제품이 요건을 충족하는지 여부를 확인하는 것을 목적으로 합니다.
다음은 브라우저 간 테스트의 예입니다. 브라우저 간 호환 웹 응용프로그램을 개발하려고 합니다. 클라이언트는 4-5개의 다른 운영 체제(브라우저)에서 올바르게 실행되기를 원합니다. 검증 테스트를 통해 사이트가 모든 조합에서 올바르게 실행되는 방식으로 개발되었는지 확인합니다. 검증 테스트는 개발된 사이트가 실제로 모든 조합에서 제대로 실행되는지 확인하는 것을 목적으로 합니다.

Test Verification vs Validation – 무엇이 관련되는가?

Verification은 대부분 펜과 종이 작업이다. 여기에는 SRS, 사이트 설계 워크플로우, 프로그램 및 문서의 평가가 포함된다. 다만 다른 팀 출신이 다수 포함돼 과정이 꽤 깁니다.

반면 Validation 은 완전히 동적이고 개발 완료 후 수동 테스트와 자동 테스트 모두에서 제품의 품질을 확인합니다.

Test Verification vs Validation – 방법의 차이

Verification 은 정적 프로세스이기 때문에 코드 실행을 수반하지 않습니다. 그것은 대부분 사양, 페이지 워크플로우, 설계 및 테스트 사례에 대한 평가를 포함합니다. 때로는 코드 검토도 수반된다. 분석이 대부분이기 때문에 수동으로만 할 수 있습니다. 검증 테스트에는 자동화 범위가 없습니다.

그러나 Validation은 유닛 테스트와 함께 코드의 실행을 포함하며 최종 사용자의 요구 사항을 충족하는 데 코드가 완벽하게 작동하는지 확인하기 위한 테스트 사례의 실행을 포함합니다.

유닛, 기능 또는 회귀 테스트와 같은 일반적인 테스트 단계는 대부분 자동화된 스크립트를 사용하여 수행할 수 있으므로 검증 테스트에서 자동화를 위한 범위가 매우 넓습니다.

Test Verification vs Validation – 누가 수행하는가?

여러 팀에서 분석을 수행하므로 검증 테스트를 수행합니다.

• 개발팀뿐만 아니라 클라이언트도 비즈니스 요구사항을 검토합니다.
• 디자인 검토는 개발팀에서 합니다.
• 코드 검토는 주로 개발자가 수행합니다.
• QA 팀은 테스트 계획을 검토합니다.
• 테스트 계획은 비즈니스 분석가뿐만 아니라 QA 관리자에 의해 다시 외부에서 검토됩니다.
• QA 팀은 테스트 문서의 동료 검토를 수행합니다.
• 마지막으로, 개발 팀과 함께 비즈니스 분석가가 테스트 문서를 검토합니다.

검증 테스트는 전적으로 QA 팀에 의해 수행되며, 여기에는 조직의 수동 및 자동화 테스터와 고객 측의 자동화 테스터가 모두 포함됩니다.

Test Verification vs Validation – 프로세스는 언제 실행되는가?

그 과정을 자세히 살펴보도록 하겠습니다.

verification 테스트

• 팀은 요구 사항이 올바르게 수집되었는지 확인합니다.
• 작업이 완료되면 다음 단계인 설계 검토가 시작됩니다.
• 개발 팀은 설계를 검토하고 제안된 모든 기능 요구사항이 실제로 구현될 수 있는지 확인합니다.
• 코딩이 시작되고 구문 오류가 없는지 철저히 검토한다. 이것은 일상적인 활동이며 개발자가 수행할 수 있습니다.
• 설계자뿐만 아니라 개발자가 지정된 모범 사례와 요구사항을 충족하는지 확인하기 위해 공식적인 코드 검토를 수행합니다.
• 이제 QA팀으로 업무가 옮겨집니다. 그들은 테스트 계획서를 만들고, 정확성과 완전성을 확인하기 위해 내부적으로 검토한다.
• QA 책임자와 프로젝트 매니저, BA가 테스트 계획이 다른 프로젝트 활동과 일치하는지 검토합니다.
• 테스트 문서가 종료된 후, 팀 구성원은 문서에 실수가 없는지 확인하기 위해 서로의 활동을 내부적으로 검토한다.
• 모든 작업이 완료되면 테스트 문서는 개발 팀의 최종 검토를 거쳐 모든 팀원들에게 공유되고 다음 단계(즉, 검증 테스트)에 대비됩니다.

Validation 테스트

• 유닛 테스트 – 코딩이 완료되면 개발자 및 테스터가 수행합니다. 유닛 테스트 자체에서 흔히 발견되는 결함이 많습니다.
• 통합 테스트 – 모든 개별 코드 조각 또는 유닛이 결합되고 전체적으로 테스트되는 단계입니다. 코드가 필수 기준을 준수하는지 여부를 평가합니다.
• 시스템 테스트 – 이 테스트 단계는 통합이 완료되면 전체 시스템에서 수행됩니다. 기능 테스트, 부하 테스트, 회귀 테스트, 기타 형태의 테스트와 같은 여러 하위 범주가 있어 응용 프로그램이 활성화되면 버그가 발생하지 않도록 보장한다. 브라우저 호환성 테스트 또는 브라우저 간 테스트는 시스템 테스트의 필수적인 부분입니다. 웹 사이트가 클라이언트에 의해 지정된 모든 장치-운영 체제-브라우저 조합에서 완벽하게 실행되도록 보장합니다.
• 사용자 수용 테스트 – 검증 테스트의 마지막 단계입니다. 여기서 실제 사용자는 응용 프로그램을 테스트하여 사용자가 의도한 모든 실제 시나리오를 응용 프로그램에서 원활하게 처리할 수 있는지 확인합니다. 이 활동은 조직 또는 고객에 의해 수행됩니다.

Test Verification vs Validation – 무엇이 대상인가?

Verification 테스트는 일반적으로 웹 사이트 아키텍처, 데이터베이스 설계, 사양, 제품 설계 등을 대상으로 합니다.

Validation 테스트는 웹사이트의 각 구성 요소, 모듈, 보안, 통합 구성 요소뿐만 아니라 골라이브가 준비되면 최종 웹 사이트를 대상으로 합니다.

Test Verification vs Validation – 프로세스 비용

Verification 테스팅은 내부 팀원들과 수작업 인건비, 분석만 수반되기 때문에 비용이 많이 들지 않습니다. 제대로 수행되면 검증 테스트 중에 오류를 탐지하는 비용이 검증 테스트 중에 동일한 작업을 수행하는 것보다 훨씬 적기 때문에 전체 프로젝트 비용도 절감됩니다.

Validation 테스팅은 수동 작업, 자동화 도구, 테스트 라이센스 비용 및 도구 검토가 수반되기 때문에 비용이 많이 들고 브라우저 간 호환 웹사이트의 경우 테스트를 수행해야 하는 여러 장치와 운영 체제를 구입해야 하므로 비용이 증가합니다. 다만 람다와 같은 클라우드 기반 테스트 플랫폼을 사용할 경우 기기 및 OS 비용을 크게 절감할 수 있다.테스트. 여기서 수백 개의 장치-브라우저-OS 조합에서 동시에 애플리케이션을 원활하게 테스트할 수 있습니다.

  

어떻게 Test Verification & Validation 이 SDLC과 균형을 맞추는가?

테스트 Verification과 Validation은 모두 필수 활동이며 다른 활동 없이 하나만 완료할 수는 없습니다.웹 사이트가 verification 테스트를 통과하지만 Validation 테스트를 수행할 때 실패하는 것은 완전히 가능한 시나리오입니다. 때로는 요구 사항 자체가 사용자의 요구 사항과 일치하지 않아 테스트 verification 이 순조롭게 통과될 수 있지만 테스트 Validation 단계에서 개발이 중단되는 시나리오로 이어질 수 있습니다.

예를 들어, 고객은 자신의 크로스 브라우저 호환 웹사이트의 특정 이미지나 버튼에 대한 호버링 효과와 같은 특정 기능을 요청할 수 있다. 이 요구 사항은 verification 테스트를 통과할 수 있지만 CSS3의 특정 호버 효과가 Internet Explorer 11 이하에서 지원되지 않기 때문에 validation 테스트는 실패합니다.

몇 가지 예를 확인해 보겠습니다.
당신의 고객이 당신의 페이지에 CTA를 추가하기를 원한다고 가정해보자. verification 과 validation 테스트 모두 다음 순서에 따라 수행됩니다.

Verification testing

• 팀은 고객이 제안한 기능이 가능한지 분석하고 확인합니다.
• 테스트 사례는 여러 브라우저, 특히 클라이언트가 제안한 브라우저에서 기능을 테스트하기 위해 작성되었습니다.
• 요구 사항을 문서화하는 과정에서 색상 코드 오류가 발견되면 어떻게 해야 하나요? 우리는 버튼이 이런 식으로 보이길 원하지 않습니다.

이럴 경우 서류에 필요한 수정이 이루어지고 다시 검토를 위해 보내집니다.

• 최종 검토를 위해 해당 팀원에게 문서를 보냅니다.
• 그것이 완료되면, 개발팀은 코딩을 시작합니다.

Validation testing

개발이 완료되면 검증 테스트가 다음과 같은 순서로 시작됩니다.

• 유닛 테스트 – 개발자가 시스템에서 상자 그림자가 제대로 작동하는지 확인합니다.

• 통합 테스트 – 검사자는 페이지의 다른 구성요소와 함께 사용할 때 박스 쉐도우가 제대로 작동하는지 확인합니다.

• 시스템 테스트 – 테스터는 전체 페이지 또는 사이트와 통합될 때 상자 그림자가 완벽하게 작동하는지 확인합니다. 여기에는 버튼과 그림자가 필요한 모든 브라우저에 완벽하게 표시되는지 여부를 확인하는 수동 또는 자동 교차 브라우저 테스트가 적용됩니다.

• 사용자 수용 테스트 – 마지막으로 UAT에서는 실제 사용자 또는 최종 사용자를 대표하는 테스터가 자신의 관점에서 기능을 테스트하고 이상이 발견되면 보고합니다.

결론
위의 차이점을 바탕으로 테스트 검증 시 제품에 관여할 필요가 없다고 말씀드릴 수 있습니다. 그러나 테스트 검증 중에는 필수 사항입니다. 둘 다 오류를 알아내는 필터가 다르고 둘 다 나름대로 버그를 확인합니다. 따라서 교차 브라우저 호환 웹 사이트를 개발할 때 검증과 검증 테스트는 모두 필수 활동이며 웹 사이트가 활성화되기 전에 실행되어야 합니다.