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팀 |
검증 대상 | 코드, 문서, 설계 명세, 기술 표준 준수 여부 | 사용자 요구사항, 비즈니스 목표 달성 여부 |
주요 활동 | - 코드 리뷰 - 정적 분석 - 단위 테스트 - 통합 테스트 - 기술 명세 검토 | - 시스템 테스트 - 인수 테스트 - 베타 테스트 - 사용성 테스트 - 성능 테스트 |
테스트 방식 | - 화이트박스 테스팅 - 정적 테스팅 - 구조 기반 테스팅 | - 블랙박스 테스팅 - 동적 테스팅 - 행위 기반 테스팅 |
평가 기준 | - 코딩 표준 준수 - 기술 명세 충족 - 설계 요구사항 만족 | - 사용자 요구사항 충족 - 비즈니스 목표 달성 - 실제 환경에서의 적합성 |
주요 산출물 | - 코드 리뷰 보고서 - 테스트 결과 문서 - 정적 분석 보고서 - 기술 검토 문서 | - 사용자 인수 테스트 보고서 - 시스템 테스트 결과 - 성능 테스트 보고서 - 베타 테스트 피드백 |
오류 발견 시점 | 개발 초기 단계에서 발견 가능 | 개발 후반부나 실제 사용 단계에서 발견 |
비용 영향 | 초기에 문제 발견으로 수정 비용 최소화 | 후반부 발견으로 수정 비용이 상대적으로 높음 |
적용 범위 | 개별 컴포넌트나 모듈 수준의 검증 | 전체 시스템 수준의 검증 |
자동화 가능성 | 높은 자동화 가능성 (단위 테스트, 정적 분석 등) | 부분적 자동화 가능 (일부 시스템 테스트) |
품질 관점 | 내부 품질 (기술적 완성도) 중심 | 외부 품질 (사용자 만족도) 중심 |
리스크 관리 | 기술적 리스크 감소에 중점 | 비즈니스 리스크 감소에 중점 |
참고 및 출처#
성능 프로파일링 (Performance Profiling) 성능 프로파일링(Performance Profiling)은 소프트웨어의 실행 동작을 분석하여 성능을 측정하고 개선하는 기술이다.
성능 프로파일링은 소프트웨어 개발 과정에서 중요한 품질 관리 활동으로, 초기 단계부터 지속적으로 수행하여 효율적이고 최적화된 소프트웨어를 개발하는 데 도움을 준다.
정의와 목적 성능 프로파일링은 소프트웨어의 실행 시 동작과 리소스 사용을 분석하는 과정이다.
주요 목적은 다음과 같다:
코드의 병목 지점 식별 리소스 사용량 분석 (CPU 시간, 메모리 사용 등) 실행 시간이 긴 함수나 코드 섹션 파악 성능 최적화를 위한 개선 지점 도출 프로파일링 단계 계획: 분석 대상과 목표 설정 데이터 수집: 실행 중 성능 데이터 수집 분석: 수집된 데이터 분석 및 병목 지점 식별 최적화: 분석 결과를 바탕으로 코드 개선 검증: 개선 효과 확인 주요 프로파일링 유형 CPU 프로파일링: 함수별 CPU 사용 시간 측정 메모리 프로파일링: 메모리 할당 및 해제 패턴 분석 I/O 프로파일링: 디스크, 네트워크 등 I/O 작업 분석 장점 코드 품질 향상 소프트웨어 효율성 증대 리소스 할당 최적화 사용자 경험 개선 확장성 향상 도구 다양한 성능 프로파일링 도구가 있으며, 대표적인 것들은 다음과 같다:
...
워크스루(Walkthrough) 워크스루는 마치 박물관 가이드가 관람객들을 안내하듯이, 코드 작성자가 리뷰어들을 코드를 통해 “안내"하는 과정이다.
이 과정에서 코드의 의도, 구현 방식, 그리고 잠재적인 문제점들을 함께 발견하고 논의할 수 있다.
워크스루 세션의 실제 예시:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 // 워크스루 세션 중 코드 설명 예시 public class OrderProcessor { // 발표자: "주문 처리 시스템의 핵심 클래스입니다. // 주문의 유효성 검사부터 결제, 배송 처리까지 담당합니다." private final PaymentService paymentService; private final InventoryService inventoryService; private final ShippingService shippingService; public OrderResult processOrder(Order order) { // 발표자: "먼저 주문의 유효성을 검사합니다. // 여기서 중요한 것은 재고 확인입니다." if (!validateOrder(order)) { throw new InvalidOrderException("Invalid order"); } // 발표자: "재고가 확인되면 결제를 진행합니다. // 결제는 트랜잭션으로 처리됩니다." PaymentResult payment = paymentService.processPayment(order); // 리뷰어 질문: "결제 실패 시 재고는 어떻게 처리되나요?" // 발표자: "좋은 지적입니다. 결제 실패 시 재고를 원복하는 // 로직을 추가해야 할 것 같네요." if (payment.isSuccessful()) { // 발표자: "결제가 성공하면 배송 처리를 시작합니다." return createShippingOrder(order, payment); } return OrderResult.failure("Payment failed"); } } 워크스루의 주요 특징과 장점 상호작용적 학습
참가자들은 실시간으로 질문하고 토론할 수 있다:
...
코드 리뷰 (Code Review) 코드 리뷰는 개발자가 작성한 코드를 다른 개발자들이 검토하고 피드백을 제공하는 과정이다.
이는 마치 작가들이 서로의 글을 읽고 조언을 주고받는 것과 유사하다.
주된 목적은 코드의 품질을 향상시키고 팀 내의 지식 공유를 촉진하는 것이다.
코드 리뷰의 실제 적용 예시:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 // 리뷰가 필요한 코드 예시 public class UserService { public void createUser(String username, String password) { // 데이터베이스에 직접 저장 database.execute( "INSERT INTO users (username, password) VALUES ('" + username + "', '" + password + "')" ); } } // 리뷰어의 피드백 후 개선된 코드 public class UserService { /** * 새로운 사용자를 생성하고 저장합니다. * @param username 사용자 이름 * @param password 비밀번호 * @throws ValidationException 유효하지 않은 입력값 */ public void createUser(String username, String password) { // 입력값 검증 validateInput(username, password); // 비밀번호 해싱 String hashedPassword = passwordHasher.hash(password); // 준비된 구문을 사용하여 SQL 인젝션 방지 userRepository.save(new User(username, hashedPassword)); } } 주요 특징 품질 보증:
코드 리뷰는 버그를 찾아내고, 코드 품질을 향상시키며, 보안 취약점을 발견하는 데 도움을 준다.
여러 눈이 검토하므로 한 사람이 놓칠 수 있는 문제점들을 더 쉽게 발견할 수 있다. 지식 공유:
팀 멤버들이 서로의 코드를 검토하면서 자연스럽게 지식을 공유하고 학습할 수 있다.
주니어 개발자는 시니어의 피드백을 통해 성장할 수 있고, 시니어 개발자도 새로운 관점을 얻을 수 있다. 일관성 유지:
팀의 코딩 표준과 모범 사례를 준수하는지 확인함으로써, 전체 코드베이스의 일관성을 유지할 수 있다. 코드 리뷰 프로세스의 주요 단계 리뷰 준비
개발자는 리뷰를 위해 코드를 준비할 때 다음 사항들을 고려한다:
...
인스펙션 (inspection) 인스펙션(Inspection)은 정적 테스팅의 한 형태로, 가장 공식적이고 체계적인 리뷰 방법이다.
인스펙션은 FTR(Formal Technical Review)라고도 불리며, 정형화된 절차와 체크리스트를 사용하여 소프트웨어 산출물의 결함을 찾아내는 방법이다.
이는 정적 테스트 방법 중 가장 많은 인원이 참여하고 가장 공식적인 프로세스를 따른다.
주요 목적 결함 발견: 코드나 문서의 오류를 조기에 식별한다. 품질 향상: 소프트웨어 산출물의 전반적인 품질을 개선한다. 프로세스 개선: 개발 프로세스의 문제점을 파악하고 개선한다. 인스펙션 대상 인스펙션은 다음과 같은 소프트웨어 산출물에 적용된다:
...
Peer Review Peer Review는 소프트웨어 개발 과정에서 중요한 품질 보증 활동으로, 동료 개발자들이 서로의 코드나 문서를 검토하여 오류를 찾고 개선점을 제시하는 과정이다.
코드 리뷰가 중요한 이유는 여러 가지가 있다.
버그나 보안 취약점을 조기에 발견할 수 있다. 코드의 일관성과 유지보수성을 높일 수 있다. 팀 전체의 기술력 향상에 도움이 된다. 한 명의 실수나 실수를 하기 쉬운 부분을 여러 사람이 검토함으로써, 더 높은 품질의 코드를 만들 수 있다. Peer Review의 목적 오류 가능성 발견 및 해결 소프트웨어 품질 향상 개발자 스킬 향상 팀 내 지식 및 경험 공유 Peer Review의 장점 개발 초기 단계에서 실수 발견 및 수정 가능 전체적인 코드 품질 향상 팀 내 상호 신뢰 및 동기 부여 증진 가독성 높은 코드 작성 촉진 개선된 설계 발견 기회 Peer Review 프로세스 Peer Review는 일반적으로 다음과 같은 단계로 진행된다:
...
정적 코드 분석 (Static Code analysis) 정적 코드 분석은 프로그램을 실행하지 않고 소스 코드를 분석하여 잠재적인 결함, 취약점, 코딩 표준 위반 등을 찾아내는 기술이다.
이는 마치 건축가가 건물을 짓기 전에 설계도를 검토하는 것과 유사하다.
코드의 품질과 안정성을 조기에 확보할 수 있다는 점에서 매우 중요한 기술이다.
특징 실행 없이 분석: 프로그램을 실행하지 않고 소스 코드만을 검사한다. 자동화: 대부분의 정적 분석 도구는 자동화되어 있어 빠른 분석이 가능하다. 조기 발견: 개발 초기 단계에서 문제점을 식별할 수 있다. 분석 기법 정적 코드 분석에는 다양한 기법이 사용된다:
...
포멀 메소드 모델 (Formal Methods Model) 소프트웨어 개발에서 수학적 기법을 사용하여 시스템을 명세, 개발, 분석 및 검증하는 엄격한 접근 방식
소프트웨어의 정확성, 신뢰성 및 안전성을 보장하는 데 중점을 둔다.
특징 수학적 기반: 집합론, 논리학, 대수학 등의 수학적 기법을 사용 명확성과 정확성: 모호함을 제거하고 요구사항을 정확하게 명세 검증 가능성: 수학적 증명을 통해 시스템의 특성을 검증할 수 있다 추상화: 복잡한 시스템을 추상적으로 표현하여 이해와 분석을 용이하게 한다. 주요 기법 명세 언어: Z 표기법, B 메소드, Event-B 등의 형식적 명세 언어를 사용한다. 정리 증명: Coq, Isabelle 등의 도구를 사용하여 시스템 속성을 수학적으로 증명한다. 모델 검사: SPIN과 같은 도구를 사용하여 시스템의 모든 가능한 상태를 검사한다. 추상 해석: Frama-C와 같은 도구를 사용하여 프로그램의 런타임 오류 부재 등을 검증한다. 단점 높은 전문성 요구: 수학적 지식과 형식적 방법에 대한 이해가 필요하다. 시간과 비용: 초기 개발 단계에서 추가적인 노력과 비용이 필요할 수 있다 규모의 한계: 대규모 시스템에 적용하기 어려울 수 있다 적합한 프로젝트 유형 안전 중요 시스템, 보안 중요 시스템, 그리고 고신뢰성이 요구되는 소프트웨어 개발에 적합
...