테스트 보고서와 품질 지표: 커버리지, 결함 밀도, 결함 탈출률, 실패율

개념

건강검진 결과표를 떠올려 보자. 쓸모 있는 결과표에는 세 가지가 있다 — 수치(콜레스테롤 240), 기준과의 비교(정상 범위 200 이하), 그리고 권고(식습관 조정, 3개월 후 재검사). 수치만 있으면 받는 사람이 아무 판단도 못 한다.

테스트 보고서가 정확히 같다. 숫자만 나열한 보고서는 읽히지 않는다. "커버리지 92%" 는 수치일 뿐이고, "계획 범위의 92%를 봤고 못 본 8%는 다국어·저사양 기기입니다" 가 판단 재료다.

테스트 보고서의 목적

테스트 보고서는 "내가 뭘 했는지" 자랑하는 문서가 아니다. 의사결정자가 이 정보를 보고 릴리스할지 말지 판단할 수 있게 만드는 문서다 — 모듈 4(레슨 5)에서 배운 Go/No-Go 결정의 근거 자료가 바로 이 보고서다. 좋은 보고서는 숫자(지표)와 그 숫자가 의미하는 바(해석)를 함께 담는다.

읽는 사람이 다르면 보고서도 다르다

같은 테스트 결과를 네 종류로 써야 할 때가 있다. 양을 줄이는 것이 아니라 관심사가 다르다.

세 번째 줄에서 많은 보고서가 실패한다. 임원이 받는 보고서에 지표 열 개를 나열하면 아무것도 전달되지 않는다. 결론 한 줄 + 위험 세 개 가 전부여야 한다.

보고서 한 장의 구조

길이가 아니라 순서가 전달력을 만든다. 결론을 맨 앞에 둔다.

5번이 보고서의 신뢰를 결정한다. "전부 테스트했습니다" 는 반드시 거짓이고, 한 번 들키면 다음 보고가 안 믿긴다(레슨 3·모듈 5 레슨 13).

지표 1 — 커버리지(Coverage)

"계획한 테스트 중 몇 %를 실행했는가"를 나타낸다.

테스트 실행률 = 실행한 테스트 케이스 수 / 계획한 전체 테스트 케이스 수 × 100

100%를 실행했다고 결함이 없다는 뜻은 아니다 — 그저 "계획한 범위를 다 확인했다"는 뜻일 뿐이다. 계획 자체가 부족했다면 커버리지 100%도 의미가 제한적이다.

커버리지의 두 가지 뜻

"커버리지" 라는 한 단어가 전혀 다른 두 가지를 가리킨다. 섞어 쓰면 보고서가 거짓이 된다.

두 번째가 더 중요하고 덜 쓰인다. 케이스 실행률 100%라도 요구사항 하나에 케이스가 아예 없으면 그 요구는 검증되지 않았다. 계획 자체의 구멍은 실행률로는 절대 드러나지 않는다.

그리고 케이스 실행률에는 함정이 하나 더 있다. 케이스마다 크기가 다르다.

200개 중 180개 실행 = 90%. 그런데 남은 20개가 전부 결제 영역이면 실질 커버리지는 90%가 아니다.

그래서 실행률은 반드시 무엇이 남았는지와 함께 보고한다. "90% 실행, 미실행 20건은 결제 영역" 이 정직한 한 줄이다.

지표 2 — 결함 밀도(Defect Density)

기능 영역(레슨 4의 라벨/컴포넌트)이나 코드 규모 단위로, 결함이 얼마나 집중되어 있는지 나타낸다.

결함 밀도 = 발견된 결함 수 / 규모(예: 기능 개수, 화면 개수, 1000줄당)

결제 모듈에서 결함 15건, 설정 화면에서 결함 2건이 나왔다면, 절대 건수만 보고 "결제 모듈이 문제"라고 단정하기보다, 각 영역의 규모 (화면 수, 기능 수)로 나눠서 밀도를 비교해야 공정하다. 결제 모듈이 화면 수가 5배 많다면 밀도는 오히려 비슷할 수 있다.

규모 단위는 구할 수 있는 것으로 고른다.

완벽한 단위는 없다. 중요한 것은 같은 단위로 계속 재는 것이다. 단위를 바꾸면 추세가 끊기고, 추세가 없으면 밀도는 거의 쓸모가 없다.

밀도가 높은 영역을 발견했을 때의 해석도 조심해야 한다.

• 정말 그 영역이 취약할 수 있다 → 다음 테스트를 더 투입한다
• 또는 그 영역만 열심히 봤을 수 있다 → 다른 영역이 미탐일 가능성
• 또는 그 영역만 변경이 많았을 수 있다 → 당연한 결과다

두 번째 가능성을 늘 함께 적는다. 결함이 안 나온 영역은 깨끗한 것이 아니라 안 본 것일 수 있다.

지표 3 — 결함 탈출률(Defect Escape Rate)

QA 단계에서 못 잡고 운영 환경까지 새어나간 결함의 비율이다.

결함 탈출률 = 운영에서 발견된 결함 수 / (QA에서 발견 + 운영에서 발견) × 100

이 지표가 높다는 건 테스트 커버리지나 테스트 설계 자체에 구멍이 있다는 신호다. 결함 탈출률은 QA 활동의 효과성을 가장 직접적으로 보여주는 지표 중 하나다.

이 지표에는 시간 함정이 있다. 운영 결함은 릴리즈 직후가 아니라 몇 주에 걸쳐 나온다.

릴리즈 ──┬── 1주 ──── 2주 ──── 4주 ────▶
         │
         └ 운영 결함 2건   +3건    +2건   ← 계속 늘어난다

그래서 "이번 달 탈출률" 처럼 달 단위로 자르면 숫자가 왜곡된다. 올바른 방법은 릴리즈 기준으로 묶는 것이다 — "v2.14 릴리즈 후 4주간 운영 결함 7건" 처럼 기준 기간을 고정해 비교한다.

그리고 분류가 전제다. 레슨 4의 발견 단계 라벨(개발 중 / QA / 운영)이 없으면 이 지표는 계산 자체가 불가능하다.

해석에서 가장 조심할 것은 이 숫자를 QA의 성적표로 읽지 않는 것이다. 탈출률이 높을 때 원인은 셋 중 하나다.

세 번째를 숫자로 보여 줄 수 있으면 탈출률은 QA를 비난하는 지표에서 자원을 요청하는 근거로 바뀐다.

지표 4 — 실패율(Failure Rate / Pass Rate)

실패율 = 실패한 테스트 케이스 수 / 실행한 테스트 케이스 수 × 100

실패율이 릴리스 직전까지 계속 높게 유지된다면, 기능이 아직 불안정 하다는 신호다. 반대로 실패율이 낮더라도 커버리지 자체가 낮다면 그 낮은 실패율은 신뢰할 수 없다 — 커버리지와 실패율은 항상 같이 봐야 한다.

실패율에는 셈하는 방식의 문제가 있다. 같은 케이스를 고친 뒤 다시 돌려 통과하면 그것을 실패로 셀까 통과로 셀까.

• 마지막 결과로 센다 → 릴리즈 시점의 상태를 보여 준다(보고용)
• 첫 실행 결과로 센다 → 처음 얼마나 불안정했는지 보여 준다(품질용)

둘을 섞지 않는다. 보고서에는 어느 쪽으로 셌는지 적는다. 적어 두지 않으면 지난 릴리즈와 비교할 수 없다.

과정 지표 — 결함이 흐르는 속도

레슨 1에서 본 세 숫자가 여기 들어온다. 위의 네 지표가 결과를 보여 준다면 이 셋은 과정을 보여 준다.

과정 지표가 결과 지표보다 먼저 움직인다. 재오픈율이 오르는 것은 다음 릴리즈의 탈출률이 오를 예고이고, 손쓸 시간이 있다는 뜻이다.

절대값보다 추세

숫자 하나로는 좋은지 나쁜지 알 수 없다. 결함 밀도 0.8이 좋은가? 아무도 모른다. 비교 대상이 없기 때문이다.

그래서 지표는 처음부터 같은 방식으로 계속 재는 것이 전부다. 완벽한 지표를 설계하려다 시작을 미루는 것보다, 거친 지표라도 같은 방식으로 다섯 번 재는 편이 훨씬 쓸모 있다.

결함 유입·해결 곡선

표 대신 그림이 설득력을 갖는 경우가 하나 있다. 쌓이는 속도와 해결되는 속도를 나란히 그리는 것이다.

건수
 60│                            ┌─ 누적 발견
   │                       ┌────┘
 40│                  ┌────┘
   │             ┌────┘        ┌──── 누적 해결
 20│        ┌────┘        ┌────┘
   │   ┌────┘     ┌───────┘
  0└───┴──────────┴────────────┴────▶
     1주      2주      3주      4주
          ↑ 두 선의 간격 = 미해결 건수

두 선이 벌어지면 발견이 해결을 앞지르고 있다 — 릴리즈가 다가와도 미해결이 줄지 않는다는 뜻이다. 좁아지면 안정화 중이다.

이 그림이 강한 이유는 "더 시간이 필요하다" 를 말로 설명하지 않아도 되기 때문이다. 간격이 좁아지는 추세가 안 보이면 날짜를 지킬 수 없다는 것이 그림으로 보인다.

지표는 목표가 아니라 신호다

지표 하나만 보고 판단하면 왜곡되기 쉽다. 예를 들어 "결함 탈출률을 낮추자"는 목표가 도구화되면, 팀이 사소한 결함까지 전부 QA 단계에서 붙잡으려다 릴리스 일정 자체가 늦어질 수 있다. 지표는 "지금 상황이 어떤지 알려주는 신호" 로 쓰고, 그 신호를 해석해서 다음 행동을 결정하는 건 사람의 몫이다.

이것은 "측정이 목표가 되면 측정이 망가진다" 는 오래된 법칙이다. 지표 하나하나가 어떻게 망가지는지 보면 조심할 지점이 분명해진다.

세 번째 줄이 가장 위험하다. 결함 수를 적게 유지하라는 압력이 생기면 결함이 기록되지 않고, 기록되지 않은 결함은 사라지는 것이 아니라 보이지 않게 될 뿐이다. 그 순간 모든 지표가 거짓이 된다.

쓰면 안 되는 지표

측정 자체가 해로운 것이 있다. 사람 단위로 집계하는 지표다.

두 번째는 특히 조심한다. 한 번 이런 집계가 공유되면, 그 뒤로 개발자는 결함을 인정하지 않는 쪽으로 움직인다. 레슨 3에서 본 "정보가 숨는다" 가 지표에서 벌어지는 모습이다.

영역 단위·유형 단위 집계는 괜찮다. "결제 영역 밀도가 높다" 는 정보고, "A님 영역 밀도가 높다" 는 평가다.

숫자에 해석을 붙이는 문장 틀

보고서에서 가장 자주 비는 부분이 해석이다. 틀을 외워 두면 쉽다.

[지표] 가 [값] 입니다 ([비교 대상] 대비 [변화]). 이것은 [의미] 라는 뜻이고, 따라서 [권고] 를 제안합니다.

적용하면 이렇게 된다.

오른쪽의 공통점은 숫자 뒤에 "그래서 무엇을 하자" 가 붙는다는 것이다. 이것이 보고서를 읽히게 만드는 유일한 차이다.

Go/No-Go 한 장 예시

지금까지의 요소를 모은 모습이다. 이 한 장이 모듈 4 레슨 5의 회의에 들어간다.

■ 결론
  조건부 Go. 결제 영역 확인 이틀을 확보하면 내보낼 수 있습니다.
  확보가 어려우면 결제 변경분만 제외하는 것을 제안합니다.
 
■ 범위
  v2.14 / 2026-09-28 ~ 10-04 / 스테이징·운영 유사 환경
  미포함: 다국어, 저사양 기기(이유: 기기 미확보)
 
■ 지표
  케이스 실행률  180/200 (90%)  ← 미실행 20건 전부 결제
  실패율         20/180 (11%)   ← 마지막 실행 기준
  결함 밀도      결제 1.9 / 설정 0.3 (화면 수 기준)
  재오픈율       8% (지난 릴리즈 14%)
 
■ 미해결 고위험
  S1 0건
  S2 2건  · 쿠폰 중복 적용 시 할인 과다 (영향: 손실 발생)
          · 주문 취소 후 재고 미복구 (영향: 데이터 누적 오류)
 
■ 못 한 것
  결제 수단 전환 경로(차터 2개), 다국어, 저사양 기기
 
■ 권고
  1) 결제 차터 2개에 이틀 확보
  2) S2 2건은 릴리즈 전 수정 또는 운영 감시 지표 합의
  3) 기기 2종 확보(탈출 결함의 5/7이 모바일)

"못 한 것" 과 "권고" 가 이 문서의 값이다. 지표만 있는 보고서는 읽는 사람에게 일을 넘기고, 이 두 절이 있는 보고서는 판단을 가능하게 만든다.

사례 — 커버리지 98%인데 운영 사고

한 릴리즈의 보고서에 커버리지 98%, 실패율 2%, 미해결 S1 0건이 적혀 있었다. 숫자로는 완벽했고 Go가 났다. 이틀 뒤 결제 실패 문의가 쏟아졌다.

원인을 추적하자 세 가지가 겹쳐 있었다.

세 가지 모두 숫자가 거짓말을 한 것이 아니라, 숫자가 그 질문에 답하지 않았던 것이다. 커버리지는 "계획을 소화했나" 에 답하고, "계획이 충분했나" 에는 답하지 않는다.

그 뒤 보고서에 두 줄을 추가했다.

• 요구사항 커버리지 — 요구 목록 대비 케이스가 없는 요구를 센다
• 미실행 항목의 영역 — "2%" 가 아니라 "미실행 4건: 결제 3, 설정 1"

첫 줄에서 케이스가 없는 요구 3건이 바로 드러났다. 지표를 하나 더 더한 것이 아니라, 원래 묻고 싶었던 질문으로 지표를 바꾼 것이다.

실무에서 왜 필요한가

모듈 4(레슨 5)에서 Go/No-Go를 결정할 때 "지금까지 발견된 결함 현황"을 근거로 든다고 배웠다. 이 레슨에서 배운 지표들이 바로 그 근거를 숫자로 만드는 방법이다. 커버리지·결함 밀도·결함 탈출률· 실패율을 계산하고 해석할 수 있는 QA는, 릴리스 회의에서 "느낌상 괜찮아 보여요"가 아니라 "커버리지 92%, 심각도 높음 결함 0건 잔존, 지난 릴리스 대비 결함 탈출률 감소"처럼 근거 있는 발언을 할 수 있다.

지표는 QA의 요구를 관철하는 수단이다

QA가 자원을 요청할 때 가장 약한 말은 "시간이 더 필요합니다" 다. 가장 강한 말은 같은 요청을 숫자로 바꾼 것이다.

오른쪽은 거절하기 어렵다. 거절하려면 그 숫자를 반박해야 하고, 숫자가 사실이면 반박할 것이 없다. 이것이 지표를 재는 가장 실용적인 이유다.

보고서는 QA의 일을 보이게 만든다

QA의 작업은 결함이 안 났을 때 가장 안 보인다. 아무 일도 없었던 릴리즈의 공로는 측정되지 않는다. 보고서가 그 공백을 메운다 — "차터 12개, 케이스 180건, 결함 35건 중 S1 4건을 릴리즈 전에 잡았다" 는 기록이 남는다.

이 기록은 평가 시즌에도 쓰이지만, 더 중요한 쓸모가 있다. 다음 릴리즈의 일정을 협상할 근거가 된다. 지난 릴리즈에 실제로 며칠이 걸렸는지가 적혀 있으면 추정이 감이 아니게 된다(모듈 5 레슨 13).

채용시장에서의 위치

지표를 계산할 수 있는 사람은 많고, 해석해서 다음 행동을 제안하는 사람은 드물다. 면접에서 갈리는 지점이 정확히 거기다.

다섯 번째가 가장 변별력이 크다. "못 한 것을 적는다" 는 답은 보고서를 실제로 의사결정에 올려 본 사람만 한다. 레슨 3의 릴리즈 판단, 모듈 5 레슨 13의 종료 보고와 같은 태도다.

세 번째도 좋은 답이다. 탈출률을 자기 성적표로 받아들이는 사람은 그 숫자를 숨기거나 변명하게 되고, 원인으로 나눠 보는 사람은 그 숫자로 자원을 얻는다.

직무로는 QA 리드·QA 매니저·품질 기획에서 직접 쓰인다. 공고 표현으로는 "품질 지표 관리", "테스트 보고 체계 수립", "릴리즈 품질 판단" 이 걸린다. 그리고 신입 단계에서도 계산은 할 수 있어야 하는 범위다.

실습 과제

과제 1 — 지표 계산하기 (12분)

다음 상황에서 4가지 지표를 각각 계산한다.

• 계획한 테스트 케이스: 200개, 실행: 180개
• 실행한 테스트 중 실패: 20개
• 이번 스프린트에서 QA가 발견한 결함: 35건
• 지난 스프린트 릴리스 이후 운영에서 발견된 결함: 5건

과제 2 — 지표를 해석해서 한 문단 보고서 쓰기 (13분)

과제 1에서 계산한 지표를 바탕으로, Go/No-Go 회의에 제출할 3~4문장 분량의 요약 보고서를 작성한다. 숫자를 나열만 하지 말고, 그 숫자가 릴리스 결정에 어떤 의미를 가지는지 해석까지 포함한다.

과제 3 — 망가진 지표 찾기 (12분)

어느 팀의 보고서에 다음이 적혀 있다. 각 줄에서 무엇이 가려져 있는지 한 줄씩 쓴다.

1. "커버리지 100% 달성"
2. "이번 스프린트 결함 수 지난 대비 40% 감소"
3. "실패율 1%로 역대 최저"
4. "QA별 결함 등록 수: A 42건, B 18건"

자가 체크리스트

• 커버리지·결함 밀도·결함 탈출률·실패율을 각각 계산할 수 있다
• 결함 밀도를 비교할 때 절대 건수가 아니라 규모 대비 비율을 봐야 하는 이유를 설명할 수 있다
• 결함 탈출률이 QA 활동의 효과성을 보여주는 지표인 이유를 설명할 수 있다
• 커버리지와 실패율을 함께 봐야 하는 이유를 설명할 수 있다
• 계산한 지표를 Go/No-Go 결정에 쓸 수 있는 해석 문장으로 정리할 수 있다
• 읽는 사람(개발 리드·PM·경영)에 따라 먼저 쓸 것이 다름을 설명할 수 있다
• 보고서 한 장의 여섯 순서를 말할 수 있고, 못 한 것을 왜 적는지 안다
• 케이스 실행률과 요구사항 커버리지의 차이를 설명할 수 있다
• 결함 밀도의 규모 단위를 고르고, 같은 단위로 계속 재는 이유를 안다
• 결함이 안 나온 영역이 "깨끗한 것이 아닐" 가능성을 설명할 수 있다
• 탈출률을 릴리즈 기준 고정 기간으로 집계해야 하는 이유를 안다
• 탈출률이 높을 때의 세 원인과 각각의 대응을 구분할 수 있다
• 결과 지표와 과정 지표의 차이, 과정 지표가 먼저 움직이는 이유를 안다
• 지표가 목표가 될 때 각 지표에서 생기는 왜곡 행동을 말할 수 있다
• 사람 단위 집계를 쓰지 않는 이유를 설명할 수 있다
• 숫자에 비교 대상·의미·권고를 붙여 한 문장으로 쓸 수 있다

흔한 실수

• 커버리지 100%를 "결함이 없다"는 뜻으로 착각한다. 계획한 범위를 다 실행했다는 뜻일 뿐, 계획 자체가 부족했을 수 있다.
• 결함 건수를 영역 규모 대비 없이 절대값으로만 비교한다. 규모가 다른 영역끼리는 밀도로 비교해야 공정하다.
• 지표 하나만 보고 판단한다. 실패율이 낮아도 커버리지가 낮으면 신뢰할 수 없는 숫자다 — 여러 지표를 함께 봐야 한다.
• 지표를 목표 자체로 삼아 왜곡된 행동을 유도한다. 지표는 판단을 돕는 신호이지, 그 자체가 최종 목표가 아니다.
• "커버리지 90%"만 적고 남은 10%가 무엇인지 안 적는다. 미실행이 전부 결제 영역이면 90%는 의미가 없다.
• 요구사항 커버리지를 안 본다. 케이스가 아예 없는 요구는 실행률로 절대 드러나지 않는다.
• 결함 밀도의 규모 단위를 중간에 바꾼다. 추세가 끊기고, 추세가 없으면 밀도는 거의 쓸모가 없다.
• 결함이 안 나온 영역을 깨끗하다고 결론 낸다. 안 본 것일 수 있다.
• 탈출률을 달 단위로 자른다. 운영 결함은 몇 주에 걸쳐 나온다. 릴리즈 기준으로 기간을 고정한다.
• 탈출률을 QA의 성적표로 읽는다. 그러면 그 숫자를 숨기거나 변명하게 된다. 원인 셋으로 나누면 자원 요청의 근거가 된다.
• 실패율을 어느 실행 기준으로 셌는지 안 적는다. 지난 릴리즈와 비교할 수 없게 된다.
• 사람 단위로 집계한다. 특히 개발자별 결함 수는 비난의 도구가 되고 정보가 숨는다. 영역·유형 단위로 센다.
• 숫자만 나열하고 권고를 안 쓴다. 읽는 사람에게 일을 넘기는 문서가 된다. "그래서 무엇을 하자"가 붙어야 읽힌다.
• "전부 테스트했습니다"로 보고한다. 반드시 거짓이고, 한 번 들키면 다음 보고가 안 믿긴다.

참고 자료

• ISTQB Glossary — Test Report, Defect Density — 품질 지표의 공식 용어 정의
• Lisa Crispin & Janet Gregory, Agile Testing — 테스트 지표와 보고서 작성을 다룬 장
• ISO/IEC/IEEE 29119-3 — Test Documentation — 테스트 완료 보고서의 표준 목차
• Martin Fowler — Cannot Measure Productivity — 사람 단위 측정이 왜 어긋나는가

이 커리큘럼 안에서

• 모듈 6 레슨 1 — 과정 지표 세 개(재오픈율·반려율·체류 시간)의 출처
• 모듈 6 레슨 2 — 리포트 품질이 재오픈율·반려율로 나타난다
• 모듈 6 레슨 3 — 숫자를 전하는 방식. 사람 단위 집계를 피하는 이유
• 모듈 6 레슨 4 — 라벨·컴포넌트. 모든 집계의 축이 여기서 나온다
• 모듈 4 레슨 5 — Go/No-Go. 이 보고서가 들어가는 자리
• 모듈 4 레슨 4 — 종료 조건. 지표로 종료를 판정하는 방법
• 모듈 5 레슨 13 — 종료 보고. "못 한 것을 적는다"의 같은 원칙
• 모듈 10 — 결함 분석. 원인 유형별 집계를 설계하는 곳
• 모듈 22 레슨 8 — Jira 대시보드로 이 지표를 자동으로 굴리는 법

한 줄 정리 — 보고서는 판단 재료이고, 판단은 숫자가 아니라 숫자 + 비교 + 해석 + 권고로 가능해진다. 커버리지는 "계획을 소화했나" 에만 답하므로 못 한 것을 함께 적고, 탈출률은 릴리즈 기준으로 고정해 재고, 사람 단위로는 세지 않는다. 그리고 지표가 목표가 되는 순간 결함은 사라지는 것이 아니라 보이지 않게 된다.