ISO/IEC/IEEE 29119의 구조: Part 1부터 Part 4까지

개념

법을 다루는 사람이 법전을 외우지 않는다. 목차를 안다. 어떤 문제가 오면 그것이 몇 편 몇 장에 있는지 짐작하고 그 부분만 펼친다.

표준도 똑같이 쓴다. 29119는 수백 쪽이고, 전부 읽는 사람은 거의 없다. 필요한 것은 "지금 내 질문의 답이 어디 있나" 를 아는 것이고, 이 레슨은 그 지도를 그린다.

4개 파트로 나뉜 이유

표준 문서 하나를 처음부터 끝까지 읽으려 하면 방대해서 압도당하기 쉽다. 다행히 ISO/IEC/IEEE 29119는 역할이 분명한 4개 파트로 나뉘어 있어서, 지금 내가 궁금한 게 어느 파트에 있는지만 알면 필요한 부분만 찾아볼 수 있다.

시리즈는 넷보다 많다

실무에서 핵심은 Part 1~4이지만, 시리즈 자체는 더 넓다.

마지막 줄은 기술 시방서(TS) 형태로 나온 것으로, 스테이지 6의 AI 검증 모듈과 직접 이어진다. 번호가 연속이 아닌 것에 놀라지 않아도 된다 — 표준 시리즈는 필요에 따라 번호를 띄워 추가한다.

정확한 구성과 최신 개정 연도는 공식 목록에서 확인하는 것이 원칙이다. 표준은 개정되고, 개정되면 항목 번호와 템플릿 구성이 바뀐다.

버전을 함께 적는 습관

표준을 인용할 때 번호와 개정 연도를 함께 적는다.

왜 중요한가 — 계약이나 심사 기준에 "29119 준수" 라고만 적혀 있으면, 어느 판을 기준으로 할지 분쟁이 생긴다. 개정판에서 항목이 빠지거나 합쳐지면 "그 항목이 없다" 는 지적이 서로 다르게 읽힌다.

실무에서는 착수 때 버전을 고정해 두는 것이 안전하다. 레슨 1의 "착수 때 산출물 형식을 받아 온다" 에 버전 확인을 한 줄 더하는 것이다.

Part 1 — 개념과 정의 (Concepts and Definitions)

표준 전체에서 쓰이는 용어와 기본 개념을 정의한다. "테스트 프로세스란 무엇인가", "테스트 케이스란 무엇인가" 같은 기초 어휘집 역할이다. 표준을 처음 접할 때 가장 먼저 봐야 할 파트다.

그런데 Part 1의 실무 쓸모는 "처음 읽는 것" 이 아니다. 용어 분쟁이 생겼을 때 펼치는 것이다.

"저희가 말하는 테스트 케이스와 귀사가 말하는 것이 다른 것 같습니다. 29119-1 정의를 기준으로 맞춰 보겠습니다."

레슨 1에서 본 "케이스 200개가 10배 차이를 뜻하는" 문제를 끝내는 방법이 이것이다. 내 기준이 아니라 제3의 기준을 가져오면 대화가 짧아진다.

Part 1에는 용어 외에 테스트의 기본 개념 모형도 들어 있다 — 테스트 수준(단위·통합·시스템·인수), 테스트 유형(기능·성능·보안 등), 그리고 이들의 관계다. 모듈 1~2에서 배운 틀이 표준 용어로 다시 정리된 형태다.

Part 2 — 테스트 프로세스 (Test Processes)

레슨 3~5에서 자세히 다룰, 조직·관리·동적이라는 세 계층의 테스트 프로세스를 정의한다. "테스트를 어떤 순서로, 누가 책임지고 진행하는가"에 대한 답이 여기 있다.

세 계층이 포함 관계라는 점만 미리 잡아 두면 레슨 3~5가 쉬워진다.

┌─ 조직 테스트 프로세스 ─────────────────────────┐
│  조직의 테스트 정책·전략 (여러 프로젝트에 공통)  │
│                                                │
│  ┌─ 테스트 관리 프로세스 ────────────────────┐  │
│  │  프로젝트 단위: 계획 → 감시·통제 → 완료    │  │
│  │                                          │  │
│  │  ┌─ 동적 테스트 프로세스 ─────────────┐   │  │
│  │  │  설계 → 환경 구성 → 실행 → 기록    │   │  │
│  │  └──────────────────────────────────┘   │  │
│  └────────────────────────────────────────┘  │
└────────────────────────────────────────────────┘

바깥이 안쪽의 기준을 준다. 조직 정책이 "고위험 영역은 반드시 독립 검증" 이라고 정하면, 프로젝트 계획이 그것을 따르고, 실행이 그 계획을 따른다. 거꾸로 실행에서 얻은 결과가 바깥으로 올라가 정책을 고치기도 한다.

Part 3 — 테스트 문서화 (Test Documentation)

레슨 6에서 사례로 따라갈, 테스트 계획서·테스트 설계 명세·테스트 케이스 명세·테스트 완료 보고서 같은 각 산출물의 템플릿과 필수 항목을 정의한다. "이 문서에는 어떤 항목이 꼭 들어가야 하는가"에 대한 답이다.

QA가 실무에서 가장 많이 펼치는 파트이고, 이유가 단순하다 — 외부에서 요구받는 것이 대부분 문서이기 때문이다. 검수·심사·제출 자리에서 "프로세스를 어떻게 정의했나" 보다 "그 문서를 보여 달라" 가 먼저 온다.

Part 3이 다루는 문서는 Part 2의 프로세스 단계마다 하나씩 대응한다.

프로세스가 문서를 낳는다는 구조를 알면 Part 2와 Part 3을 헷갈리지 않는다. Part 2는 "무엇을 하는가", Part 3은 "그 결과를 어떤 형식으로 남기는가" 다.

Part 4 — 테스트 기법 (Test Techniques)

모듈 3에서 배운 동등분할·경계값분석 같은 테스트 설계 기법을 표준화된 용어로 재정의한다. 여러분이 모듈 3에서 배운 내용과 상당 부분 겹치지만, 표준이 이걸 공식 용어로 어떻게 부르는지 확인하는 용도로 쓰인다.

실제로 대조해 보면 이름만 다른 경우가 많다. 모듈 3을 익힌 사람은 Part 4를 새로 배우는 것이 아니라 번역표를 만드는 것에 가깝다.

마지막 줄이 흥미로운 지점이다. 표준도 경험 기반 기법을 포함하고 있어서, 레슨 1에서 본 "문서 중심" 비판과 달리 탐색을 배제하지는 않는다. 다만 그것을 어떻게 기록할지에 대한 요구가 따라붙고, 그 기록 방법이 모듈 5 레슨 11의 세션 노트다.

Part 4의 또 다른 쓸모는 기법을 고른 근거를 적을 때다. "경계값 분석을 적용했다" 고 쓰면서 표준 용어를 쓰면, 심사자가 그 기법의 의미를 되묻지 않는다.

전체 그림

Part 1: 개념·정의       — "용어가 뭘 뜻하는가"
Part 2: 테스트 프로세스  — "누가, 언제, 어떤 순서로 하는가"
Part 3: 테스트 문서화    — "무슨 문서를, 어떤 형식으로 남기는가"
Part 4: 테스트 기법      — "구체적으로 어떻게 테스트 케이스를 설계하는가"

Part 1이 사전이라면, Part 2는 프로세스 지도, Part 3은 문서 양식, Part 4는 실무 기법 카탈로그에 해당한다. 이 강의의 모듈 3(설계 기법)은 사실상 Part 4와, 모듈 4(계획)는 Part 2·3과 이미 상당 부분 맞닿아 있다 — 표준은 이 강의에서 이미 배운 내용들을 하나의 공식 체계로 묶어주는 역할을 한다.

질문을 파트로 보내는 라우팅 표

실무 질문이 오면 어디를 펼칠지 바로 정해지는 것이 목표다.

규칙 하나로 줄이면 이렇다 — "무슨 문서" 는 Part 3, "무슨 활동" 은 Part 2, "무슨 뜻" 은 Part 1, "어떻게 설계" 는 Part 4.

이 커리큘럼과 표준의 대응 지도

표준을 처음 보는 사람이 가장 안심하는 지점이 여기다. 이미 배운 것이 표준의 어디에 해당하는지 알면 "새로 공부할 것" 이 훨씬 줄어든다.

모듈 4와 모듈 6이 표준과 가장 많이 겹친다. 계획서와 보고서가 표준이 요구하는 산출물의 중심이기 때문이고, 그래서 그 두 모듈을 익혔으면 내용은 이미 갖춰진 상태다. 남은 것은 형식을 맞추는 일이다.

표준 문서를 실제로 구해 읽는 법

알아 둘 현실이 하나 있다 — ISO 표준은 유료다. 부별로 따로 구매하고, 가격이 가볍지 않다. 그래서 실무에서는 접근 방법이 몇 가지로 갈린다.

세 번째가 의외로 유용하다. 목차만 봐도 그 문서가 요구하는 항목 목록을 알 수 있고, 산출물 템플릿을 설계할 때는 그것으로 상당 부분 충분하다.

주의할 것은 요약 자료만 보고 "준수했다" 고 말하지 않는 것이다. 심사 대상이라면 원문의 항목 번호를 대조해야 하고, 그때는 원문 접근이 필수다.

사례 — 지도 한 장으로 공부 범위가 줄었다

고객사가 "29119 기반 산출물 제출" 을 요구해 왔다. 팀은 표준을 본 적이 없었고, 처음 반응은 "수백 쪽을 다 봐야 하나" 였다.

QA가 한 일은 순서가 분명했다.

4번의 결과가 결정적이었다. 요구 항목 34개 중 27개는 이미 있었고 (이름만 달랐다), 빈 것은 7개였다.

"수백 쪽 공부" 가 "7개 항목 채우기" 로 줄었다. Part 2와 Part 4는 이번에 펼치지 않아도 됐다 — 요구된 것이 문서였기 때문이다.

여기서 남는 교훈이 둘이다. 첫째, 요구된 것이 무엇인지부터 좁힌다. "29119 준수" 라는 말은 넓지만, 실제로 제출할 것은 문서 세 개였다. 둘째, 대조표를 그리면 공백이 숫자로 보인다. 막막함의 대부분은 무엇이 없는지 모르는 상태에서 온다.

실무에서 왜 필요한가

표준 문서를 실무에서 참조할 때, "지금 내가 찾는 정보가 어느 파트에 있을까"를 아는 것만으로도 검색 시간이 크게 줄어든다. 예를 들어 "테스트 계획서에 뭘 넣어야 하지?"라는 질문이면 Part 3을, "우리 조직 전체의 테스트 정책은 어떻게 정의하지?"라는 질문이면 Part 2를 찾아야 한다. 구조를 모르면 방대한 문서 전체를 뒤지게 된다.

공부할 범위를 좁히는 것이 첫 성과다

표준을 요구받은 팀이 가장 먼저 겪는 것은 막막함이다. 그런데 그 막막함은 표준이 어려워서가 아니라 요구된 범위를 모르기 때문에 온다.

이 좁히기를 할 수 있는 사람이 QA다. 개발·기획은 산출물 요구가 무엇을 뜻하는지 모르고, 문서 요구를 해석하는 것이 QA의 일이다.

이미 가진 것을 세는 쪽이 빠르다

두 번째 성과는 대조표다. 모듈 4·6·7을 익힌 팀이라면 표준이 요구하는 항목의 대부분이 이미 있고 이름만 다르다. 그때 할 일은 공부가 아니라 번역과 빈칸 채우기다.

이 순서가 중요한 이유가 있다. "없는 것부터 찾으면" 표준이 적대적으로 보이고, "있는 것부터 세면" 할 만해 보인다. 팀의 저항을 줄이는 데 이 차이가 크다.

채용시장에서의 위치

구조를 아는 것은 면접에서 깊이의 신호로 쓰인다. 표준 이름만 아는 사람과 어디에 무엇이 있는지 아는 사람의 답이 분명히 다르다.

세 번째가 가장 변별력이 크다. "처음부터 읽었다" 는 답은 실제로 해 본 사람의 답이 아니다. 표준은 참조 문서이고, 참조 문서를 읽는 방식은 찾아 펼치는 것이다.

다섯 번째는 계약·심사를 겪어 본 사람만 하는 답이다. 버전 고정은 사소해 보이지만 분쟁을 막는 한 줄이다.

공고 표현으로는 "ISO 29119", "테스트 산출물 표준화", "품질 문서 체계" 가 이 레슨에 걸린다. 그리고 다음 레슨들(3~6)이 Part 2·3의 내용을 하나씩 풀어 간다.

실습 과제

과제 1 — 질문을 파트에 배정하기 (10분)

다음 네 가지 질문이 각각 Part 1~4 중 어디에서 답을 찾을 수 있을지 배정한다.

1. "테스트 완료 보고서에 반드시 포함해야 할 항목은 무엇인가?"
2. "'테스트 시나리오'와 '테스트 케이스'는 표준상 어떻게 다르게 정의되는가?"
3. "경계값 분석 기법을 표준은 어떻게 설명하는가?"
4. "테스트 관리자가 프로젝트 테스트 계획 단계에서 해야 할 활동은 무엇인가?"

과제 2 — 이미 배운 내용과 연결하기 (5분)

이 강의의 모듈 3(테스트 설계 기법)과 모듈 4(테스트 계획)가 각각 Part 2~4 중 어느 파트와 가장 관련이 깊을지 적어본다.

과제 3 — 요구를 파트로 좁히기 (12분)

고객사 요구 문구가 아래와 같다. 각각 어느 파트를 펼쳐야 하는지와 펼치지 않아도 되는 파트를 적는다.

1. "테스트 계획서와 완료 보고서를 29119 형식으로 제출할 것"
2. "조직의 테스트 정책 문서를 제출하고, 그 정책이 프로젝트 계획에 반영됐음을 설명할 것"
3. "적용한 테스트 설계 기법을 표준 용어로 명시할 것"
4. "본 사업에서 쓰는 테스트 용어의 정의를 부속서로 첨부할 것"

자가 체크리스트

• Part 1~4가 각각 무엇을 다루는지 한 문장으로 설명할 수 있다
• "이 질문의 답은 어느 파트에 있을까"를 판단할 수 있다
• 이 강의에서 이미 배운 내용(설계 기법, 테스트 계획)이 표준의 어느 파트와 연결되는지 설명할 수 있다
• 시리즈가 Part 5·29119-11 까지 있다는 것과 각각의 쓸모를 안다
• 표준을 인용할 때 번호와 개정 연도를 함께 적는 이유를 설명할 수 있다
• Part 1의 실무 쓸모가 용어 분쟁 해결임을 설명할 수 있다
• Part 2의 세 계층 포함 관계를 그릴 수 있다
• 프로세스가 문서를 낳는다는 Part 2·3의 관계를 설명할 수 있다
• 모듈 3의 기법 이름을 표준 용어로 대응시킬 수 있다
• 표준도 경험 기반 기법을 포함한다는 것과 그 기록 요구를 안다
• 무슨 문서 3 · 무슨 활동 2 · 무슨 뜻 1 · 어떻게 설계 4 규칙을 쓸 수 있다
• 표준 문서를 구해 보는 네 경로와 그 한계를 안다
• 요구 문구를 읽고 펼치지 않아도 되는 파트를 지울 수 있다
• "있는 것부터 세는" 순서가 팀의 저항을 줄이는 이유를 설명할 수 있다

흔한 실수

• 표준 전체를 처음부터 순서대로 다 읽으려 한다. 필요한 파트만 찾아 참조하는 게 실무에서 훨씬 효율적이다.
• Part 4(테스트 기법)를 모듈 3과 완전히 다른 새로운 내용이라고 생각한다. 대부분 이미 배운 기법을 표준 용어로 재정의한 것이다.
• Part 2와 Part 3을 혼동한다. Part 2는 "프로세스"(누가 언제 무엇을), Part 3은 "문서"(그 결과물을 어떤 형식으로 남기는가)로 역할이 다르다.
• "29119 준수"라는 넓은 말을 그대로 받는다. 산출물 형식만 뜻하는지 프로세스 정의까지인지 되물어야 공부 범위가 정해진다.
• 버전을 적지 않고 "29119"로만 인용한다. 개정판에서 항목 구성이 바뀌어 심사에서 서로 다르게 읽힌다. 착수 때 버전을 고정한다.
• 없는 것부터 찾는다. 표준이 적대적으로 보인다. 있는 것부터 세면 할 만해 보이고, 대개 대부분이 이미 있다.
• 요약 자료만 보고 "준수했다"고 말한다. 심사 대상이면 원문의 항목 번호를 대조해야 한다.
• 표준이 탐색적 테스팅을 배제한다고 생각한다. Part 4에 경험 기반 기법이 포함되어 있고, 요구되는 것은 기록 방법이다.
• Part 1을 "처음 한 번 읽는 것"으로만 쓴다. 실제 쓸모는 용어 분쟁이 생겼을 때 제3의 기준으로 꺼내는 것이다.

참고 자료

• ISO/IEC/IEEE 29119 시리즈 공식 목록 — Part 1~5까지 각 파트의 공식 범위
• ISTQB Glossary — Test Documentation — Part 3 관련 용어의 공식 정의
• e나라 표준인증 — 한국산업표준으로 채택된 표준의 열람 경로
• ISO/IEC/IEEE 29119-3 공식 페이지 — 문서 템플릿 부의 범위와 목차 미리보기

이 커리큘럼 안에서

• 모듈 8 레슨 1 — 표준이 필요한 이유. 버전 고정과 착수 시 형식 확인
• 모듈 8 레슨 3~5 — Part 2의 세 계층(조직·관리·동적)을 하나씩
• 모듈 8 레슨 6 — Part 3 템플릿 실물 따라가기
• 모듈 8 레슨 7 — IEEE 829 등 이전 표준과 29119의 관계
• 모듈 1 — 기본 개념·용어. Part 1에 대응
• 모듈 3 — 설계 기법. Part 4와 거의 일대일
• 모듈 4 — 계획·리스크·종료 조건. Part 2 + Part 3
• 모듈 5 레슨 11 — 세션 노트. 경험 기반 기법의 기록 방법
• 모듈 6 — 결함 보고·완료 보고. Part 3 산출물
• 모듈 7 — 도구·환경·조직. Part 2의 환경 구성·조직 프로세스

한 줄 정리 — 표준은 참조 문서이고, 참조 문서는 찾아 펼치는 것이다. 규칙 하나면 된다 — 무슨 문서는 Part 3, 무슨 활동은 Part 2, 무슨 뜻은 Part 1, 어떻게 설계는 Part 4. 그리고 공부를 시작하기 전에 요구된 것을 좁히고 이미 가진 것을 세면, 수백 쪽이 빈칸 몇 개로 줄어든다.