개념
보고의 목적은 정보가 아니라 결정이다
많은 QA 보고서가 이렇게 시작한다. "금주 테스트 수행 현황: 전체 420건 중 312건 수행(74.3%), Pass 287건, Fail 25건. 결함 현황: 신규 18건, 해결 22건, 미해결 31건…" 숫자는 정확하지만 읽는 사람은 마지막 줄까지 가서도 묻는다. "그래서 예정대로 나가도 되는 거예요?"
품질 상태 보고의 독자는 대부분 결정을 해야 하는 사람이다. 릴리스 일정, 범위, 추가 인원, 위험 감수 여부. 그래서 보고서는 결정에 필요한 것부터 쓴다. 이것을 결론 먼저(BLUF, Bottom Line Up Front) 원칙이라고 부른다.
한 장 구조
┌─────────────────────────────────────────────────────────┐
│ [결제 개편 릴리스 9/30] 품질 상태 — 9/19 기준 │
│ │
│ 요약 ● 주의(AMBER). 예정 출시 가능하나 정산 배치 1건이 │
│ 9/24까지 해결되지 않으면 범위 조정 필요. │
│ │
│ 신호등 범위 ● 녹 일정 ● 황 결함 ● 황 환경 ● 녹 │
│ │
│ 주요 위험 (최대 3개) │
│ 1. 정산 배치 이중 집계 결함(치명) — 수정 예정 9/23 │
│ 2. 테스트 진척 예상 완료 9/27 (릴리스 3일 전, 여유 부족) │
│ │
│ 선택지 │
│ A. 예정대로 9/30 — 9/24 결함 미해결 시 정산 기능 제외 │
│ B. 10/7로 1주 연기 — 전 범위 출시, 추가 비용 없음 │
│ │
│ 권고 A. 정산 기능은 기존 배치로 유지 가능해 제외 영향 작음 │
│ │
│ 요청 9/24 오전까지 A/B 결정(제품 책임자) │
│ │
│ 근거 데이터: [대시보드 링크] │
└─────────────────────────────────────────────────────────┘여섯 칸의 역할은 이렇다.
| 칸 | 역할 | 쓰는 요령 |
|---|---|---|
| 요약 | 결론 한두 문장 | 신호등 색 + "그래서 무엇이 필요한가" |
| 신호등 | 영역별 상태 | 4~5개 영역, 기준에 따라 색을 매김 |
| 주요 위험 | 결정에 영향을 주는 것만 | 최대 3개. 각각 영향과 예상 해결일 |
| 선택지 | 결정권자가 고를 수 있는 것 | 2~3개. 각각의 대가를 명시 |
| 권고 | QA의 의견 | 근거 한 줄. 권고 없이 선택지만 주지 않는다 |
| 요청 | 누가 언제까지 무엇을 | 결정·자원·정보 요청 |
세부 숫자는 링크로 뺀다. 보고서 본문에 표 세 개가 들어가는 순간 독자는 요약을 건너뛰고 표를 해석하기 시작한다.
신호등(RAG)을 기준 있게 매긴다
빨강·황색·녹색(Red·Amber·Green) 신호등은 쉽고 강력하지만, 기준 없이 매기면 "모든 게 늘 황색" 이 된다. 리드는 다칠까 봐 빨강을 피하고, 녹색은 자신 없어서 피한다. 영역별로 색의 기준을 미리 정하고 공개한다.
| 영역 | 녹색 | 황색 | 빨강 |
|---|---|---|---|
| 일정 | 예상 완료일이 릴리스 5일 이상 전 | 1~4일 전 | 릴리스일 이후 |
| 결함 | 미해결 치명 0, 주요 5 이하 | 치명 1 | 치명이 해결 예정일 없이 남음 |
| 범위 | 계획 범위 변경 없음 | 범위 10% 이내 증가 | 10% 초과 증가 또는 핵심 기능 미확정 |
| 환경 | 차단 비율 2% 미만 | 2~5% | 5% 초과 |
기준이 있으면 색은 리드의 기분이 아니라 지표의 결과 가 된다. 레슨 5의 지표를 그대로 쓴다.
빨강을 두려워하지 않는다. 빨강은 "도와 달라"는 신호다. 빨강이 한 번도 없던 프로젝트가 출시 직전에 무너지는 것이 가장 나쁜 보고다.
수치에는 맥락을 붙인다
"결함 31건 미해결"은 좋은가 나쁜가? 맥락 없이는 알 수 없다. 수치에는 세 가지 맥락 중 하나 이상을 붙인다.
- 기준 대비 — "종료 조건(주요 5건 이하) 대비 3건 초과"
- 추세 — "지난주 44건 → 31건, 하루 평균 2건 감소"
- 영향 — "31건 중 결제 흐름에 걸린 것은 2건"
"테스트 커버리지 74%"도 마찬가지다. 남은 26%가 저위험 관리자 화면이면 문제가 없고, 결제 경로면 큰 문제다. 남은 것이 무엇인가 를 쓰는 것이 퍼센트보다 중요하다.
나쁜 소식은 빨리, 선택지와 함께
나쁜 소식은 주간 보고를 기다리지 않는다. 레슨 5의 매일 아침 루틴에서 빨강 신호가 보이면 그날 결정권자에게 짧게 알린다.
[긴급 공유] 결제 개편 — 정산 배치 치명 결함
- 무엇: 정산 배치가 특정 조건에서 거래를 이중 집계(BUG-845)
- 영향: 가맹점 정산 금액 과다 지급 가능. 운영 반영 시 회수 필요
- 현재: 개발 원인 파악 완료, 수정 예정 9/23
- 선택지: (A) 9/24까지 미해결 시 정산 기능 제외 출시 (B) 1주 연기
- 요청: 9/24 오전 결정. 내일 오전 스탠드업에서 진행 상황 다시 공유드리겠습니다.나쁜 소식을 숨기거나 늦추는 가장 큰 이유는 "해결책 없이 문제만 가져가기 싫어서"다. 그래서 선택지를 붙여서 가져간다. 선택지가 불완전해도 괜찮다. 결정권자가 더 나은 선택지를 알 수도 있다.
독자에 따라 깊이를 바꾼다
같은 상황도 독자에 따라 다르게 쓴다. 모듈 26 레슨 7(C레벨 보고)의 원칙이 팀 리드 수준에서도 적용된다.
| 독자 | 관심사 | 보고 깊이 |
|---|---|---|
| 개발 리드 | 어떤 결함을 언제까지 고쳐야 하나 | 결함 목록, 재현 조건, 우선순위 |
| 제품 책임자 | 예정대로 나가나, 무엇을 빼야 하나 | 한 장 보고서, 선택지와 권고 |
| 경영진 | 사업·고객 위험, 필요한 결정 | 요약 두 줄 + 결정 요청 |
| 팀원 | 우리 팀이 지금 어디에 있나 | 신호등 + 이번 주 집중 영역 |
경영진에게 결함 번호를 쓰지 않는다. "정산 금액 과다 지급 가능성"처럼 사업 언어 로 쓴다.
보고서 자체를 개선한다
보고서가 쓸모 있는지는 독자에게 물어보면 된다. 분기에 한 번 제품 책임자와 개발 리드에게 "이 보고서에서 실제로 읽는 칸은 어디인가요? 빠진 것은?"이라고 묻는다. 읽히지 않는 칸은 지우고, 자꾸 따로 물어보는 정보는 칸으로 만든다.
실무에서 왜 필요한가
QA 팀의 영향력은 보고의 질에 비례한다. 같은 테스트를 해도 보고가 숫자 나열이면 QA는 "테스트 수행 부서"로 보이고, 보고가 선택지와 권고를 주면 QA는 "릴리스 의사결정의 파트너"로 보인다. 모듈 4 레슨 5의 Go/No-Go 결정도 결국 이 한 장 보고서가 매일·매주 쌓인 결과 위에서 이루어진다.
채용시장에서의 위치
리드·매니저 면접에서 "품질 상태를 어떻게 보고하셨나요"라는 질문에 한 장 보고서 샘플을 보여 줄 수 있으면 강하다(기밀은 가상 데이터로 바꿔 포트폴리오에 넣는다). 특히 "빨강 신호를 2주 먼저 올려 범위를 조정했고 출시일을 지켰다"는 사례는 리드 역량의 핵심 증거다.