개념
지표는 매달 손으로 세면 죽는다
모듈 6(레슨 5)에서 품질 지표를 배웠다. 결함 밀도, 결함 탈출률, 재오픈율, 실패율. 개념은 명확했다. 그런데 실무에서 이 지표들이 살아남지 못하는 이유는 계산식이 어려워서가 아니다.
매달 사람이 손으로 세야 하기 때문이다.
첫 달에는 다들 열심히 센다. 둘째 달에는 조금 늦어진다. 셋째 달에는 "이번 달은 바빠서"가 나오고, 넷째 달에는 아무도 묻지 않는다. 지표가 죽는 전형적인 경로다.
앞 레슨에서 JQL로 원하는 집합을 뽑는 법을 배웠다. 이 레슨은 그 쿼리를 항상 켜져 있는 화면 으로 만드는 방법이다. 한 번 만들어두면 숫자는 스스로 갱신된다. 지표가 살아남는 유일한 방법이다.
대시보드 만들기 — 세 가지만 정하면 된다
Jira 상단 대시보드 메뉴에서 생성한다. 처음 정하는 것은 셋이다.
| 항목 | 결정 기준 |
|---|---|
| 이름 | 누가 보는 화면인지 드러나게. [QA] 주간 결함 현황 처럼 |
| 설명 | 팀원이 이 화면을 어떻게 쓰는지 한두 줄 |
| 권한 | 비공개(나만) / 공유(팀·그룹·전사) |
그 다음 레이아웃 을 1~3열 중에서 고른다. 실무 감각으로는 2열이 기본 이다. 3열은 노트북 화면에서 각 가젯이 너무 좁아지고, 1열은 스크롤이 길어진다.
레이아웃을 정하면 빈 화면이 나오고, 여기에 가젯 을 얹는다.
가젯 — 무엇을 언제 쓰는가
가젯은 종류가 많지만 QA가 실제로 쓰는 것은 한정적이다. 용도별로 정리한다.
| 가젯 | 무엇을 보여주나 | QA가 쓰는 상황 |
|---|---|---|
| 필터 결과(Filter Results) | 필터에 걸린 항목을 목록으로 | 지금 당장 처리해야 할 것 — 검증 대기, 긴급 결함 |
| 파이 차트(Pie Chart) | 한 기준으로 그룹화한 비율 | 상태별·컴포넌트별·담당자별 결함 분포 |
| 만듦 대비 해결됨(Created vs Resolved) | 기간별 생성 건수와 해결 건수 비교 | 결함이 쌓이는 중인지 줄어드는 중인지 |
| 이슈 통계(Issue Statistics) | 특정 필드 기준 건수 집계 | 담당자별 작업량, 병목 구간 파악 |
| 2차원 필터 통계 | 두 기준의 교차표 | 우선순위 × 상태, 컴포넌트 × 심각도 |
| 스프린트 상태(Sprint Health) | 진행 중 스프린트의 완료율·범위 변경 | 스프린트 중반 리스크 감지 |
| 로드맵(Road Map) | 예정된 버전과 진행률 | 릴리즈 준비 상황 확인 |
| 이슈 캘린더 | 마감일 기준 달력 | 일정 충돌 확인 |
| 경과 시간 차트 | 해결까지 걸린 시간 분포 | 사이클 타임·리드 타임 추세 |
가장 먼저 넣어야 할 것을 하나만 고르라면 '만듦 대비 해결됨'이다. 이 가젯 하나가 팀에 던지는 질문이 크기 때문이다 — 우리는 결함을 만드는 속도보다 빠르게 고치고 있는가? 선이 벌어지고 있다면 그 자체가 경고다.
품질 지표를 가젯에 매핑하기
모듈 6에서 배운 지표들이 어떤 가젯으로 화면이 되는지 연결해두면, 이 레슨이 개념 학습이 아니라 실행 계획이 된다.
| 품질 지표 | 필요한 JQL | 표현할 가젯 |
|---|---|---|
| 결함 유입/처리 균형 | 프로젝트 + Bug | 만듦 대비 해결됨 |
| 결함 밀도(영역별) | Bug + 컴포넌트별 | 파이 차트(컴포넌트 기준) |
| 우선순위 분포 | Bug + 미해결 | 2차원 통계(우선순위 × 상태) |
| 재오픈된 결함 | status CHANGED FROM Done TO Reopened | 필터 결과 + 건수 |
| 방치된 결함 | updated <= -60d AND status NOT IN (Done) | 필터 결과 |
| 검증 누락 | status = Done AND status WAS NOT "In QA" | 필터 결과 |
| 결함 해결 소요 시간 | 해결된 Bug | 경과 시간 차트 |
| 담당자별 부하 | 미해결 항목 | 이슈 통계(담당자 기준) |
표의 가운데 열이 전부 앞 레슨의 JQL이라는 점을 짚어두자. 대시보드 작업의 90%는 이미 필터를 만들 때 끝나 있다. 가젯은 그것을 그리는 얇은 층일 뿐이다.
그래서 순서가 중요하다.
① 답이 필요한 질문을 정한다
↓
② 그 질문을 JQL로 쓴다
↓
③ 필터로 저장하고 팀에 공유한다 ← 공유를 빠뜨리면 ④에서 막힌다
↓
④ 가젯을 얹는다3번에서 막히는 경우가 정말 많다. 가젯 설정 화면의 필터 목록에 내가 만든 필터가 안 보인다면, 십중팔구 공유 설정을 안 한 것 이다.
대시보드는 독자별로 나눈다
여기가 설계의 핵심이다. 하나의 대시보드에 모든 것을 담으려 하면 아무도 보지 않는 화면이 된다. 보는 사람이 다르면 필요한 숫자도 다르기 때문이다.
| 독자 | 알고 싶은 것 | 넣을 가젯 |
|---|---|---|
| QA 팀원 | 오늘 내가 무엇을 해야 하나 | 필터 결과(내 검증 대기, 재현 필요), 이슈 캘린더 |
| 개발 팀·스크럼 마스터 | 지금 무엇이 막혀 있나 | 스프린트 상태, 2차원 통계(상태 × 담당자), 차단 결함 목록 |
| PO·릴리즈 매니저 | 이번 버전을 내보내도 되나 | 로드맵, 픽스 버전별 미해결 건수, 우선순위별 잔여 |
| 경영진·유관 부서 | 품질이 나아지고 있나 | 만듦 대비 해결됨(추세), 경과 시간 차트, 월별 유입 추이 |
독자별 대시보드의 지표 개수는 3~5개로 제한한다. 화면에 12개 가젯이 있으면 사람은 아무것도 보지 않는다. 경영진용 화면일수록 더 적어야 한다.
또 하나의 기준 — 행동으로 이어지지 않는 숫자는 빼라. "총 등록된 결함 누적 4,812건"은 보기에는 그럴듯하지만 그 숫자를 보고 할 수 있는 일이 없다. 반면 "60일 이상 방치된 High 결함 14건"은 즉시 행동을 부른다.
안티패턴 — 죽은 대시보드의 특징
실무에서 자주 보는 실패 형태들이다.
1) 허영 지표만 있는 화면. 누적 건수, 총 테스트 케이스 수처럼 오르기만 하는 숫자 는 상태를 말해주지 않는다. 비율과 추세로 바꾼다.
2) 기준선이 없는 숫자. "미해결 결함 37건"만으로는 좋은지 나쁜지 알 수 없다. 지난달은 몇 건이었나? 목표는 몇 건인가? 비교 대상이 없는 숫자는 판단을 만들지 못한다. 모듈 25(레슨 3)에서 배운 '목표치의 출처' 문제가 여기서 반복된다.
3) 깨진 채로 방치된 가젯. 필터가 삭제되거나 상태 이름이 바뀌면 가젯은 조용히 0을 표시한다. 0이 "좋아졌다"인지 "고장났다"인지 구분되지 않는 것이 가장 위험하다. 대조용으로 전체 건수 가젯을 하나 두면 이 상황을 감지할 수 있다.
4) 아무도 열지 않는 화면. 가장 흔한 실패다. 만들 때는 열심이지만 일상 동선에 없으면 안 열린다. 해결책은 화면을 예쁘게 만드는 것이 아니라 회의 아젠다에 넣는 것 이다. 주간 회의를 이 대시보드를 열어놓고 시작하면 화면은 살아 있게 된다.
가젯으로 안 되는 것
정직하게 한계도 짚자. Jira 대시보드로 감당하기 어려운 것들이 있다.
- 여러 프로젝트를 가로지르는 복합 집계 — 가젯 단위로는 한계가 있다
- 정교한 계산이 필요한 지표 — 결함 탈출률처럼 분모가 릴리즈 시점에 따라 달라지는 계산
- 긴 기간의 추세와 비교 — 분기·연 단위 비교
- 테스트 실행 결과와의 결합 — 케이스 수·통과율은 Jira 기본에 없다
이럴 때 선택지는 셋이다. (1) 모듈 22 레슨 1에서 본 Xray·Zephyr 같은 플러그인 을 쓰면 테스트 실행 지표 가젯이 함께 온다. (2) Jira REST API로 데이터를 뽑아 별도 BI 도구에서 그린다. (3) 마켓플레이스의 리포팅 앱을 쓴다.
어떤 경우든 출발점은 같다 — 답이 필요한 질문이 먼저이고 도구는 그 다음이다. 가젯이 안 된다고 질문을 포기하지 않는 것이 중요하다.
실무에서 왜 필요한가
QA의 일에는 구조적인 불리함이 하나 있다. 잘하면 아무 일도 일어나지 않는다. 결함을 미리 잡으면 사고가 안 나고, 사고가 안 나면 아무도 QA를 떠올리지 않는다. 반대로 하나 놓치면 그것만 남는다.
대시보드는 이 비대칭을 조금 교정한다. "이번 분기에 결함 유입이 줄고 해결 속도가 빨라졌다"는 것이 매주 갱신되는 화면으로 보이면 그건 주장이 아니라 사실이 된다. QA 활동의 효과를 눈에 보이게 만드는 가장 값싼 방법이다.
실무적으로도 시간을 크게 아낀다. 주간 회의 준비, 릴리즈 판단 근거, 회고 자료를 매번 손으로 만들던 것이 링크 하나로 대체된다. 그 시간은 그대로 테스트로 돌아온다.
그리고 이 능력은 다른 도구에도 그대로 이식된다. "질문 → 쿼리 → 저장 → 시각화"라는 사슬은 모든 도구에서 같다. 도구가 바뀌어도 이 사고 순서를 아는 사람은 하루면 적응한다.