exact difference between verification
검증 vs 검증 : 예제를 통한 차이점 탐색
이것의 기본으로 돌아 가기 여러분! 차이점에 대한 고전적인 모습 확인 및 검증 .
소프트웨어 테스트 세계에서 이러한 용어에 대해 많은 혼란과 논쟁이 있습니다.
이 기사에서는 소프트웨어 테스트의 관점에서 확인 및 검증이 무엇인지 살펴볼 것입니다. 이 기사가 끝날 때까지 두 용어의 차이점에 대해 알아볼 것입니다.
다음은 차이점을 이해해야하는 몇 가지 중요한 이유입니다.
- 이것은 기본적인 QA 개념이므로 QA를 인식하는 데 거의 기본 요소입니다.
- 이것은 일반적으로 묻는 소프트웨어 테스팅 인터뷰 질문 .
- 인증 강의 계획서에는 이것을 중심으로 많은 장이 있습니다.
- 마지막으로, 실제로 테스터가이 두 가지 테스트 유형을 모두 수행하므로 이에 대한 전문가가 될 수도 있습니다.
학습 내용 :
- 소프트웨어 테스트에서 검증 및 검증이란 무엇입니까?
- 확인이란 무엇입니까?
- 검증이란 무엇입니까?
- 검증 및 검증 예
- 개발 라이프 사이클의 여러 단계에서 V & V
- 검증과 검증의 차이점
- 다양한 표준
- 유효성 검사 및 확인을 언제 사용해야합니까?
- 결론
소프트웨어 테스트에서 검증 및 검증이란 무엇입니까?
테스트 맥락에서 ' 확인 및 검증 ”는 널리 사용되는 두 가지 용어입니다. 대부분의 경우 두 용어를 동일한 것으로 간주하지만 실제로이 용어는 상당히 다릅니다.
V & V (Verification & Validation) 작업에는 두 가지 측면이 있습니다.
- 요구 사항 확인 (생산자 품질 관점)
- 사용에 적합 (소비자의 품질 관점)
품질에 대한 제작자의 관점 간단히 말해서 개발자가 최종 제품에 대한 인식을 의미합니다.
소비자는 품질을 본다 최종 제품에 대한 사용자의 인식을 의미합니다.
V & V 작업을 수행 할 때 우리는 품질에 대한 이러한 두 가지 관점에 모두 집중해야합니다.
먼저 검증 및 검증의 정의부터 시작한 다음 예제를 통해 이러한 용어를 이해하도록하겠습니다.
노트 : 이러한 정의는 QAI의 CSTE CBOK에 언급 된대로입니다 (CSTE에 대해 자세히 알아 보려면이 링크를 확인하십시오).
확인이란 무엇입니까?
검증은 소프트웨어 개발 라이프 사이클의 중간 작업 제품을 평가하여 최종 제품을 만드는 데 올바른 경로에 있는지 확인하는 프로세스입니다.
즉, 검증은 소프트웨어의 중개자 제품을 평가하여 제품이 단계 시작시 부과 된 조건을 충족하는지 여부를 확인하는 프로세스라고 말할 수도 있습니다.
이제 질문은 다음과 같습니다. 중개자 또는 중개자 제품은 무엇입니까?
여기에는 요구 사항 사양, 디자인 문서, 데이터베이스 테이블 디자인, ER 다이어그램, 테스트 케이스, 같은 개발 단계에서 생성되는 문서가 포함될 수 있습니다. 추적 성 매트릭스 등
우리는 때때로 이러한 문서를 검토하는 것의 중요성을 무시하는 경향이 있지만, 개발주기의 후반 단계에서 발견되거나 수정되면 비용이 많이들 수있는 경우 검토 자체로 많은 숨겨진 이상을 발견 할 수 있음을 이해해야합니다.
검증은 시스템 (소프트웨어, 하드웨어, 문서 및 직원)이 검토 또는 실행 불가능한 방법에 의존하여 조직의 표준 및 프로세스를 준수하는지 확인합니다.
검증은 어디에서 수행됩니까?
다음은 검증이 수행되는 일부 영역 (이것이 전부는 아님을 강조해야 함) 중 일부입니다.
| 확인 상황 | 배우 | 정의 | 산출 |
|---|---|---|---|
| 테스트 문서 검토 (동료 검토) | QA 팀원 | 동료 검토는 팀 구성원이 문서 자체에 실수가 없는지 확인하기 위해 서로의 작업을 검토하는 곳입니다. | 외부 팀과 공유 할 준비가 된 테스트 문서. |
| 비즈니스 / 기능 요구 사항 검토 | 비즈니스 요구 사항을위한 개발 팀 / 클라이언트. | 이는 요구 사항이 수집 및 / 또는 올바르게 수집되었는지 확인하는 것뿐만 아니라 실행 가능한지 여부를 확인하는 데 필요한 단계입니다. | 다음 단계 인 설계에서 사용할 준비가 된 최종 요구 사항. |
| 디자인 리뷰 | 개발팀 | 설계 생성 후 Dev 팀은 제안 된 설계를 통해 기능 요구 사항을 충족 할 수 있는지 철저하게 검토합니다. | 설계를 IT 시스템에 구현할 준비가되었습니다. |
| 코드 연습 | 개인 개발자 | 작성된 코드는 구문 오류를 식별하기 위해 검토됩니다. 이것은 본질적으로 좀 더 캐주얼하며 개별 개발자가 직접 개발 한 코드에 대해 수행합니다. | 단위 테스트를위한 코드 준비. |
| 코드 검사 | 개발팀 | 이것은보다 공식적인 설정입니다. 주제 전문가와 개발자는 코드가 소프트웨어가 목표로하는 비즈니스 및 기능적 목표와 일치하는지 확인합니다. | 테스트를위한 코드 준비. |
| 테스트 계획 검토 (QA 팀 내부) | QA 팀 | 테스트 계획은 QA 팀에서 내부적으로 검토하여 정확하고 완전한지 확인합니다. | 외부 팀 (프로젝트 관리, 비즈니스 분석, 개발, 환경, 클라이언트 등)과 공유 할 준비가 된 테스트 계획 문서 |
| 테스트 계획 검토 (외부) | 프로젝트 관리자, 비즈니스 분석가 및 개발자. | QA 팀의 타임 라인 및 기타 고려 사항이 다른 팀 및 전체 프로젝트 자체와 일치하는지 확인하기위한 테스트 계획 문서의 공식 분석. | 테스트 활동의 기반이되는 서명 또는 승인 된 테스트 계획 문서. |
| 테스트 문서 최종 검토 | 비즈니스 분석가 및 개발 팀. | 테스트 케이스가 시스템의 모든 비즈니스 조건 및 기능 요소를 포함하는지 확인하기위한 테스트 문서 검토. | 실행할 준비가 된 테스트 문서. |
참조 테스트 문서 검토 테스터가 리뷰를 수행하는 방법에 대한 자세한 프로세스를 게시하는 기사입니다.
검증이란 무엇입니까?
검증은 소프트웨어가 비즈니스 요구 사항을 충족하는지 확인하기 위해 최종 제품을 평가하는 프로세스입니다. 간단히 말해서 우리가 일상 생활에서 수행하는 테스트 실행은 실제로 다음을 포함하는 유효성 검사 활동입니다. 연기 테스트 , 기능 테스트, 회귀 테스트, 시스템 테스트 등
유효성 검사는 제품 작업 및 테스트를 포함하는 모든 형태의 테스트입니다.
다음은 유효성 검사 기술입니다.
검증은 관찰 및 평가할 수있는 일련의 테스트를 통해 시스템 기능을 실행하여 시스템이 계획에 따라 작동하는지 물리적으로 확인합니다.
충분히 공평 하지요? 여기 내 두 센트가 있습니다.
수업에서이 V & V 개념을 다루려고 할 때 많은 혼란이 있습니다. 간단하고 사소한 예가 모든 혼란을 해결하는 것 같습니다. 다소 어리석지 만 실제로 작동합니다.
검증 및 검증 예
실제 사례 :레스토랑 / 식당에 가서 블루 베리 팬케이크를 주문한다고 상상해보십시오. 웨이터 / 웨이트리스가 주문을 가져 왔을 때 나왔던 음식이 주문한 음식인지 어떻게 알 수 있습니까?
첫 번째는 우리가 그것을보고 다음 사항에 주목하는 것입니다.
다른 전화를 감시하는 앱
- 음식이 일반적으로 보이는 팬케이크처럼 보입니까?
- 블루 베리가 보이나요?
- 냄새가 맞나요?
더 많을 수도 있지만 요점은 맞습니까?
다른 한편으로, 음식이 당신이 예상 한 것과 같은지에 대해 절대적으로 확신해야 할 때 : 당신은 그것을 먹어야 할 것입니다.
검증은 아직 식사를하지 않았지만 주제를 검토하여 몇 가지 사항을 확인하는 경우입니다. 유효성 검사는 실제로 제품을 섭취하여 옳은지 확인하는 것입니다.
이런 맥락에서 나는 스스로를 도울 수 없지만 CSTE CBOK 참고. 우리가이 개념을 집으로 가져 오는 데 도움이되는 멋진 진술이 있습니다.
검증은 '올바른 시스템을 구축 했습니까?'라는 질문에 답합니다. 유효성 검사에서는 '우리가 시스템을 올바르게 구축 했습니까?'라고 말합니다.
개발 라이프 사이클의 여러 단계에서 V & V
개발 라이프 사이클의 각 단계에서 검증 및 검증이 수행됩니다.
한 번 살펴 보겠습니다.
# 1) V & V 작업 - 계획
- 계약 확인.
- 개념 문서 평가.
- 위험 분석 수행.
# 2) V & V 작업 - 요구 사항 단계
- 소프트웨어 요구 사항 평가.
- 인터페이스 평가 / 분석.
- 시스템 테스트 계획 생성.
- 수락 테스트 계획 생성.
# 3) V & V 작업 - 디자인 단계
- 소프트웨어 설계 평가.
- 인터페이스 (UI) 평가 / 분석.
- 통합 테스트 계획 생성.
- 구성 요소 테스트 계획 생성.
- 테스트 디자인 생성.
# 4) V & V 작업 - 구현 단계
- 소스 코드 평가.
- 문서 평가.
- 테스트 케이스 생성.
- 테스트 절차 생성.
- 구성 요소 테스트 케이스 실행.
# 5) V & V 작업 - 테스트 단계
- 시스템 테스트 케이스 실행.
- 수락 테스트 케이스 실행.
- 추적 성 메트릭 업데이트.
- 위험도 분석
# 6) V & V 작업 - 설치 및 체크 아웃 단계
- 설치 및 구성 감사.
- 설치 후보 빌드의 최종 테스트입니다.
- 최종 테스트 보고서 생성.
# 7) V & V 작업 - 운영 단계
- 새로운 제약의 평가.
- 제안 된 변경 평가.
# 8) V & V 작업 - 유지 보수 단계
- 이상 징후 평가.
- 마이그레이션 평가.
- 재심 기능의 평가.
- 제안 된 변경 사항의 평가.
- 생산 문제 검증.
검증과 검증의 차이점
| 확인 | 확인 |
|---|---|
| 중간 제품을 평가하여 특정 단계의 특정 요구 사항을 충족하는지 확인합니다. | 최종 제품을 평가하여 비즈니스 요구 사항을 충족하는지 확인합니다. |
| 제품이 지정된 요구 사항 및 설계 사양에 따라 제작되었는지 확인합니다. | 소프트웨어가 사용하기에 적합하고 비즈니스 요구를 충족하는지 여부를 결정합니다. |
| “우리가 제품을 제대로 만들고 있습니까?”를 확인합니다. | '올바른 제품을 만들고 있습니까?'를 확인합니다. |
| 이것은 소프트웨어를 실행하지 않고 수행됩니다. | 소프트웨어 실행으로 완료됩니다. |
| 모든 정적 테스트 기술을 포함합니다. | 모든 동적 테스트 기술을 포함합니다. |
| 예를 들어 검토, 검사 및 연습이 있습니다. | 예에는 연기, 회귀, 기능, 시스템 및 UAT와 같은 모든 유형의 테스트가 포함됩니다. |
다양한 표준
ISO / IEC 12207 : 2008
| 검증 활동 | 검증 활동 |
|---|---|
| 요구 사항 확인에는 요구 사항 검토가 포함됩니다. | 테스트 결과를 분석하기 위해 테스트 요구 사항 문서, 테스트 케이스 및 기타 테스트 사양을 준비합니다. |
| 설계 검증에는 HLD 및 LDD를 포함한 모든 설계 문서의 검토가 포함됩니다. | 이러한 테스트 요구 사항, 테스트 사례 및 기타 사양이 요구 사항을 반영하고 사용하기에 적합한 지 평가합니다. |
| 코드 검증에는 코드 검토가 포함됩니다. | 경계 값, 스트레스 및 기능을 테스트합니다. |
| 문서 확인은 사용자 설명서 및 기타 관련 문서의 확인입니다. | 오류 메시지를 테스트하고 오류가 발생하면 응용 프로그램이 정상적으로 종료됩니다. 소프트웨어가 비즈니스 요구 사항을 충족하고 사용하기에 적합한 지 테스트합니다. |
CMMI :
확인 및 검증은 성숙도 레벨 3에서 서로 다른 두 KPA입니다.
| 검증 활동 | 검증 활동 |
|---|---|
| 피어 리뷰 수행. | 제품 및 해당 구성 요소가 환경에 적합한 지 확인합니다. |
| 선택한 산출물을 확인하십시오. | 검증 프로세스가 구현 될 때 모니터링 및 제어됩니다. |
| 계획 및 검토를위한 조직 수준의 정책을 수립하여 명확한 프로세스를 표준화합니다. | 교훈을 얻은 활동을 수행하고 개선 정보를 수집합니다. 명확한 프로세스를 제도화하십시오. |
IEEE 1012 :
이러한 테스트 활동의 목표는 다음과 같습니다.
- 오류의 조기 발견 및 수정을 용이하게합니다.
- 프로세스 및 제품 위험 내부의 관리 개입을 장려하고 향상시킵니다.
- 소프트웨어 라이프 사이클 프로세스에 대한 지원 조치를 제공하여 일정 및 예산 요구 사항의 준수를 강화합니다.
유효성 검사 및 확인을 언제 사용해야합니까?
이는 시스템 또는 응용 프로그램이 요구 사항 및 사양을 준수하고 의도 된 목적을 달성하는지 확인하기 위해 함께 사용해야하는 독립적 인 절차입니다. 둘 다 품질 관리 시스템의 중요한 구성 요소입니다.
제품이 검증을 통과했지만 검증 단계에서는 실패 할 수 있습니다. 그러나 문서화 된 요구 사항 및 사양을 충족했기 때문에 이러한 사양 자체로는 사용자의 요구 사항을 해결할 수 없었습니다. 따라서 전체적인 품질을 보장하기 위해 두 유형 모두에 대해 테스트를 수행하는 것이 중요합니다.
검증은 개발, 확장 또는 생산에서 내부 프로세스로 사용할 수 있습니다. 반면에 검증은 이해 관계자와의 적합성을 받아들이 기위한 외부 프로세스로 사용되어야합니다.
UAT 검증 또는 검증입니까?
UAT (User Acceptance Testing)는 유효성 검사로 간주되어야합니다. 시스템 또는 응용 프로그램의 실제 유효성 검사는 시스템이 '사용하기에 적합한 지'확인하는 실제 사용자가 수행합니다.
결론
V & V 프로세스는 주어진 활동의 제품이 요구 사항을 준수하고 사용에 적합한 지 여부를 결정합니다.
마지막으로 다음 사항에 유의해야합니다.
- 매우 간단한 용어로 (혼란을 피하기 위해) Verification은 검토 활동을 의미하거나 정적 테스트 기술 및 유효성 검사는 실제 테스트 실행 활동 또는 동적 테스트 기술을 의미한다는 것을 기억합니다.
- 확인은 제품 자체를 포함하거나 포함하지 않을 수 있습니다. 검증에는 확실히 제품이 필요합니다. 최종 시스템을 나타내는 문서에 대해 확인을 수행 할 수도 있습니다.
- 테스터가 검증 및 검증을 반드시 수행 할 필요는 없습니다. 이 기사에서 위에서 볼 수 있듯이 이들 중 일부는 개발자 및 다른 팀에서 수행합니다.
이 주제에 대한 SME (주제 전문가)가되기 위해 검증 및 검증에 대해 알아야 할 모든 것입니다.