검증팀이 관리해야 할 ASPICE 테스트 산출물
자동차 소프트웨어 개발에서 검증팀은 단순히 테스트를 실행하는 조직이 아니다. 요구사항과 설계가 실제 소프트웨어에 제대로 반영되었는지 확인하고, 테스트 결과를 통해 품질 수준을 객관적으로 보여주는 역할을 한다. ASPICE가 적용되는 프로젝트에서는 검증 활동의 결과를 산출물로 명확히 남기는 것이 중요하다. 테스트를 많이 수행했더라도 어떤 기준으로 수행했는지, 어떤 요구사항을 확인했는지, 실패 항목이 어떻게 조치되었는지 설명할 수 없다면 좋은 테스트 산출물이라고 보기 어렵다.
검증팀이 가장 먼저 확인해야 할 산출물은 테스트 계획이다. 테스트 계획에는 테스트 대상, 범위, 환경, 일정, 담당자, 진입 조건, 종료 조건이 포함되어야 한다. 예를 들어 유닛 검증, 소프트웨어 통합 검증, 소프트웨어 적격성 검증 중 어떤 단계를 수행하는지 명확해야 한다. 또한 테스트에 사용할 장비, 시뮬레이터, HIL 환경, CAN 통신 장비, 테스트 자동화 도구 등도 정리해야 한다. 테스트 계획이 명확해야 이후 결과를 판단하는 기준도 분명해진다.
두 번째로 중요한 산출물은 테스트 케이스다. 테스트 케이스는 요구사항이나 설계를 기준으로 작성되어야 하며, 입력 조건, 수행 절차, 예상 결과, 판정 기준이 포함되어야 한다. 단순히 “기능 확인”처럼 작성하면 실제로 무엇을 검증했는지 알기 어렵다. 좋은 테스트 케이스는 특정 요구사항을 어떤 조건에서 어떻게 확인할 것인지 구체적으로 설명해야 한다. 정상 조건뿐 아니라 비정상 조건, 경계값, 통신 오류, 신호 누락, 타이밍 조건도 함께 고려하는 것이 좋다.
세 번째는 테스트 결과서다. 테스트 결과서에는 실행 일자, 테스트 환경, 소프트웨어 버전, 테스트 수행자, 결과 판정, 로그, 캡처 자료, 실패 항목이 포함되어야 한다. 자동차 소프트웨어는 버전 관리가 중요하기 때문에 어떤 소프트웨어 빌드와 어떤 요구사항 버전을 기준으로 테스트했는지 반드시 남겨야 한다. 동일한 테스트를 다시 수행했을 때 결과를 재현할 수 있어야 ASPICE 관점에서 신뢰성 있는 산출물로 볼 수 있다.
검증팀 관점에서 특히 중요한 것은 추적성이다. 테스트 케이스는 소프트웨어 요구사항, 아키텍처 설계, 상세 설계와 연결되어야 한다. 하나의 요구사항이 어떤 테스트로 검증되었는지 확인할 수 있어야 하며, 반대로 특정 테스트가 어떤 요구사항을 확인하기 위한 것인지도 설명할 수 있어야 한다. 추적성이 부족하면 테스트 누락 여부를 판단하기 어렵고, 요구사항 변경 시 재검증 범위를 정하기도 어렵다.
결함 관리 산출물도 빠질 수 없다. 테스트 중 실패가 발생하면 결함의 재현 조건, 실제 결과, 기대 결과, 로그, 심각도, 담당자, 수정 상태를 기록해야 한다. 수정이 완료된 후에는 재검증 결과도 함께 남겨야 한다. 실패 항목이 단순히 닫힌 상태로만 남아 있고 원인 분석이나 재검증 기록이 없다면 검증 활동의 완성도가 떨어져 보일 수 있다.
결론적으로 ASPICE 테스트 산출물은 테스트를 수행했다는 흔적이 아니라, 요구사항이 실제로 검증되었음을 보여주는 근거다. 검증팀은 테스트 계획, 테스트 케이스, 테스트 결과서, 추적성 매트릭스, 결함 관리 이력을 일관성 있게 관리해야 한다. 이러한 산출물이 잘 정리되어 있으면 ASPICE Assessment 대응은 물론 자동차 소프트웨어의 품질과 신뢰성을 높이는 데도 큰 도움이 된다.