결과·결함·커버리지·종료기준 관리
1,000개 케이스 중 980개가 통과했다고 하자. 실패한 20개가 모두 화면 정렬 문제인 경우와 그중 하나가 결제 중복이나 개인정보 노출인 경우는 같은 98%라도 의미가 완전히 다르다.
1. 테스트 통과율 98%면 출시해도 될까
1,000개 케이스 중 980개가 통과했다고 하자. 실패한 20개가 모두 화면 정렬 문제인 경우와 그중 하나가 결제 중복이나 개인정보 노출인 경우는 같은 98%라도 의미가 완전히 다르다.
이번 절은 결과를 단순 통과율로 줄이지 않고 결함의 상태·커버리지의 분모·잔여위험·종료기준을 연결하여 출시·보류·추가시험 판단으로 바꾼다.
기획한 위험과 자동화 결과를 같은 추적선 위에 놓는다
측정값·지표·목표·기준선에서는 측정값·지표·목표·기준선을 같은 분자·분모·단위·대상·기간과 비교규칙으로 정의해야 변화 판단이 재현된다고 배웠다. 테스트 기획·계획·분석·설계는 위험·조건·케이스를 설계했고, 단위·통합·시스템·인수와 기능·비기능 시험은 시험수준과 오라클을, 테스트 자동화·CI·환경·데이터는 CI·환경·데이터와 자동화 결과를 다뤘다. 결과관리는 같은 기준선과 분모를 유지하면서 이 증거를 원래 위험과 요구에 다시 연결한다.
테스트 결과관리
테스트 결과관리는 실행결과·결함·커버리지·미실행 범위와 잔여위험을 함께 해석하여 추가시험·수정·예외승인·출시 여부를 결정하고 그 근거를 추적 가능하게 남기는 활동이다.
통과율, 결함 건수, 커버리지 수치는 판단의 입력이며 그 자체가 제품 품질이나 출시 승인을 뜻하지 않는다.
실행결과를 출시판단으로 바꾸는 흐름
화살표의 방향과 조건을 따라 연결을 읽습니다.
선은 근거와 해석의 연결이다. 커버리지·통과율·결함·미실행의 평균을 낸 품질점수가 아니다. 종료조건과 잔여위험에 따른 권고를 남기되 사람의 최종 출시 승인과 구별한다.
결과는 반드시 어떤 요구와 위험을 검증했는지 되짚을 수 있어야 한다.
2. 실행결과는 통과·실패 외에 미실행·차단·불확실을 구분한다
환경 장애로 실행하지 못한 케이스, 선행 결함 때문에 차단된 케이스, 오라클이 불충분해 판정하지 못한 케이스를 실패나 통과에 섞지 않는다. 분모가 달라지면 통과율의 의미도 달라진다.
RM-1: 100개 중 90 통과, 5 실패, 5 미실행
전체 계획 100개를 분모로 하면 통과 90%, 실패 5%, 미실행 5%다. 실행된 95개만 분모로 통과율을 계산하면 약 94.7%가 된다. 두 수치 중 하나를 선택해 미실행 5개를 숨기지 않고 분모와 사유를 함께 보고한다.
‘미실행’을 성공으로 간주하지 않는다
장비가 없어 성능시험을 못 했거나 외부기관 계정이 없어 인수시나리오가 차단되었다면 품질증거가 없는 것이다. 일정이 끝났다는 이유로 미실행을 통과로 바꾸지 않는다.
3. 결함 건수보다 영향·재현성·노출범위·복구가능성을 본다
결함은 증상, 재현조건, 기대/실제 결과, 영향범위, 심각도, 우선순위, 상태, 수정판본과 재시험 결과를 연결한다. 심각도는 제품 영향, 우선순위는 언제 처리할지의 의사결정이므로 같은 값이 아닐 수 있다.
심각도와 우선순위를 구분한다
| 사례 | 심각도 | 우선순위 판단 |
|---|---|---|
| 드물지만 개인정보 영구노출 | 매우 높음 | 즉시 차단 가능 |
| 자주 보이는 문구 오탈자 | 낮음 | 릴리스 전 묶음 수정 가능 |
| 테스트환경에서만 재현되는 데이터손상 | 조사 필요 | 환경차이 확인 후 결정 |
등급 이름보다 판단근거와 잔여위험을 남긴다.
결함 상태는 워크플로이며 삭제기록이 아니다
개발자가 수정한 상태와 재시험 후 종료를 구별한다 · 상태 따라가기
발견한 결함을 분석하여 수정할 범위를 정한다. 모든 단계에서 결함 상태·종료 근거의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
화살표의 방향과 조건을 따라 연결을 읽습니다.
한 조직이 사용할 수 있는 부분 워크플로 예다. 수정됨과 종료의 완료 근거가 다르다. 중복 신고를 닫아도 원래 위험·영향이 사라지는 것은 아니며 재개방·예외 경로는 조직 계약으로 확인한다.
이 예의 조건
- 결함이 신규·분석·수정 중·수정됨·재시험·종료의 예시 상태를 따르되 수정됨은 개발 변경, 종료는 합의한 재시험과 영향 확인 완료를 뜻한다.
- 신규→분석→수정 중→수정됨→재시험→종료의 부분 워크플로다. 조사 시작·수정 착수·개발 변경·확인 실행·확인 완료의 전이 조건을 각각 보존한다. 수정됨은 개발 변경이고 종료는 합의한 재시험과 영향 확인의 완료이며 전체 생애 모델이 아니다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 신규·분석 발견한 결함을 분석하여 수정할 범위를 정한다. |
|
|
| 수정 중 승인한 범위를 수정하며 아직 검증이 끝나지 않았다. |
|
|
| 수정됨 수정 보고가 있어도 재시험을 기다린다. |
|
|
| 재시험·종료 재시험 조건과 관련 영향을 확인한 뒤에만 종료한다. |
|
|
개발자가 수정한 상태와 재시험 후 종료를 구별한다 · 상태 따라가기
발견한 결함을 분석하여 수정할 범위를 정한다. 모든 단계에서 결함 상태·종료 근거의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
화살표의 방향과 조건을 따라 연결을 읽습니다.
한 조직이 사용할 수 있는 부분 워크플로 예다. 수정됨과 종료의 완료 근거가 다르다. 중복 신고를 닫아도 원래 위험·영향이 사라지는 것은 아니며 재개방·예외 경로는 조직 계약으로 확인한다.
이 예의 조건
- 결함이 신규·분석·수정 중·수정됨·재시험·종료의 예시 상태를 따르되 수정됨은 개발 변경, 종료는 합의한 재시험과 영향 확인 완료를 뜻한다.
- 신규→분석→수정 중→수정됨→재시험→종료의 부분 워크플로다. 조사 시작·수정 착수·개발 변경·확인 실행·확인 완료의 전이 조건을 각각 보존한다. 수정됨은 개발 변경이고 종료는 합의한 재시험과 영향 확인의 완료이며 전체 생애 모델이 아니다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 신규·분석 발견한 결함을 분석하여 수정할 범위를 정한다. |
|
|
| 수정 중 승인한 범위를 수정하며 아직 검증이 끝나지 않았다. |
|
|
| 수정됨 수정 보고가 있어도 재시험을 기다린다. |
|
|
| 재시험·종료 재시험 조건과 관련 영향을 확인한 뒤에만 종료한다. |
|
|
중복결함을 닫아도 원래 위험은 사라지지 않는다
같은 원인의 신고 10건을 하나로 병합하면 결함 건수는 줄지만 영향받은 사용자·경로가 줄었다는 뜻은 아니다. 중복관계와 영향범위를 보존한다.
4. 커버리지의 분모에는 반드시 이름을 붙인다
요구 커버리지, 위험 커버리지, 코드 커버리지, 상태·전이 커버리지, 자동화 커버리지는 서로 다른 질문이다. 80%라는 숫자만 보고 무엇의 80%인지 알 수 없으면 출시근거로 쓰기 어렵다.
CV-1: 요구 10개 중 10개 연결과 코드 80%는 다른 증거다
요구 10개 모두 테스트가 연결되어 요구 추적 커버리지가 100%여도 각 케이스가 얕거나 실패했을 수 있다. 반대로 코드 라인 80%가 실행되어도 핵심 업무요구·보안위험을 검증했다는 뜻은 아니다. 분모와 판정결과를 함께 읽는다.
커버리지 목표를 채우기 위해 의미 없는 테스트를 추가하지 않는다
숫자만 올리기 위한 단순 getter 호출이나 결과를 검증하지 않는 케이스는 실행범위만 늘리고 오류 탐지력은 거의 주지 않을 수 있다. 미커버 영역의 위험과 이유를 먼저 본다.
5. 잔여위험은 ‘아직 틀릴 수 있는 곳’을 명시하는 목록이다
미해결 결함, 미실행 시험, 낮은 커버리지, 실제와 다른 환경, 외부의존성, 불확실한 오라클을 출시 후 영향과 연결한다. 잔여위험이 0이라고 쓰려면 근거가 필요하며, 모른다는 사실은 0이 아니다.
RR-1: 모두 통과했지만 실제 결제망 장애를 시험하지 못했다
가상 테스트환경에서 500개 자동시험이 모두 통과했어도 외부 결제사의 지연·부분실패를 재현하지 못했다면 해당 회복성 위험은 남아 있다. 출시판단에는 ‘자동시험 100% 통과’와 ‘외부망 장애 검증 미완료’를 동시에 적는다.
6. 종료기준은 확인 근거와 위험 수용 조건을 정한다
핵심 위험 케이스 통과, 특정 심각도 이상의 미해결 결함 0건, 요구·위험 커버리지 기준, 필수 비기능 시험 완료, 미실행 범위 승인처럼 조건을 사전에 정한다. 조건을 충족하지 못하면 추가시험·수정·예외승인 중 무엇을 할지 결정한다. 시간·예산의 한계도 합의한 종료조건에 포함될 수 있지만, 이해관계자의 잔여위험 검토·수용 없이 시험 통과로 바뀌지는 않는다. 이 절의 RM-2는 다음 네 증거 조건과 별도의 운영 예외를 둔 사례다.
RM-2: 종료기준은 지표의 평균을 내지 않고 조건별로 판정한다
자체 결제서비스 release 후보에 계획한 테스트가 1,000건이고 결과가 통과 930건, 실패 20건, 미실행 50건이라고 하자. 계획 전체를 분모로 하면 통과 93%, 실패 2%, 미실행 5%이고 실행률은 (930+20)/1000=950/1000=95%다. 실행된 950건만 분모로 한 통과율은 930/950≈97.89%다. 97.89%라는 값으로 미실행 50건을 없애지 않는다.
요구 추적 커버리지 95%는 교육용으로 요구 200개 중 190개에 검증증거가 연결되고 10개가 미연결인 상태라고 두자. 코드 라인 커버리지 82%는 별도 관찰값이며 두 비율의 평균을 내어 (95+82)/2=88.5% 같은 종합 품질점수를 만들지 않는다.
이 release 후보의 사전 종료기준을 다음 네 조건으로 정했다고 가정한다. 코드 커버리지 82%는 위험 검토 자료이지만 이 예의 종료기준에는 넣지 않았다.
| 종료조건 | 기준 | 현재 증거 | 판정 |
|---|---|---|---|
| 계획 케이스 실행률 | 98% 이상 | 950/1000=95% | 미충족 |
| 미해결 고위험 결함 | 0건 | 1건 | 미충족 |
| 요구 추적 커버리지 | 98% 이상 | 190/200=95% | 미충족 |
| 필수 외부 결제망 회복성시험 | 완료 | 미실행 | 미충족 |
네 조건은 서로 다른 위험을 보므로 하나의 높은 수치로 다른 실패를 상쇄하지 않는다. 현재는 종료기준 미충족이며 기본 경로는 고위험 결함 수정·재시험, 미실행 케이스 수행, 미연결 요구 보강, 외부 결제망 회복성시험 수행이다.
사업상 예외가 필요하면 “테스트 통과”로 바꾸는 대신 종료기준 미충족 상태와 잔여위험을 유지한 채 별도 권한자가 노출범위, 모니터링, 즉시 롤백 기준, 보완시험 기한과 만료를 승인하는 예외 경로로 기록한다. 예외승인은 품질증거가 생겼다는 뜻이 아니다. 반대로 네 종료조건을 모두 충족해도 테스트 종료 근거가 갖춰진 것이며 법적·운영·사업 판단을 포함한 최종 release 승인이 자동으로 끝나는 것은 아니다.
종료조건과 출시판단은 연결되지만 동일하지 않다
종료기준을 만족했다고 자동 출시되는 것은 아니다. 사업일정, 법적 의무, 외부변경, 운영준비 같은 별도 의사결정이 남을 수 있다. 반대로 종료기준 미충족을 단순 일정압박으로 무시하지 않고 예외의 위험·승인자·보완책을 기록한다.
7. 결함 추세는 건수의 방향보다 발견·수정·재개방 흐름을 본다
기간별 신규·수정·종료·재개방 결함, 심각도 분포, 오래 열린 결함을 본다. 신규 결함 감소가 품질향상일 수도 있지만 테스트 범위 축소나 실행량 감소 때문일 수도 있으므로 분모와 함께 해석한다.
TR-1: 신규 결함 20→10이 좋아졌다고 단정하지 않는다
1주차 1,000개 케이스에서 신규 결함 20건, 2주차 300개 케이스에서 10건이 발견되었다고 하자. 절대 건수는 줄었지만 실행량도 크게 줄었다. 동일 조건의 추세인지, 위험범위가 바뀌었는지 확인해야 한다.
8. 결과보고서는 숫자보다 의사결정 가능한 구조를 갖춘다
판본·범위·환경, 실행결과, 핵심 실패, 결함상태, 커버리지 분모, 미실행·차단, 잔여위험, 종료기준 충족 여부, 권고조치를 한 묶음으로 보고한다. 독자는 어떤 증거가 없고 무엇을 승인해야 하는지 알 수 있어야 한다.
출시 권고는 조건부 문장으로 쓴다
예를 들어 “핵심 결제·권한 회귀는 통과했으나 외부 결제망 장애시험이 미완료이므로 트래픽 10% 제한과 즉시 롤백 조건으로 출시 후보”처럼 증거·남은 위험·보완책을 연결한다. 실제 출시승인은 권한 있는 사람이 별도로 한다.
공식 범위 연결 — IT테스트 결과 관리
실행결과·결함·커버리지·미실행·잔여위험과 종료기준을 하나의 판단근거로 묶어 추가시험·수정·예외·출시 권고를 관리한다.
출처와 적용 경계
ISTQB와 CTFL 저자들의 Foundation Level Syllabus v4.0.1 §5.1.3·5.3.2·5.5의 종료조건·결과보고·결함기록을 대조했다(2024-09-15 판본, 확인 2026-10-06). 통과율·결함·실행량·트래픽 제한 수치는 교육용 자체 예시이며 실제 제품의 release 판단이나 사람 승인을 나타내지 않는다. RM-2의 요구 200개, 실행률 98%, 요구 커버리지 98%, 고위험 0건과 필수 회복성시험 완료 조건도 종료기준 판정 학습을 위한 자체 가정이며 특정 조직의 실제 release 기준이 아니다.
9. 한 장으로 정리하기
- 통과·실패·미실행·차단·불확실의 분모를 구분한다.
- 결함 건수보다 영향·재현성·상태·재시험을 추적한다.
- 커버리지에는 요구·위험·코드·상태 등 분모 이름이 필요하다.
- 미실행·환경차이·미해결 결함을 잔여위험으로 남긴다.
- 종료기준은 합의한 증거·위험·시간·예산 조건이며, 일정 종료를 시험 통과로 바꾸지 않는다.
- 결과보고서는 증거·공백·위험·권고조치를 연결한다.
독립 연습 — 실행률을 올린 뒤에도 남은 관문을 읽는다
다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.
RM-2의 계획 1,000 건 중 990 건을 실행했다. 고위험 결함은 0 건, 200 개 요구 중 199 개에 검증 증거가 연결되어 있다. 필수 외부 결제의 회복 시험 케이스는 미실행이다. 운영자가 한시적으로 트래픽 10%·즉시 롤백·3 일 내 보완을 조건으로 운영 예외를 승인했다고 가정한다.
- 각 지표와 필수 관문을 나누어 판정하라.
- 예외 승인과 필수 시험의 상태를 섞지 않고 보고하는 문장을 쓰라.
풀이와 오답 교정 보기
실행률 990/1000=99%는 98% 이상, 고위험 0 건은 충족, 요구 추적 커버리지 199/200=99.5%는 98% 이상이다. 필수 회복 시험 완료 관문은 미충족이다. 따라서 실행률을 넘겼어도 전체 정규 종료로 보고하지 않는다. “필수 외부 결제 회복 케이스는 미실행이며 제한 운영 예외가 승인됐다”처럼 운영 예외와 시험 상태를 분리한다. 예외가 승인됐다고 미실행 결과가 PASS로 바뀌지는 않는다.
10. 자체 10점 문제
IT테스트 결과관리에서 통과율, 결함, 커버리지, 잔여위험과 종료기준을 함께 관리해야 하는 이유를 설명하시오.
요구어는 설명이다. 각 숫자의 분모와 출시판단까지의 연결을 보여준다.
10점 풀이와 답안 구성 보기
10점 답안 목차
- 테스트 결과관리 정의
- 실행결과 분모와 미실행
- 결함 심각도·상태·재시험
- 커버리지 분모
- 잔여위험
- 종료기준과 출시 권고
10점 답안 도식
증거와 잔여위험 그림을 다시 사용한다. 결과 + 결함 + 커버리지 + 미실행을 잔여위험으로 연결하고 종료기준에 따라 추가시험 / 출시권고를 판단한다.
10점 모범답안
테스트 결과관리는 실행결과·결함·커버리지·미실행과 잔여위험을 함께 해석하여 다음 행동과 출시권고를 정하는 활동이다. 통과율은 계획 전체인지 실제 실행분인지 분모를 명시하고 미실행·차단을 숨기지 않는다. 결함은 건수뿐 아니라 영향·심각도·상태·수정판본·재시험을 추적한다. 커버리지는 요구·위험·코드·상태처럼 무엇의 비율인지 분모에 이름을 붙인다. 이 증거에서 미해결 결함·미실행·환경차이를 잔여위험으로 정리하고, 사전에 합의한 종료기준 충족 여부에 따라 추가시험·수정·예외승인·출시권고를 결정한다. 종료기준 충족이나 자동화 통과가 사람의 최종 출시승인을 대신하지 않는다.
11. 자체 25점 문제
결제서비스 release 후보의 테스트 결과가 계획 1,000건 중 930 통과, 20 실패, 50 미실행이고 요구 커버리지 95%, 코드 커버리지 82%이다. 고위험 결함 1건과 외부 결제망 장애시험 미완료가 남아 있다. 결과·결함·커버리지·잔여위험·종료기준을 이용해 출시판단 보고체계를 설계하시오.
요구어는 설계다. 숫자의 평균을 내지 말고 판단 경계와 예외조건을 만든다.
25점 풀이와 답안 구성 보기
25점 답안 목차
- 판본·범위·환경과 계획 분모 고정
- 930/20/50과 실행률·실행분 통과율 구분
- 고위험 결함과 미실행 회복성시험
- 요구 95%·코드 82%의 서로 다른 분모
- 사전 종료조건별 충족/미충족 표
- 수정·재시험·미연결 요구 보강
- 예외승인과 테스트 통과의 분리
- 제한·모니터링·롤백·만료 조건
- 종료근거와 최종 release 권한 분리
25점 도식 대조표
증거와 잔여위험 그림의 각 가지를 아래 표의 실제 분모·결함·공백으로 설명한다.
| 서로 다른 증거 | 잔여위험으로 해석할 것 |
|---|---|
| 1,000 계획: 930 PASS / 20 FAIL / 50 NOT RUN | 실패의 결함과 미실행의 증거 공백 |
| 요구 95% / 코드 82% | 서로 다른 분모의 미커버 위험 |
| 외부망 미완료 | 회복성 검증 공백 |
| 종료기준 / 예외승인 | 사전 종료조건별 표와 별도 승인 상태 |
25점 모범답안
1. 실행결과의 분모를 고정한다. release 후보의 commit·빌드·환경과 계획 1,000건을 고정한다. 통과 930건은 계획 대비 93%, 실패 20건은 2%, 미실행 50건은 5%이며 실행률은 950/1000=95%다. 실행된 950건만 보면 통과율은 930/950≈97.89%지만, 이 값을 계획 대비 통과율로 바꾸거나 미실행 50건을 성공으로 처리하지 않는다.
2. 결함·커버리지·미실행을 별도 위험으로 읽는다. 실패 20건은 심각도·영향·재현성·수정판본·재시험을 연결하고 미해결 고위험 결함 1건을 별도 표시한다. 요구 200개 중 190개 연결이라는 자체 가정에서 요구 추적 커버리지는 95%이고 10개 요구가 미연결이다. 코드 커버리지 82%는 실행된 코드 영역의 관찰값이므로 요구 95%와 함께 평균을 내어 품질점수 88.5%로 만들지 않는다. 외부 결제망 장애시험 미완료도 잔여위험으로 남긴다.
3. 사전 종료조건을 한 줄씩 판정한다. 이 예의 종료조건을 계획 케이스 실행률 98% 이상, 미해결 고위험 결함 0건, 요구 추적 커버리지 98% 이상, 필수 외부 결제망 회복성시험 완료로 정했다면 현재는 각각 95%, 1건, 95%, 미실행이므로 네 조건 모두 미충족이다. 코드 커버리지 82%는 이 예에서 종료조건으로 선언하지 않았으므로 숫자가 높거나 낮다는 이유만으로 별도 합격·불합격을 만들어 붙이지 않는다.
4. 기본 조치와 예외 경로를 분리한다. 기본 조치는 고위험 결함 수정·재시험, 남은 50건 수행, 미연결 10개 요구의 시험 보강, 외부 결제망 회복성시험 완료다. 일정상 예외가 필요하더라도 미충족 조건을 통과로 고치지 않는다. 권한 있는 별도 승인자가 허용 노출범위, 모니터링, 즉시 롤백 조건, 보완시험 기한·만료를 기록한 제한적 예외를 판단하도록 한다.
5. 종료판정과 release 승인을 분리한다. 예외가 승인되면 “종료기준을 충족했다”가 아니라 “종료기준 미충족 위험을 명시한 예외”로 추적한다. 반대로 재시험 뒤 실행률·고위험 결함·요구 커버리지·필수 회복성시험의 네 조건이 모두 충족되면 테스트 종료의 최소 증거가 갖춰진다. 그 상태도 법적 의무·운영준비·사업판단을 포함한 사람의 최종 release 승인을 자동으로 대신하지 않는다.
12. 결과관리 답안의 분모와 판정을 직접 고친다
| 잘못 쓴 답 | 수정할 판단 | 돌아갈 본문 |
|---|---|---|
| 930/950=97.89%이므로 계획 테스트 통과율도 97.89%다 | 실행분 통과율과 계획분모의 93%를 구별한다 | RM-2 |
| 미실행 50건은 실패에 넣으면 되므로 별도 표시는 필요 없다 | 미실행은 증거 부재라 실패와 별도 상태·사유로 남긴다 | 실행상태 |
| 요구 95%와 코드 82% 평균은 품질점수 88.5%다 | 서로 다른 분모의 평균을 내지 않고 미커버 위험을 각각 본다 | 커버리지 |
| 고위험 결함 1건은 전체 계획의 0.1%라 무시 가능하다 | 건수 비율이 아니라 영향과 사전 종료조건으로 판정한다 | 결함 |
| 외부망 시험을 못 했어도 자동시험 대부분이 통과했으니 회복성도 통과다 | 미실행 필수 시험은 통과 증거가 아니다 | 잔여위험 |
| 코드 커버리지 82%가 높아 보이므로 종료기준을 만족한다 | 선언되지 않은 임계값을 사후에 만들어 합격시키지 않는다 | 종료기준 |
| 예외승인을 받으면 미충족 시험도 PASS로 바꾼다 | 예외와 시험결과를 분리해 미충족 위험을 보존한다 | 예외 경로 |
| 네 종료조건을 모두 만족하면 최종 release 승인도 끝난다 | 테스트 종료 근거와 release authority의 결정을 구분한다 | 종료와 출시 |
조건을 바꿔도 종료조건을 한 줄씩 다시 본다
연습 1 — 고위험 결함을 수정하고 요구 커버리지를 99%로 올렸지만 외부 결제망 회복성시험은 여전히 미실행이라면? 고위험 0건과 요구 99%는 통과하지만 필수 회복성시험 완료 조건은 미충족이다. 실행률도 별도로 98% 이상인지 확인해야 하므로 두 개선만으로 종료판정을 끝내지 않는다.
연습 2 — 계획 1,000건 중 990건을 실행했고 고위험 0건·요구 99%·회복성시험 완료라면? 실행률은 990/1000=99%로 98% 기준을 넘는다. 네 사전 종료조건이 모두 충족됐는지 확인한 뒤 테스트 종료 근거를 만들 수 있지만, 최종 release 승인이 자동으로 끝나는 것은 아니다.
연습 3 — 권한자가 외부망 시험 미완료를 예외로 승인해 트래픽 10% 제한·즉시 롤백·3일 내 보완시험을 정했다면? 운영상 제한적 release 경로를 판단할 수는 있어도 “필수 회복성시험 완료”라는 원래 시험조건은 여전히 미충족이다. 예외승인과 시험 PASS를 같은 상태로 저장하지 않는다.