진척·결함·위험 지표를 매일 읽는 법 — 번업, 유입·해결 곡선, 위험 목록

개념

지표는 보고용이 아니라 판단용이다

많은 팀이 지표를 주간 보고서에 넣기 위해 만든다. 금요일 오후에 숫자를 모으고, 표를 그리고, 보내고, 끝. 이렇게 쓰는 지표는 이미 일어난 일을 설명할 뿐 다음 행동을 바꾸지 못한다.

리드에게 지표는 매일 아침 5분 동안 보는 계기판이다. 목적은 하나다. "지금 계획대로 가면 릴리스 날 무슨 일이 생기는가"를 남보다 먼저 아는 것. 이 레슨의 지표는 모듈 6 레슨 5의 품질 지표를 리드의 일일 판단용으로 다시 배치한 것이다.

지표 1 — 실행 진척 번업 차트

번업(burn-up) 차트는 두 선을 그린다. 전체 범위(계획된 케이스 수)와 완료된 케이스 수다.

케이스
 400 ┤                             ______ 범위(증가!)
 350 ┤                  __________/
 300 ┤ ________________/                     ..... 목표선
 250 ┤                                ...../
 200 ┤                          ...../   ___ 완료
 150 ┤                    ...../   _____/
 100 ┤              ...../  ______/
  50 ┤        ...../ ______/
   0 ┼──────┬──────┬──────┬──────┬──────┬───
       D1     D3     D5     D7     D9    D11(릴리스)

번다운 대신 번업을 쓰는 이유는 범위 증가가 보이기 때문 이다. 번다운에서는 남은 일이 줄지 않으면 팀이 느린 것인지 범위가 늘어난 것인지 구분이 안 된다. 번업에서는 위쪽 선이 올라가는 것이 그대로 보인다. 위 그림처럼 D5에 범위가 300에서 350으로 늘었다면 그 원인(요구사항 추가, 테스트 설계 누락 발견)을 기록하고 일정 영향을 바로 계산한다.

판단 규칙은 간단하다. 최근 3일의 평균 완료 속도로 남은 케이스를 나누면 예상 완료일이 나온다. 예상 완료일이 릴리스일보다 늦으면 지금 위험을 올린다.

지표 2 — 결함 유입·해결 누적 곡선

결함 관리에서 가장 많은 정보를 주는 그림이다. 발견된 결함 누적(유입)과 해결된 결함 누적(해결)을 같은 축에 그린다. 두 선 사이의 간격이 미해결 결함 이다.

유입 곡선이 완만해지는 것이 품질이 좋아져서인지, 테스트가 덜 돌아서인지 는 반드시 번업 차트와 함께 본다. 실행 진척이 멈춘 날 유입이 줄었다면 그건 좋은 신호가 아니다.

지표 3 — 미해결 결함의 심각도 분포

미해결 결함 수만 보면 판단이 흐려진다. 미해결 40건 중 치명 0건·주요 3건과, 미해결 15건 중 치명 2건은 완전히 다른 상태다. 매일 심각도별로 나눠 본다.

[일일 미해결 결함]         D7    D8    D9    추세
치명(Blocker/Critical)     2     3     3     ▲ 주의
주요(Major)               11    10     8     ▼
보통·경미                  24    27    29     ▲ (허용 범위)

치명 결함이 줄지 않고 있다면 그것 하나만으로 릴리스 위험이다. 개수보다 치명 결함 각각의 예상 해결일 을 추적한다.

지표 4 — 재오픈율과 차단 비율

재오픈율이 올라가면 두 가지를 확인한다. 개발 쪽 수정이 급하게 되고 있는지, 아니면 결함 보고서의 기대 결과가 모호해서 개발자가 다르게 해석하는지. 후자라면 리뷰 체크리스트(레슨 2)의 BR-3 항목을 강화한다.

지표 5 — 기능별 결함 밀도

결함을 기능·모듈별로 나누면 어디가 아픈지 가 보인다. 결함의 80%가 20%의 모듈에 몰리는 경향(파레토)이 흔하다. 결함이 몰리는 모듈은 두 가지 조치가 필요하다.

1. 그 모듈의 회귀 범위를 넓히고 탐색적 테스트 세션을 추가한다
2. 개발 리드와 공유해 코드 리뷰나 리팩터링을 논의한다

위험 목록 — 지표를 행동으로 바꾸는 곳

지표에서 신호를 봤다면 위험 목록에 올린다. 위험 목록은 "걱정"의 목록이 아니라 담당자와 기한이 있는 조치 목록 이다.

위험의 상태는 열림 → 대응 중 → 해소 / 현실화 로 관리한다. 현실화된 위험은 이슈가 되어 일정·범위 결정으로 넘어간다(레슨 7, 모듈 4 레슨 5).

매일 아침 5분 루틴

1분  번업: 예상 완료일 vs 릴리스일
1분  유입/해결 곡선: 간격이 벌어지는가
1분  미해결 치명·주요: 개수와 각각의 예상 해결일
1분  재오픈·차단 비율: 경고 수준 초과 여부
1분  위험 목록: 오늘 확인할 항목, 새로 올릴 항목

대시보드는 모듈 22 레슨 8(Jira 대시보드와 가젯)과 레슨 11(TestRail)로 만든다. 도구가 없으면 스프레드시트 하나로도 충분하다. 중요한 것은 매일 같은 순서로 보는 습관 이다.

실무에서 왜 필요한가

릴리스 직전에 "테스트가 다 안 끝났습니다"라고 말하는 리드와, 2주 전에 "지금 속도면 D13에 끝납니다. 저위험 40개를 이연하거나 인원을 한 명 더 붙이는 선택지가 있습니다"라고 말하는 리드는 같은 상황을 전혀 다르게 만든다. 앞의 리드는 문제를 보고하고, 뒤의 리드는 결정을 돕는다. 이 차이는 지표를 매일 읽느냐에서 나온다.

채용시장에서의 위치

리드·매니저 공고의 "품질 지표 관리", "테스트 진척 관리"는 이 레슨의 내용이다. 면접에서 결함 유입·해결 곡선을 그려 보이며 "이 모양일 때 이렇게 판단했다"고 설명할 수 있으면 실제로 릴리스를 운영해 본 사람으로 보인다.

실습 과제

과제 1 — 곡선 해석 (15분)

다음 데이터를 스프레드시트에 넣어 유입·해결 누적 곡선을 그리고, D10 시점에 릴리스 위험을 어떻게 판단할지 세 줄로 쓴다.

일자   D1 D2 D3 D4 D5 D6 D7 D8 D9 D10
유입    8 14 12 11 10  9 10  9 10  9
해결    2  5  8  9  8  7  6  6  5  5

과제 2 — 예상 완료일 계산 (10분)

전체 케이스 420개, D6까지 완료 210개, 최근 3일 완료 수 28·31·30개, 릴리스는 D11이다. 예상 완료일을 계산하고, 늦는다면 선택지 두 개를 적는다.

과제 3 — 위험 목록 작성 (15분)

과제 1과 2의 결과로 위험 두 건을 위험 목록 형식(근거 지표·영향·가능성·대응·담당·확인일)으로 작성한다.

자가 체크리스트

• 지표를 보고용이 아니라 판단용으로 쓰는 차이를 설명할 수 있다
• 번업 차트로 범위 증가를 보고 예상 완료일을 계산할 수 있다
• 결함 유입·해결 곡선의 네 가지 모양을 해석할 수 있다
• 미해결 결함을 심각도별로 나눠 보는 이유를 말할 수 있다
• 재오픈율·차단 비율·반려율의 의미와 대응을 말할 수 있다
• 지표의 신호를 담당자와 기한이 있는 위험 목록으로 바꿀 수 있다

흔한 실수

• 지표를 주간 보고 때만 본다. 신호를 일주일 늦게 잡는다.
• 번다운만 본다. 범위 증가가 숨어 팀이 느린 것처럼 보인다.
• 유입이 줄면 무조건 좋다고 본다. 실행이 멈춰서 줄었을 수 있다.
• 미해결 결함 총수만 본다. 치명 결함 두 건이 경미 결함 서른 건보다 중요하다.
• 위험 목록을 걱정 목록으로 쓴다. 담당자와 확인일이 없으면 아무도 움직이지 않는다.

참고 자료

• ISTQB — CTAL-TM v3.0 — 테스트 모니터링·통제·보고
• Atlassian — Burnup chart — 번업 차트 구성과 범위 변경 표시
• 레슨 s2-m06-l05 — 테스트 보고서와 품질 지표
• 레슨 s2-m04-l04 — 일정·리소스 산정과 테스트 종료 조건