(A-SPICE 19회차) SWE.6: 소프트웨어 인정 시험! 시험은 끝날 때까지 끝난 게 아니다!

🧪 19회차: SWE.6 – 소프트웨어 인정 시험! 시험은 끝날 때까지 끝난 게 아니다!

"우리 소프트웨어, 단위 시험도 했고, 통합 시험도 끝났는데… 왜 또 시험을?"
음… 여러분, 아직 진짜 큰 산이 남아 있습니다. 이름하여 👉 SWE.6 - 소프트웨어 인정 시험!

---

🎯 SWE.6이 뭐예요?

SWE.6 = Software Qualification Testing
SWE.4에서 단위 시험하고, SWE.5에서 통합 시험하고, 이제 SWE.6에서는 소프트웨어 전체가 요구사항을 만족하는지를 시험하는 단계예요.

✔️ 목표는?
👉 "소프트웨어가 제대로 작동하는지를 확인하는 것!"

---

🧠 시험은 시험인데… 어떤 시험이죠?

🔍 SWE.5 vs SWE.6 (소프트웨어 통합시험 vs 소프트웨어 인정 시험)

항목	SWE.5 (소프트웨어 통합 시험)	SWE.6 (소프트웨어 인정 시험)
목적	모듈 간 연동 검증	전체 소프트웨어 기능 검증
중심	인터페이스와 흐름	요구사항 만족 여부
시험 대상	코드 구성 요소 간의 상호작용	전체 소프트웨어가 요구사항을 만족하는지
예시	"A → B 호출 잘 돼?"	"이 버튼 누르면 진짜 창문이 열려?"

SWE.5는 내부 점검이라면,
SWE.6는 완전체 기능의 시험입니다! 🚀

---

🧪 그럼 Verification vs Validation은 뭔가요?

헷갈리는 V&V(V-Model의 핵심) 개념, 여기서 확실히 정리하고 갑시다!

개념	뜻	예시
Verification	“우리가 만든 것이 스펙에 맞는가?”	코드가 요구사항대로 동작하는가?
Validation	“우리가 만든 것이 사용자의 목적에 맞는가?”	실제 사용자가 원하는 기능이 구현됐는가?

• SWE.6에서는 둘 다 필요하지만, Verification에 더 가까운 시험입니다. 

       (소프트웨어 요구사항 기반이라 Validation 요소도 포함)

• 이 시험이 제대로 안 되면… 출시 후 고객에게 제대로 혼날 수 있어요 😱

---

🧰 SWE.6에서는 뭘 해야 하나요?

1️⃣ 소프트웨어 요구사항 기반 시험 항목 도출

• SWE.1에서 정의된 소프트웨어 요구사항을 다시 확인하고, 시험 항목으로 변환!

2️⃣ 시험 환경 구성

• 가짜가 아닌, 실환경 또는 HIL/SIL 기반 환경에서!
• 시험 장비, 시나리오, 로그 장치 준비 완료 🎬

3️⃣ 시험 수행 및 로그 관리

• 시험 수행 후 결과를 문서화!
• 문제가 생기면 반드시 결함 등록 + 개선 계획 수립

4️⃣ 반복! 반복! 반복!

• 결함을 수정한 후에는 재시험(Re-test) 이 필수!
• 시험 사이클을 기록으로 남겨야 A-SPICE에서 인정받을 수 있어요

---

🏭 현업에서 자주 나오는 실수들

😅 요구사항 없이 시험부터 시작

“그냥 기능 작동만 확인해 봤어요” → Validation이 안 됩니다!

😅 시험 결과를 로그로 안 남김

“우리 다 했어요!” → 근거 없이는 시험 안 한 거로 봅니다!

---

🧠 SWE.6은 왜 중요한가요?

• 소프트웨어 요구사항을 충족하는지 최종 확인 단계
• 기능안전(ISO 26262)에서는 Software Safety Requirement가 검증되는 단계
• 고객사 EO, 양산 승인, 리콜 예방 등과 직결되는 핵심 시험!

---

🧪 SWE.6 요약정리

항목	내용
무엇을?	전체 소프트웨어 시험
왜?	소프트웨어 요구사항을 제대로 구현했는지 확인
어떻게?	시험 계획 → 환경 구성 → 시험 수행 → 결과 문서화
실패 시?	양산 실패, 고객 불만, 프로젝트 재시작… 😭

---

🔮 다음 회차 예고: 20회차 – ACQ.4, 소프트웨어 공급자의 계약 관리란?

"개발은 잘했는데… 계약은 어떻게 하죠?"
A-SPICE에서는 개발뿐 아니라, 외부 업체와의 계약과 협업 관리도 매우 중요합니다!

✔️ 공급자 선정부터 성과 관리까지
✔️ 협력사와 개발 프로세스를 맞추는 법
✔️ 중소기업 vs 대기업의 현실적인 접근법

다음 시간에 속 시원히 풀어드릴게요!
우리 계약도, 블로그도 잘 맺어봅시다! 😄