개념
3계층 프로세스와 산출물 — 이 표 하나가 3과목의 뼈대다
29119-2는 테스트 프로세스를 세 층으로 나눈다. 활동 이름과 산출물을 짝지어 외운다.
| 프로세스 | 활동 | 산출물 |
|---|---|---|
| 조직 테스트 | 조직 테스트 명세 개발 → 활용 모니터링 및 제어 → 갱신 | 조직 테스트 정책 명세서, 조직 테스트 전략 명세서 |
| 테스트 관리 | 테스트 계획 | 테스트 계획서 |
| 테스트 모니터링 및 제어 | 테스트 현황 보고서 | |
| 테스트 종료 | 테스트 종료 보고서 | |
| 동적 테스트 | 테스트 설계 및 구현 | 테스트 설계 명세서, 테스트 케이스 명세서, 테스트 절차 명세서, 테스트 환경 요건 명세서, 테스트 데이터 요건 명세서 |
| 테스트 환경 구축 및 관리 | 테스트 환경 준비 보고서, 테스트 데이터 준비 보고서 | |
| 테스트 실행 | 테스트 실행 로그 | |
| 결함 보고 | 결함 보고서, 결함 추적 보고서 |
조직 테스트 프로세스는 특정 프로젝트가 아니라 조직 전체 에 공통 적용된다. 정책은 "왜·무엇을" (테스트 목적·원칙), 전략은 "어떻게"(공통 기법·완료 기준·문서 수준)다. 프로젝트 성과로 조직 명세를 갱신하는 고리까지 기억한다.
시험 함정 두 가지. "테스트 프로세스는 개발 프로세스가 끝난 뒤 시작하고, 한 번 정한 프로세스는 바꾸지 않는다"(X — 개발과 병행하고 지속 개선한다). "테스트 프로세스 자체의 효율 향상과 개선이 목적인 활동"은 별도로 묻는다 — 조직 테스트 명세 갱신 과 종료 단계의 교훈 이 그 역할이다.
테스트 계획 — 컨텍스트·위험·전략
① 테스트 컨텍스트 — 계획 유형(프로젝트 테스트 계획 / 레벨·유형별 개별 테스트 계획), 테스트 대상, 테스트 범위(포함·제외 피처), 가정 및 제약사항, 이해관계자.
② 위험 분석 — 위험 요소마다 발생 가능성(L, Likelihood)과 영향도(I, Impact)를 곱해 위험도 (E, Exposure)를 구한다.
| 위험 요소 | L | I | E = L × I | 조치(완화) |
|---|---|---|---|---|
| 인력 부족 | 2 | 4 | 8 | 일정 보수 산정, 일정 엄수, 현황 보고 빈도 증가 |
| 기술·경험 부족 | 2 | 3 | 6 | 훈련 계획, 미숙련 산출물 검토 시간 확보 |
위험은 두 종류다.
| 구분 | 뜻 | 예 |
|---|---|---|
| 프로젝트 위험 | 테스트 수행 에 관한 위험 — 조직·인력·비용·일정 | 인력 부족, 예산 부족, 환경 지연 |
| 제품 위험 | 제품이 목표 품질을 못 낼 위험 — 기능·비기능 | 결제 누락, 응답 지연, 개인정보 유출 |
조치는 네 가지 이름으로 묻는다.
| 조치 | 뜻 | 예 |
|---|---|---|
| 회피 | 원인을 제거해 발생 자체를 막는다 | 위험한 신기술 대신 검증된 기술 사용 |
| 완화 | 발생 가능성이나 영향을 낮춘다 | 조기 테스트, 강한 기법, 높은 완료 기준 |
| 수용 | 비용이 너무 커서 감수한다 | 저위험 피처는 테스트 범위에서 제외 |
| 전가 | 다른 조직·방법으로 넘긴다 | 보안 테스트 아웃소싱, 정형 방법·V&V 분석 |
위험이 실제로 터졌을 때를 위한 비상 계획(Contingency plan) 도 따로 세운다. 고위험 제품 피처는 반드시 범위에 넣고 컴포넌트 레벨부터, 더 강한 설계 기법으로, 더 엄격한 완료 기준을 건다.
③ 테스트 전략 항목 — 개별 테스트(레벨·유형 구성), 테스트 산출물, 설계 기법, 테스트 환경, 테스트 데이터 요건, 재테스팅·리그레션, 중단 및 재시작 조건, 테스트 메트릭, 완료 기준.
중단·재시작 조건의 예:
| 중단 조건 | 재시작 조건 |
|---|---|
| 테스트 실패율이 과도할 때(예: 50% 이상) | 관련 결함 해결 후 해당 테스트 전체 재시작 |
| 기본 시나리오 실패 시 대안 시나리오 중단 | 기본 시나리오 결함 해결 후 해당 유즈케이스 전체 재시작 |
| 환경 문제로 실행 실패 시 같은 환경의 모든 테스트 중단 | 환경 복구 후 같은 환경의 모든 테스트 재시작 |
완료 기준은 수치로 적는다 — 예: 문장 커버리지 80% 이상, 심각도 1 결함 0건, 계획 TC 실행률 100%, 통과율 95% 이상.
테스트 설계 및 구현 — 피처에서 절차까지
| 단계 | 하는 일 | 산출물 |
|---|---|---|
| 피처 집합 식별 | 범위의 피처를 논리 묶음으로, 위험 고려해 우선순위 | 테스트 설계 명세서 |
| 피처 구체화 | 피처를 세부 피처로 쪼갠다 | 〃 |
| 테스트 전략 구체화 | 피처 집합별 기법·완료 기준 확정 | 〃 |
| 테스트 케이스 개발 | 기법을 적용해 TC 도출(목적·우선순위·입력·예상 결과) | 테스트 케이스 명세서 |
| 테스트 절차 개발 | TC를 실행 순서로 묶음(시작 작업·TC 목록·종료 작업) | 테스트 절차 명세서 |
| 환경·데이터 요건 명세 | 필요한 HW·SW·도구·데이터 | 환경 요건 명세서, 데이터 요건 명세서 |
이어서 환경 구축 및 관리 에서 데이터를 준비하고 환경을 세운 뒤 준비 보고서를 남긴다.
테스트 실행 — 선정·실행·비교·기록
테스트 절차 선정 → 실행 → 실제 결과와 예상 결과 비교 → 실행 로그 기록(시간순, 시간–작업–관련 결함 ID). 불일치가 나오면 바로 결함으로 등록하지 않고 먼저 분석 한다.
| 분석 단계 | 하는 일 | 예 |
|---|---|---|
| 구체화 | 재현 가능한 입력·절차·환경을 명확히 | "가끔 실패" → "재고 0인 상품을 장바구니 담기 후 결제" |
| 고립화(Isolation) | 결함과 무관한 요소를 제거 해 최소 재현 조건을 찾는다 | 쿠폰·배송지·브라우저는 무관, 재고 0만 필요 |
| 일반화 | 유사 조건으로 확장해 영향 범위 를 파악한다 | 재고 0인 모든 옵션 상품에서도 동일 |
O/X 함정: "고립화란 결함 발견 시 사용한 데이터·절차·환경을 바꿔 가며 결함의 영향 범위 를 넓히는 것이다"(X — 그것은 일반화).
결함 생명 주기 — 상태와 Verified 이후
Open → Review ─┬─▶ Assigned → Resolved → Verified → Closed
│ (Fixed / Duplicated / Won't Fix / Invalid)
├─▶ Deferred ──(차기 릴리스)──▶ Reopen → Assigned …
└─▶ Closed (경미해서 무시)
Verified 결과가 부정확하면 → Reopen
| 상태 | 뜻 |
|---|---|
| Open | 구체화·고립화·일반화를 거쳐 결함 보고서로 등록, 추적 시작 |
| Review | 위험(발생 가능성·심각성·긴급성)으로 처리 방침 결정 — 이번 수정(Assigned)·연기(Deferred)·무시(Closed) |
| Deferred | 다음 릴리스에서 해결하기로 연기 — 적절한 시점에 Reopen |
| Assigned | 수정 담당 개발자가 정해짐 |
| Resolved | 개발자의 처리 결과만 제시된 상태(아직 검증 전) |
| Verified | 처리가 합당·정확한지 검증됨 |
| Closed | 종결 |
| Reopen | 다시 처리 시작 |
Verified 이후 상태 는 표로 외운다 — Won't Fix만 다르다.
| Resolved 유형 | 검증 결과 정확 | 부정확 |
|---|---|---|
| Fixed(수정함) | Closed | Reopen |
| Duplicated(중복) | Closed | Reopen |
| Won't Fix(수정 안 함) | Deferred | Reopen |
| Invalid(결함 아님) | Closed | Reopen |
Fixed의 검증은 재테스팅, Duplicated는 원 결함과 같은지와 원 결함이 처리되었는지, Won't Fix는 테스트 관리자 가 정말 중요·긴급하지 않은지, Invalid는 보고 자체(TC·절차)에 문제가 있는지를 본다.
Jira 워크플로에 대응시키기
실무 도구는 이름이 다르다. 팀 워크플로를 설계할 때 대응표를 먼저 만든다(Jira는 2025년부터 "이슈"를 업무 항목(work item) 으로 부르기 시작했다).
| CSTS 상태 | Jira 예시 상태 | 비고 |
|---|---|---|
| Open | To Do | 결함 유형 업무 항목 생성 |
| Review | In Review(트리아지) | 기본 워크플로에 없으면 추가 |
| Assigned | In Progress | 담당자 지정 |
| Resolved | Done + 해결(Resolution) 필드 | Fixed·Duplicate·Won't Do·Cannot Reproduce |
| Verified | QA Done(검증 완료) | 사용자 정의 상태 |
| Closed | Closed | |
| Deferred | Backlog | 수정 버전(Fix Version) 지정 |
모니터링·제어와 현황 보고
모니터링은 계획 대비 진척과 메트릭을 측정하고, 제어는 그 결과로 조치(인력 재배치, 범위 조정, 일정 변경, 리스크 대응)를 한다. 대표 메트릭은 결함 추세(발견·수정 속도 → 안정 시점 예측), 진척률(TC 실행률·통과율), 커버리지(구조·요구 커버리지 → 완료 기준 판정), 결함 나이 (장기 미해결 경보), 결함 누적 곡선(Open·Resolved·Closed 간격으로 병목 탐지), 위험 번다운.
테스트 현황 보고서 항목: 보고 대상 기간, 계획 대비 진척도(지연 원인·영향·해소 방안), 테스트 메트릭, 신규 및 변경 위험, 이후 테스트 계획(지연 요인 조치, 새 위험의 회피·완화·전가·수용 계획).
테스트 종료
종료 활동은 테스트 자산 관리(재사용할 TC·스크립트·데이터 보관), 테스트 환경 정리, 종료 보고 다. 테스트 종료 보고서(테스트 보고서·테스트 요약 보고서라고도 한다) 항목:
- 테스트 요약(대상, 환경, 관련 문서, 전반적 결과)
- 계획 대비 차이점과 그 이유
- 테스트 메트릭
- 테스트 방해 요인
- 잔존 위험
- 테스트 완료 평가(완료 기준 충족 여부)
- 테스트 산출물
- 재사용 가능한 테스트 자산
- 교훈
실무에서 왜 필요한가
공공·금융 SI의 산출물 목록은 29119(또는 그 전신인 IEEE 829) 이름을 거의 그대로 쓴다. 발주처가 "테스트 절차 명세서와 테스트 실행 로그를 제출하라"고 할 때 두 문서의 차이를 모르면 같은 엑셀을 두 번 내게 된다. 위험 분석 표(L × I)는 테스트 범위를 줄여야 할 때 무엇을 왜 뺐는지 를 남기는 유일한 근거이고, 종료 보고서의 잔존 위험 항목이 그 기록을 이어받는다(s2-m04-l02, s2-m31 모듈).
결함 상태의 Won't Fix → Deferred 규칙은 실무에서 가장 자주 무너진다. "수정 안 함"으로 닫힌 결함이 차기 릴리스 백로그로 가지 않으면 그대로 사라지고, 운영에서 다시 신고된다. 워크플로에 이 전이를 강제해 두는 것만으로 결함 누락이 준다.