Validation and Verification#
소프트웨어 테스팅에서 Validation과 Verification은 서로 다른 관점과 목적을 가지고 있다.
Verification은 “제품을 올바르게 만들고 있는가?“를 확인하는 과정이고, Validation은 “올바른 제품을 만들고 있는가?“를 확인하는 과정이다.
이러한 근본적인 차이는 테스트 방법과 접근 방식에 큰 영향을 미친다.
Verification#
Verification은 “우리가 제품을 올바르게 만들고 있는가?” 라는 질문에 답하는 프로세스로, 개발 과정 중에 제품이 명세된 요구사항과 설계 문서에 따라 정확하게 구현되고 있는지를 검증한다.
개발자와 테스터가 수행하며, 코드 레벨에서의 정확성과 기술적 완성도를 중요시한다.
예를 들어, 특정 함수가 입력값에 대해 정확한 출력값을 반환하는지, 데이터베이스 쿼리가 예상대로 작동하는지 등을 확인한다.
Validation#
Validation은 “우리가 올바른 제품을 만들고 있는가?” 라는 질문에 답하는 프로세스로, 개발된 제품이 실제 사용자의 요구사항과 기대를 충족시키는지 확인하는 과정이다.
사용자 관점에서의 테스트가 주를 이루며, 실제 운영 환경에서의 적합성과 사용성을 중요시한다.
예를 들어, 사용자가 웹사이트에서 원하는 정보를 쉽게 찾을 수 있는지, 모바일 앱의 인터페이스가 직관적인지 등을 확인한다.
프로세스와 방법론의 차이#
Verification은 주로 정적 테스팅 방법을 사용한다.
코드 리뷰, 문서 검토, 정적 분석 등이 여기에 해당한다.
Validation은 동적 테스팅 방법을 주로 사용하며, 실제 시스템을 실행하면서 테스트를 수행한다.
사용자 시나리오 테스트, 성능 테스트, 사용성 테스트 등이 이에 해당한다.
품질 보증에서의 역할#
두 테스트 방식은 상호 보완적인 관계에 있다.
Verification이 제품의 기술적 완성도를 보장한다면, Validation은 제품의 실용적 가치를 보장한다.
따라서 효과적인 품질 보증을 위해서는 두 가지 접근 방식을 모두 적절히 활용해야 한다.
Validation and Verification#
| 비교 기준 | Verification (검증) | Validation (확인) |
|---|
| 정의 | 제품을 올바르게 만들고 있는지 검증 (Building the product right) | 올바른 제품을 만들고 있는지 확인 (Building the right product) |
| 목적 | 개발 중인 제품이 명세와 표준을 준수하는지 확인 | 개발된 제품이 실제 사용자의 요구사항을 충족하는지 확인 |
| 수행 시점 | 개발 단계에서 지속적으로 수행 | 개발 후반부나 완료 단계에서 수행 |
| 수행 주체 | 개발팀, QA팀, 테스트 엔지니어 | 최종 사용자, 고객, QA팀 |
| 검증 대상 | 코드, 문서, 설계 명세, 기술 표준 준수 여부 | 사용자 요구사항, 비즈니스 목표 달성 여부 |
| 주요 활동 | - 코드 리뷰
- 정적 분석
- 단위 테스트
- 통합 테스트
- 기술 명세 검토 | - 시스템 테스트
- 인수 테스트
- 베타 테스트
- 사용성 테스트
- 성능 테스트 |
| 테스트 방식 | - 화이트박스 테스팅
- 정적 테스팅
- 구조 기반 테스팅 | - 블랙박스 테스팅
- 동적 테스팅
- 행위 기반 테스팅 |
| 평가 기준 | - 코딩 표준 준수
- 기술 명세 충족
- 설계 요구사항 만족 | - 사용자 요구사항 충족
- 비즈니스 목표 달성
- 실제 환경에서의 적합성 |
| 주요 산출물 | - 코드 리뷰 보고서
- 테스트 결과 문서
- 정적 분석 보고서
- 기술 검토 문서 | - 사용자 인수 테스트 보고서
- 시스템 테스트 결과
- 성능 테스트 보고서
- 베타 테스트 피드백 |
| 오류 발견 시점 | 개발 초기 단계에서 발견 가능 | 개발 후반부나 실제 사용 단계에서 발견 |
| 비용 영향 | 초기에 문제 발견으로 수정 비용 최소화 | 후반부 발견으로 수정 비용이 상대적으로 높음 |
| 적용 범위 | 개별 컴포넌트나 모듈 수준의 검증 | 전체 시스템 수준의 검증 |
| 자동화 가능성 | 높은 자동화 가능성 (단위 테스트, 정적 분석 등) | 부분적 자동화 가능 (일부 시스템 테스트) |
| 품질 관점 | 내부 품질 (기술적 완성도) 중심 | 외부 품질 (사용자 만족도) 중심 |
| 리스크 관리 | 기술적 리스크 감소에 중점 | 비즈니스 리스크 감소에 중점 |
참고 및 출처#
보안 취약점 스캔 (Security Vulnerability Scanning) 시스템의 모든 진입점과 약점을 체계적으로 검사하는 과정이다.
주로 자동화된 도구를 사용하여 알려진 취약점 패턴을 검사하고, 잠재적인 보안 위험을 식별합니다.
주요 목적 잠재적인 보안 취약점 식별 데이터 유출 및 사이버 공격 위험 감소 규정 준수 요구사항 충족 전반적인 보안 태세 강화 작동 방식 대상 식별: 스캔할 시스템, 네트워크, 애플리케이션을 정의 스캔 실행: 자동화된 도구를 사용하여 취약점 검색 데이터 수집 및 분석: 발견된 취약점에 대한 정보 수집 및 분석 보고서 생성: 식별된 취약점과 심각도 수준을 포함한 상세 보고서 작성 결과 평가 및 조치: 우선순위에 따라 취약점 해결 방안 수립 주요 스캔 유형 네트워크 취약점 스캔: 방화벽, 라우터 등 네트워크 인프라의 취약점 검사 웹 애플리케이션 취약점 스캔: SQL 인젝션, XSS 등 웹 관련 취약점 탐지 데이터베이스 취약점 스캔: 데이터베이스 시스템의 보안 취약점 평가 호스트 취약점 스캔: 개별 서버나 워크스테이션의 OS 수준 취약점 검사 장점 조기 취약점 발견으로 비용 절감 자동화를 통한 효율적인 보안 관리 규정 준수 입증 용이 지속적인 보안 상태 모니터링 가능 주의사항 거짓 양성(false positive) 결과 발생 가능성 모든 취약점을 발견할 수 없음 스캔 자체가 시스템에 부하를 줄 수 있음 참고 및 출처
성능 프로파일링 (Performance Profiling) 성능 프로파일링(Performance Profiling)은 소프트웨어의 실행 동작을 분석하여 성능을 측정하고 개선하는 기술이다.
성능 프로파일링은 소프트웨어 개발 과정에서 중요한 품질 관리 활동으로, 초기 단계부터 지속적으로 수행하여 효율적이고 최적화된 소프트웨어를 개발하는 데 도움을 준다.
정의와 목적 성능 프로파일링은 소프트웨어의 실행 시 동작과 리소스 사용을 분석하는 과정이다.
주요 목적은 다음과 같다:
코드의 병목 지점 식별 리소스 사용량 분석 (CPU 시간, 메모리 사용 등) 실행 시간이 긴 함수나 코드 섹션 파악 성능 최적화를 위한 개선 지점 도출 프로파일링 단계 계획: 분석 대상과 목표 설정 데이터 수집: 실행 중 성능 데이터 수집 분석: 수집된 데이터 분석 및 병목 지점 식별 최적화: 분석 결과를 바탕으로 코드 개선 검증: 개선 효과 확인 주요 프로파일링 유형 CPU 프로파일링: 함수별 CPU 사용 시간 측정 메모리 프로파일링: 메모리 할당 및 해제 패턴 분석 I/O 프로파일링: 디스크, 네트워크 등 I/O 작업 분석 장점 코드 품질 향상 소프트웨어 효율성 증대 리소스 할당 최적화 사용자 경험 개선 확장성 향상 도구 다양한 성능 프로파일링 도구가 있으며, 대표적인 것들은 다음과 같다:
...
정적 코드 분석 (Static Code analysis) 정적 코드 분석은 프로그램을 실행하지 않고 소스 코드를 분석하여 잠재적인 결함, 취약점, 코딩 표준 위반 등을 찾아내는 기술이다.
이는 마치 건축가가 건물을 짓기 전에 설계도를 검토하는 것과 유사하다.
코드의 품질과 안정성을 조기에 확보할 수 있다는 점에서 매우 중요한 기술이다.
특징 실행 없이 분석: 프로그램을 실행하지 않고 소스 코드만을 검사한다. 자동화: 대부분의 정적 분석 도구는 자동화되어 있어 빠른 분석이 가능하다. 조기 발견: 개발 초기 단계에서 문제점을 식별할 수 있다. 분석 기법 정적 코드 분석에는 다양한 기법이 사용된다:
...
포멀 메소드 모델 (Formal Methods Model) 소프트웨어 개발에서 수학적 기법을 사용하여 시스템을 명세, 개발, 분석 및 검증하는 엄격한 접근 방식
소프트웨어의 정확성, 신뢰성 및 안전성을 보장하는 데 중점을 둔다.
특징 수학적 기반: 집합론, 논리학, 대수학 등의 수학적 기법을 사용 명확성과 정확성: 모호함을 제거하고 요구사항을 정확하게 명세 검증 가능성: 수학적 증명을 통해 시스템의 특성을 검증할 수 있다 추상화: 복잡한 시스템을 추상적으로 표현하여 이해와 분석을 용이하게 한다. 주요 기법 명세 언어: Z 표기법, B 메소드, Event-B 등의 형식적 명세 언어를 사용한다. 정리 증명: Coq, Isabelle 등의 도구를 사용하여 시스템 속성을 수학적으로 증명한다. 모델 검사: SPIN과 같은 도구를 사용하여 시스템의 모든 가능한 상태를 검사한다. 추상 해석: Frama-C와 같은 도구를 사용하여 프로그램의 런타임 오류 부재 등을 검증한다. 단점 높은 전문성 요구: 수학적 지식과 형식적 방법에 대한 이해가 필요하다. 시간과 비용: 초기 개발 단계에서 추가적인 노력과 비용이 필요할 수 있다 규모의 한계: 대규모 시스템에 적용하기 어려울 수 있다 적합한 프로젝트 유형 안전 중요 시스템, 보안 중요 시스템, 그리고 고신뢰성이 요구되는 소프트웨어 개발에 적합
...
Peer Review Peer Review는 소프트웨어 개발 과정에서 중요한 품질 보증 활동으로, 동료 개발자들이 서로의 코드나 문서를 검토하여 오류를 찾고 개선점을 제시하는 과정이다.
코드 리뷰가 중요한 이유는 여러 가지가 있다.
버그나 보안 취약점을 조기에 발견할 수 있다. 코드의 일관성과 유지보수성을 높일 수 있다. 팀 전체의 기술력 향상에 도움이 된다. 한 명의 실수나 실수를 하기 쉬운 부분을 여러 사람이 검토함으로써, 더 높은 품질의 코드를 만들 수 있다. Peer Review의 목적 오류 가능성 발견 및 해결 소프트웨어 품질 향상 개발자 스킬 향상 팀 내 지식 및 경험 공유 Peer Review의 장점 개발 초기 단계에서 실수 발견 및 수정 가능 전체적인 코드 품질 향상 팀 내 상호 신뢰 및 동기 부여 증진 가독성 높은 코드 작성 촉진 개선된 설계 발견 기회 Peer Review 프로세스 Peer Review는 일반적으로 다음과 같은 단계로 진행된다:
...