[ISO 26262 9강] 검증 수행과 Verification Evidence 품질

 

Title: ISO 26262 중급 강좌 9강 – 검증 수행과 Verification Evidence 품질: 테스트 케이스 관리, Defect Tracking, Traceability까지

Description: ISO 26262 검증 수행 실무를 중심으로 테스트 케이스 관리, Defect Tracking, Verification Evidence, Traceability 구축 방법과 Audit 대응 전략을 알아봅니다.

Keywords: ISO 26262, Verification Evidence, Traceability, Defect Tracking, 테스트 케이스 관리, 기능안전, Verification, Audit, Safety Requirement

---

🚗 ISO 26262 중급 강좌 9강: 검증 수행과 Verification Evidence 품질(테스트 케이스 관리, Defect Tracking, Traceability까지)

기능안전 프로젝트에서 검증(Verification)은 단순히 테스트를 수행하는 활동이 아닙니다.
"안전 요구사항이 실제로 충족되었음을 입증하는 증거(Evidence)를 만드는 과정" 입니다.

ISO 26262에서는 테스트 결과뿐 아니라 요구사항, 결함, 변경 이력, 재시험 결과까지 연결된 형태의 증적 관리를 요구합니다.

이번 강의에서는 실무 Audit에서 가장 많이 확인하는 Verification Evidence 품질과 Traceability 구축 방법을 살펴보겠습니다. 🔍

---

1. Verification Evidence란 무엇인가? 📑

많은 개발 조직이 테스트 리포트는 잘 작성합니다.

하지만 심사 시 다음 질문이 나오면 막히는 경우가 많습니다.

• 어떤 Safety Requirement를 검증했는가?
• 실패한 테스트는 어떻게 처리했는가?
• 결함 수정 후 재시험은 수행했는가?
• 변경된 소프트웨어 버전에서도 동일한 결과가 유지되는가?

Verification Evidence는 단순한 테스트 로그가 아닙니다.

안전 요구사항 충족을 입증하는 객관적 증거 집합(Objective Evidence)

 

ISO 26262-8과 ISO 26262-10은 검증 결과가 추적 가능하고 재현 가능해야 함을 강조합니다.

---

2. 테스트 케이스 관리 실무 🧪

테스트 케이스 수가 많다고 검증 품질이 높아지는 것은 아닙니다.

중요한 것은 요구사항과 테스트 간 연결성(Traceability) 입니다.

예를 들어:

Safety Requirement SR-001

↓

Software Requirement SWR-001

↓

Test Case TC-001

↓

Test Result TR-001

↓

Defect DEF-001

↓

Re-Test RTR-001

이 흐름이 한눈에 보이는 구조가 되어야 합니다.

실무 체크포인트

✅ 모든 테스트 케이스는 Requirement ID 보유

✅ Pass/Fail 기준 명확화

✅ 테스트 환경 기록

✅ 수행 버전 명시

✅ 재시험 결과 연결

---

테스트 추적 구조 예시

Safety Goal
    ↓
Functional Safety Requirement
    ↓
Technical Safety Requirement
    ↓
Software Safety Requirement
    ↓
Test Case
    ↓
Test Result
    ↓
Defect
    ↓
Fix Version
    ↓
Re-Test

---

3. Defect Tracking은 검증의 일부다 🛠️

실무에서 자주 발생하는 문제 중 하나가

"결함은 관리되는데 안전 요구사항 영향이 연결되지 않는 경우"입니다.

예를 들어 CAN Timeout 검출 실패가 발생했다고 가정해 보겠습니다.

단순히 Jira나 Redmine에 등록하는 것으로 끝나면 안 됩니다.

반드시 다음 정보가 연결되어야 합니다.

• 관련 Safety Requirement
• 영향 받는 기능
• ASIL 수준
• 수정 버전
• 재시험 결과

특히 ASIL C/D 프로젝트에서는 미해결 Defect가 Safety Goal에 미치는 영향 평가가 필요합니다.

 

👉 Defect Tracking은 Verification 활동의 연장선입니다.

---

4. 문서는 많은데 왜 증적이 약할까? 📊

Audit에서 자주 듣는 지적 사항이 있습니다.

"문서는 충분하지만 Traceability가 부족합니다."

 

실제로 다음 문서들이 각각 존재하더라도 연결되지 않으면 의미가 약합니다.

• Test Specification
• Test Report
• Review Report
• FMEA 결과
• Defect List
• Change Request

반대로 문서 수가 적어도 요구사항 중심으로 연결되어 있으면 강력한 Evidence가 됩니다.

좋은 Evidence의 조건

항목확인 내용

완전성	모든 요구사항 검증 여부
정확성	결과와 판정 기준 일치
추적성	Requirement-Test-Defect 연결
재현성	동일 환경에서 반복 가능
독립성	검증 수행자의 독립성 확보

 

---

6. OEM / Tier1 / Tier2 관점 정리 🏭

OEM

• 차량 레벨 Verification Strategy 수립
• Safety Goal 검증
• Supplier Evidence 검토

Tier1

• ECU 수준 Test Case 관리
• Defect Tracking 운영
• Verification Report 작성

Tier2

• HW/SW Component 검증
• Unit Test Evidence 제공
• 변경 이력 및 재시험 결과 제공

👉 OEM은 안전성 입증을, Tier1은 통합 검증을, Tier2는 컴포넌트 수준 증적 생성을 담당합니다.

---

핵심 정리 📝

✅ Verification Evidence는 테스트 로그가 아니라 안전 요구사항 충족의 객관적 증거이다.

✅ 테스트 케이스 수보다 Requirement와의 연결성이 중요하다.

✅ Defect Tracking은 검증 활동의 일부로 관리해야 한다.

✅ Audit 대응의 핵심은 Traceability와 재현성이다.

✅ Requirement → Test → Defect → Re-Test 구조가 명확해야 강력한 Evidence가 된다.

---

📢 다음 강의 예고

ISO 26262 중급 강좌 10강 – FMEA와 FTA 실전 적용: 안전 분석 결과를 설계와 검증에 연결하는 방법

 

기능안전 프로젝트의 핵심 분석 기법인 FMEA(Failure Mode and Effects Analysis) 와 FTA(Fault Tree Analysis) 를 실제 ECU 개발 사례를 통해 자세히 알아보겠습니다.