ISO 26262·IEC 62304 — 위험 등급이 테스트 강도를 정한다

개념

"고장 나지 않게"에서 "고장 나도 안전하게"로

지금까지 배운 QA의 목표는 대체로 하나였다. 결함을 줄이는 것. 더 많이 찾고, 더 일찍 찾고, 다시 안 생기게 막는 일이다.

기능 안전이 다루는 시스템은 여기서 출발점이 다르다. 전제 자체가 "결함은 남는다" 이다. 반도체는 물리적으로 고장 나고, 커넥터는 진동으로 접촉이 끊기며, 소프트웨어에는 우리가 아직 못 찾은 결함이 있다. 이 전제를 인정한 다음 질문이 바뀐다.

고장을 없앨 수 없다면, 고장이 났을 때 시스템이 어디로 가야 사람이 안 다치는가?

이 질문에 설계와 검증으로 답하는 사고방식이 기능 안전(Functional Safety) 이다. 핵심 개념은 안전 상태(safe state) 다. 전동 파워스티어링을 예로 들어보자. 조향 보조 토크를 계산하는 모듈이 이상한 값을 내놓기 시작했다. 기능 안전의 답은 "그 계산을 완벽하게 만든다"가 아니다. 이상값을 감지하면 보조를 끊고 수동 조향으로 떨어뜨린다 는 것이다. 핸들은 무거워지지만 운전자는 여전히 차를 조종할 수 있다. 무보조 상태가 이 시스템의 안전 상태다.

그래서 요구사항 목록에 낯선 줄들이 붙는다. "고장을 몇 밀리초 안에 감지할 것", "감지 후 몇 밀리초 안에 안전 상태로 이행할 것". 그리고 QA는 정상 동작만이 아니라 이 이행 경로를 테스트해야 한다. 일부러 고장을 주입해서 확인한다.

모듈 1에서 배운 결함(fault) → 오류(error) → 고장(failure)의 전파 사슬에, 마지막 칸 뒤로 "위해(harm)"를 하나 더 붙인 세계라고 보면 된다.

일반 웹 서비스 QA와 무엇이 근본적으로 다른가

차이는 "더 꼼꼼하게 한다" 수준이 아니다. 목표 함수 자체가 다르다.

마지막 줄이 이 레슨 전체를 관통한다. 안전 규격의 세계에서 테스트는 결함을 찾는 일이면서 동시에 "우리는 이만큼 확인했다"를 제3자에게 제출하는 문서를 만드는 일 이다. 이 이중성을 이해하지 못하면 규격 환경에 처음 간 QA는 "왜 이렇게 서류가 많냐"는 불평에서 벗어나지 못한다.

ISO 26262 — 위험을 세 축으로 쪼개 등급을 만든다

ISO 26262 (Road vehicles — Functional safety) 는 도로 차량의 전기·전자(E/E) 시스템 기능 안전 표준이다. 산업 전반의 기능 안전 표준인 IEC 61508을 자동차 도메인에 맞게 다시 쓴 것으로, 2011년 1판 이후 2018년에 2판이 나오면서 적용 범위와 파트가 넓어졌다.

여러 파트로 나뉜다. 테스트 엔지니어가 위치를 알아야 할 곳은 몇 군데다.

ASIL 등급은 Part 3의 HARA 에서 나온다. 원리가 명쾌하다. 위험한 사건 하나를 놓고 세 가지를 각각 매긴다.

이 세 값의 조합이 등급을 결정한다. 결과는 QM, ASIL A, B, C, D 다. D가 가장 엄격하고, QM(Quality Management)은 "이 규격이 추가로 요구하는 안전 활동이 붙지 않는다"는 뜻이다. QM은 "테스트 안 해도 된다"가 아니라 "일반 품질관리로 충분하다" 는 판정이라는 점을 꼭 구분하자.

아래는 축을 이해하기 위한 감각용 예시다. 실제 등급은 HARA에서 근거와 함께 결정되며, 이건 정답표가 아니다.

여기서 얻어갈 통찰은 "세 축 중 하나만 낮아도 등급이 내려간다" 는 것이다. 특히 제어 가능성(C)이 축에 들어 있다 는 점이 중요하다. 심각도가 같아도 운전자가 쉽게 대처할 수 있으면 등급이 내려간다. 자동차라는 도메인이 "사람이 루프 안에 있다"는 사실을 등급 공식에 명시적으로 넣은 것이다. 이 설계 선택을 기억해 두자. 잠시 뒤 의료기기 규격이 같은 자리에 다른 것 을 넣는 걸 보게 된다.

등급이 올라가면 테스트는 어떻게 강해지는가 — Part 6

소프트웨어 개발을 다루는 Part 6 은 "이렇게 하시오" 문장으로 되어 있지 않다. 활동마다 방법 표 가 있고 각 셀에 ASIL A~D별 권고 강도가 표기된다. 흔히 ++(강력 권고), +(권고), o(권고 없음)로 읽는다. 즉 규격은 방법을 나열하고 "이 등급에서는 이 방법을 이만큼 강하게 권고한다" 라고 말한다. 다른 방법을 쓰려면 동등한 근거를 제시해야 한다.

등급이 올라갈 때 테스트가 강해지는 방향은 세 갈래다.

1. 테스트 방법의 수가 늘어난다. 요구사항 기반 테스트에서 시작해 인터페이스 테스트, 고장 주입 테스트(fault injection), 자원 사용량 평가, 모델과 코드의 백투백 비교 테스트가 차례로 얹힌다.
2. 테스트 케이스 도출 기법이 늘어난다. 모듈 3에서 배운 동등 분할·경계값 분석·오류 추정 같은 기법들이 "권고 기법" 목록으로 그대로 등장한다. 등급이 높을수록 여러 기법을 조합해 도출했음을 보여야 한다.
3. 구조 커버리지 기준이 올라간다. 구문 → 분기 → MC/DC 순서다.

위 표는 경향 을 보여주기 위한 요약이다. 실제 셀 값과 표기(++/+/o)는 ISO 26262-6의 해당 표를 원문으로 확인해야 하며, 프로젝트에서는 반드시 규격 원문과 사내 안전 계획서를 근거로 삼아야 한다.

등급이 올라가면 구문 커버리지의 권고 강도가 오히려 내려가는 게 눈에 띈다. 요구가 약해진 게 아니라, 더 강한 기준이 약한 기준을 사실상 포함하기 때문에 강조점이 위로 옮겨간 것이다.

MC/DC가 무엇이고 어떻게 케이스를 고르는지는 모듈 3 레슨 7 에서 이미 코드로 계산해봤다. 여기서 새로 얻을 것은 "규격은 왜 하필 그 기준을 요구하는가" 다. 답은 분기 커버리지의 한계에 있다. if (a && b && c) 같은 복합 조건에서 분기 커버리지는 참·거짓 두 경로만 보면 만족하고, 그 안에 아무 영향도 주지 않는 죽은 조건 이 섞여 있어도 통과한다. ASIL D에서 MC/DC를 요구한다는 건 질문을 바꾸겠다는 선언이다.

즉 "얼마나 많이 실행했나"에서 "이 논리가 실제로 필요한 것들로만 이루어져 있음을 증명했나" 로 올라간다. 안전 등급이 높다는 건 코드에 대해 더 강한 주장을 하라는 요구다. 통합 수준에서는 함수 커버리지·호출 커버리지 같은 기준이 같은 역할을 한다.

IEC 62304 — 피해의 크기로 A·B·C를 나눈다

IEC 62304 (Medical device software — Software life cycle processes) 는 의료기기 소프트웨어의 생명주기 표준이다. 2006년 초판에 2015년 개정(Amendment 1)이 더해진 형태로 쓰이며, 유럽과 미국의 의료기기 심사에서 사실상의 참조 기준이다.

등급은 세 개고, 기준은 "소프트웨어가 고장 났을 때 환자·사용자에게 어떤 피해가 가능한가" 하나다.

자동차는 축이 세 개(S·E·C)인데 의료기기는 피해의 심각도 한 축 이다. 노출 빈도가 공식에 없다. 주행 상황은 "이 조건이 겹칠 확률"을 따질 수 있지만, 의료기기는 위험한 상황이 대개 정확히 그 기기를 쓰는 순간 이라 노출을 따로 나눌 실익이 적다.

대신 개정된 62304는 다른 자리에 완충 장치를 넣었다. 소프트웨어 바깥의 위험 통제 수단 이다. 하드웨어 인터록, 기계식 안전밸브, 이중 확인 절차처럼 소프트웨어가 틀려도 위해를 막아주는 장치가 있다면, 그 사실을 근거로 더 낮은 등급을 매길 수 있다는 구조다.

여기서 두 규격의 대비가 완성된다.

같은 발상의 다른 구현이다. 위험의 크기만으로 등급을 정하지 않고, "그럼에도 막아줄 수단이 있는가"를 함께 본다. 자동차는 그 수단으로 사람을 세었고, 의료기기는 장치와 절차를 세었다.

또 하나, 62304는 시스템 전체를 한 등급으로 묶지 않는다. 소프트웨어를 아이템·유닛으로 나누고 그 사이가 충분히 분리(segregation)되어 있음을 보일 수 있다면 부분마다 다른 등급을 매길 수 있다. 아키텍처 설계가 검증 비용을 직접 줄이는 수단이 된다. 투여량 계산 로직만 Class C로 격리하고 로그 뷰어를 Class A로 떼면 전부를 C로 검증할 때보다 일이 훨씬 줄어든다. 물론 그 분리가 실제로 작동한다는 것 자체를 증명해야 한다.

등급에 따라 요구되는 활동이 달라지는 구조는 대략 이렇다.

이 표도 구조를 이해하기 위한 요약 이다. 62304 원문은 조항마다 머리에 [Class B, C] 처럼 적용 등급을 직접 표기한다. 실제 프로젝트에서 어느 조항이 걸리는지는 요약표가 아니라 원문 조항의 등급 표기를 직접 확인 해야 한다.

읽는 법이 중요하다. 등급이 낮다고 "테스트를 안 해도 된다"가 아니다. 강제되는 문서와 세분화 수준이 달라진다. Class A에서도 시스템 테스트는 해야 하지만, 유닛 하나하나에 수용 기준을 문서로 정의하고 그 결과를 보관할 의무는 없다.

SOUP — 남이 만든 코드에도 책임을 진다

62304에는 다른 규격에서 보기 어려운 개념이 하나 있다. SOUP(Software of Unknown Provenance) 다. 이 생명주기를 거쳐 만들어지지 않은 소프트웨어 — 오픈소스 라이브러리, 상용 RTOS, 운영체제, 구매한 컴포넌트가 전부 여기 해당한다. 웹 서비스의 습관과 나란히 놓으면 차이가 드러난다.

QA 관점에서 이건 "우리가 안 짠 코드도 검증 범위에 들어온다" 는 뜻이다. npm install 한 줄이 여기서는 문서 한 페이지가 된다.

검증·확인의 구분과 추적성 — 앞 모듈이 여기서 규제 요건이 된다

모듈 1 레슨 2 에서 배운 구분을 다시 꺼내자. 검증(Verification)은 "우리가 제대로 만들고 있는가" — 산출물이 명세·설계와 일치하는가. 확인(Validation)은 "우리가 맞는 것을 만들고 있는가" — 실제 사용 요구를 충족하는가.

일반 프로젝트에서 이 구분은 개념적 도구다. 의료기기 영역에서는 제출 대상이 다른 두 개의 서류 묶음 이 된다. IEC 62304는 소프트웨어 생명주기 안의 검증 활동을 규정하고, 기기가 의도한 임상적 사용 목적을 충족하는지 보이는 확인은 품질경영시스템(ISO 13485)과 각국 규제 쪽에서 요구한다. 그래서 이런 답이 통하지 않는다.

"단위 테스트 2,400건 전부 통과했습니다." — 이건 검증의 증거 다. "이 기기가 임상 환경에서 의도한 용도를 달성한다"는 확인의 증거 가 아니다.

두 증거를 섞어 제출하면 심사에서 되돌아온다.

그리고 모듈 2 레슨 5 에서 만든 추적성 매트릭스가 여기서 규제 요건이 된다. 다만 사슬이 하나 더 붙는다.

세 번째 줄이 규격 환경의 진짜 특징이다. 모듈 2에서는 "이 요구사항이 테스트됐음"을 증명했다. 여기서는 "이 위험을 줄이려고 넣은 그 장치가, 실제로 요구사항이 되었고, 구현되었고, 검증되었음" 을 끝에서 끝까지 이어 보여야 한다. 위험 관리(의료기기에서는 ISO 14971 계열)에서 나온 위해요인 ID가 추적성 매트릭스의 열로 들어오는 셈이다.

두 규격에서 뽑아낸 공통 구조 세 가지

여기까지 왔으면 이 레슨의 핵심 메시지를 정리할 수 있다. 두 규격은 조항도 용어도 다르지만 뼈대는 같다.

1. 위험을 등급으로 나눈다. 축은 도메인마다 다르다. 그 축이 무엇이냐가 그 산업이 무엇을 두려워하는지를 보여준다.
2. 등급이 활동과 테스트 강도를 결정한다. 규격은 "테스트를 잘 하라"고 하지 않는다. "이 등급이면 이 방법 목록, 이 커버리지 기준, 이 문서"라고 말한다.
3. 모든 활동은 문서로 증명 가능해야 한다. 계획, 절차, 결과, 판정 기준, 승인, 변경 이력이 남아야 한다. 남지 않은 활동은 하지 않은 것으로 취급된다.

같은 뼈대를 다른 도메인 규격에 대보면 바로 읽힌다.

그래서 처음 보는 도메인 안전 규격을 만났을 때 30초 안에 할 일 이 정해진다. 모듈 개요가 말한 "규격 번호를 만났을 때의 판단"이 구체적으로는 이 네 질문이다.

1. 등급 체계가 무엇인가 — 이름과 개수를 찾는다.
2. 등급을 정하는 축이 무엇인가 — 이 도메인이 무엇을 두려워하는지가 드러난다.
3. 내 산출물이 등급에 따라 어떻게 달라지는가 — 대개 표로 정리되어 있다.
4. 무엇을 증거로 제출해야 하는가 — 여기서 QA의 실제 업무량이 결정된다.

실무에서 왜 필요한가

"테스트했다"가 아니라 "테스트했음을 증명한다"

규격 환경에 처음 간 QA가 가장 놀라는 지점이다. 테스트를 실행하는 시간보다 그 실행을 증거로 만드는 시간이 더 길다.

요구사항 ID가 붙지 않은 테스트 케이스는 이 세계에서 존재하지 않는 것과 같다. 심사에서 "이건 무엇을 검증한 겁니까"에 답할 수 없기 때문이다.

도구조차 신뢰를 증명해야 한다

일반 프로젝트에서 커버리지 도구를 바꾸는 건 취향 문제다. 규격 환경에서는 아니다.

ISO 26262는 지원 프로세스를 다루는 파트에서 소프트웨어 도구 사용에 대한 신뢰 를 별도로 요구한다. 두 가지를 묻는 발상이다. 그 도구가 잘못 동작하면 안전 요구사항 위반이 만들어질 수 있는가? 그런 도구 오류를 다른 수단으로 검출할 수 있는가? 이 두 축으로 신뢰 수준을 정하고, 수준이 높으면 도구 자체를 검증하는 활동(도구 자격 확인)을 요구한다. 컴파일러·정적 분석기·커버리지 도구·코드 생성기가 다 대상이다.

현실적 의미가 크다. "커버리지 측정을 사내 스크립트로 바꾸자"는 결정이 편의 개선이 아니라 안전 논거의 변경이 된다. 모듈 3 레슨 7에서 이름만 봤던 VectorCAST·LDRA 같은 상용 도구가 비싼 값에 팔리는 이유가 여기 있다. 도구 자격 확인 자료를 같이 팔기 때문이다.

변경 하나에 따라오는 무게

일반 서비스에서 "한 줄 고쳤어요"는 가벼운 말이다. 여기서는 아니다.

모듈 2의 추적성 매트릭스가 여기서 성격을 바꾼다. "있으면 편한 것"이 아니라 "이게 없으면 무엇을 다시 테스트하지 않아도 되는지를 정당화할 수 없는 것" 이 된다.

규격이 QA에게 실제로 주는 것

부담만 있는 건 아니다. 규격 환경의 QA는 "어디까지 테스트해야 하는가"를 매번 협상하지 않는다. 등급이 정해주기 때문이다. 일정 압박 앞에서 "이번엔 그냥 넘어가죠"가 통하지 않는 구조는 역설적으로 QA를 보호한다.

대신 힘을 써야 할 자리가 앞으로 옮겨간다. 등급을 정하는 회의(HARA, 위험 분석)에 QA가 들어가야 한다. 등급 하나가 올라가면 이후 반년의 작업량이 결정되고, 근거 없이 높게 매겨진 등급은 팀 전체를 태운다.

채용시장에서의 위치

모듈 개요에서 본 대로 이 영역은 어느 산업에 있느냐 가 전부를 가른다. 이 레슨의 두 규격에 한정해 덧붙일 것은 세 가지다.

• 공고에 등급이 그대로 적힌다. "ASIL D 프로젝트 경험", "IEC 62304 Class C 개발 이력"처럼 등급 단위로 요구된다. 등급이 그 사람이 겪어본 문서량과 검증 강도의 지표로 읽히기 때문이다.
• 인접 규격을 세트로 묻는다. 자동차라면 Automotive SPICE, 의료기기라면 위험 관리(ISO 14971)·품질경영시스템(ISO 13485)과 함께 묻는 경우가 많다.
• 자격증으로는 ISTQB의 자동차 소프트웨어 테스터(CT-AuT)가 가장 가깝다.

규격 경험이 없는 상태에서 가장 설득력 있는 재료는 추적성과 증거 관리 경험 이다. 일반 프로젝트에서라도 요구사항 ID와 테스트를 연결해 관리하고 변경 시 재테스트 범위를 문서로 정당화해봤다면, 그게 규격 환경 언어로 번역되는 경험이다.

실습 과제

과제 1 — ASIL 등급 직접 매겨보기 (18분)

아래 세 가지 위험 사건에 대해 S·E·C를 각각 상·중·하로 매기고, 세 값을 근거로 어느 등급 쪽에 가까울지 판단한다. 정확한 등급 문자보다 판단 근거를 문장으로 쓰는 것 이 목적이다.

과제 2 — IEC 62304 안전 등급 나누기 (15분)

인슐린 펌프의 소프트웨어를 세 부분으로 나눴다. 각각 Class A·B·C 중 어디에 가까울지 판단하고, 등급을 낮추기 위해 무엇을 설계에 추가할 수 있을지 한 줄씩 적는다.

과제 3 — 위해요인까지 이어지는 추적 사슬 그리기 (12분)

과제 2의 ① 모듈에 대해, 아래 사슬을 한 줄로 완성한다. 각 칸에 실제로 쓸 법한 ID와 문장을 채운다.

위해요인 → 위험 통제 수단 → 소프트웨어 요구사항 → 설계·코드 → 검증 테스트 → 결과 기록

완성한 뒤 스스로에게 묻는다. "투여량 상한 로직을 한 줄 고쳤을 때, 이 사슬만 보고 다시 테스트해야 할 것을 전부 짚어낼 수 있는가?" 짚어낼 수 없다면 사슬 어디가 끊겨 있는지 표시한다.

과제 4 — 처음 보는 규격 30초 판독 (선택, 20분)

이 레슨에서 다루지 않은 도메인 안전 규격 하나를 고른다(철도의 EN 50128, 산업 전반의 IEC 61508, 원자력의 IEC 61513 등). 공개된 개요 문서나 표준 판매 페이지의 범위(scope) 설명만 읽고 네 질문에 답해본다.

1. 등급 체계의 이름과 개수는?
2. 등급을 정하는 축은 무엇인가? 그 축에서 이 산업이 무엇을 두려워하는지 읽히는가?
3. 등급에 따라 소프트웨어 검증 요구가 어떻게 달라지는가?
4. 무엇을 증거로 제출해야 하는가?

네 칸이 대략이라도 채워졌다면 이 레슨의 목표는 달성된 것이다. 막히는 칸이 있다면 공개 자료만으로는 알 수 없는 부분 일 가능성이 높다. 그 경계를 아는 것도 판독 능력의 일부다.

자가 체크리스트

• 기능 안전이 "고장을 없앤다"가 아니라 "고장이 나도 안전 상태로 간다"를 목표로 삼는 이유를 설명할 수 있다
• 안전 필수 시스템의 테스트가 일반 서비스 QA와 목표 함수부터 다른 이유를 표로 설명할 수 있다
• ASIL이 심각도·노출·제어 가능성의 조합으로 결정된다는 것과 각 축이 묻는 질문을 말할 수 있다
• ASIL의 QM이 "테스트 안 해도 된다"가 아니라는 것을 설명할 수 있다
• ASIL 등급이 올라갈 때 테스트가 강해지는 세 방향(방법 수·도출 기법·구조 커버리지)을 댈 수 있다
• 규격이 높은 등급에서 MC/DC를 요구하는 이유를 분기 커버리지의 한계로 설명할 수 있다
• IEC 62304의 안전 등급 A·B·C가 무엇으로 나뉘는지 말할 수 있다
• 두 규격이 "그래도 안 다칠 수 있는 이유" 자리에 각각 무엇을 넣었는지 대비해 설명할 수 있다
• SOUP이 무엇이고 QA에게 무슨 일을 만드는지 설명할 수 있다
• 검증과 확인의 구분이 규제 환경에서 왜 특히 엄격한지 설명할 수 있다
• 안전 규격 세 개의 공통 구조(등급화·강도 결정·증거화)를 말하고, 처음 보는 규격에 네 질문을 적용할 수 있다
• 도구 자격 확인이 왜 필요한지와, 도구 교체가 왜 가벼운 결정이 아닌지 설명할 수 있다

흔한 실수

• 등급을 "이 모듈이 얼마나 복잡한가"로 정한다. 등급은 복잡도가 아니라 틀렸을 때 위해로 가는 경로가 있는가 로 정해진다. 세 줄짜리 표시 로직이 수천 줄짜리 로그 모듈보다 높은 등급을 받는 일이 흔하다.
• 최고 등급을 전체에 일괄 적용하고 안심한다. 안전해 보이지만 팀을 태운다. 두 규격 모두 분할과 분리를 통해 부분마다 다른 등급을 매기는 길 을 열어두고 있고, 그 설계가 검증 비용을 실제로 줄인다.
• "QM이니까 테스트 안 해도 된다"고 읽는다. QM은 이 규격이 요구하는 안전 활동이 추가로 붙지 않는다 는 뜻이지, 품질 활동의 면제가 아니다.
• 검증 결과를 확인 결과인 것처럼 제출한다. 단위·통합 테스트가 전부 통과했다는 사실은 "명세대로 만들었다"의 증거이지 "임상적으로 의도한 용도를 달성한다"의 증거가 아니다. 두 묶음은 끝까지 분리해서 관리한다.
• 오픈소스 라이브러리를 검증 범위 밖으로 둔다. SOUP 요구는 남이 만든 코드에도 책임을 지운다. 버전 고정과 알려진 이상 목록 검토가 빠지면 그 자체로 지적사항이다.
• 정상 동작만 테스트하고 고장 경로를 빼먹는다. 기능 안전의 핵심은 안전 상태로의 이행이다. 고장을 일부러 주입해 그 경로를 확인하지 않으면 가장 중요한 요구사항이 검증되지 않은 채 남는다.
• 안전 기능 자체가 위험원이 될 수 있다는 걸 놓친다. 긴급제동이 필요할 때 안 걸리는 것만 위험한 게 아니라, 필요 없을 때 걸리는 것도 위험하다. 오작동 (unintended activation) 시나리오를 테스트 설계에 반드시 넣는다.
• 요약표와 블로그 글을 근거로 프로젝트 판단을 내린다. 이 레슨의 표들을 포함해 2차 자료는 구조를 이해하는 용도다. 어떤 조항이 우리에게 걸리는지는 규격 원문과 사내 안전 계획서로 확인 해야 한다.

참고 자료

• ISO 26262-6:2018 — Product development at the software level — 소프트웨어 수준 개발 요구가 담긴 파트. 이 레슨의 단위·통합 테스트 방법 표가 여기 있다
• ISO 26262-6:2018 온라인 열람(OBP) — 범위와 용어 정의를 무료로 확인할 수 있다. 정확한 표 값은 정식 구매본으로 확인해야 한다
• IEC 62304:2006+AMD1:2015 CSV — 의료기기 소프트웨어 생명주기 표준의 통합본. 조항마다 적용 안전 등급이 표기된 형태를 확인할 수 있다
• IEC TR 80002-1:2009 — ISO 14971의 의료기기 소프트웨어 적용 지침 — 위해요인에서 위험 통제 수단으로 이어지는 사슬을 소프트웨어에 어떻게 적용하는지 다룬 기술 보고서
• FDA, General Principles of Software Validation — 검증과 확인의 구분, 도구 밸리데이션에 대한 규제기관의 관점을 무료로 읽을 수 있는 문서
• ISTQB Certified Tester Automotive Software Tester (CT-AuT) — ISO 26262·Automotive SPICE와 XiL 테스트 환경을 다루는 자격증. 실러버스가 공개되어 있다