개념
진단은 "무엇이 문제인가"가 아니라 "왜 그런가"를 찾는 일
조직이 컨설턴트나 QMO에게 진단을 요청할 때는 대개 증상을 들고 온다. "운영 장애가 많다", "테스트가 늘 일정의 병목이다", "QA 팀 이직률이 높다". 진단의 일은 증상에서 원인 으로 내려가고, 그 원인을 증거 로 뒷받침하는 것이다.
모듈 7 레슨 6에서 TMMi와 TPI Next를 "우리 팀 레벨 가늠하기" 수준으로 봤다. 이 레슨은 그것을 남의 조직을 진단하는 실무 로 확장한다.
1단계 — 진단 범위와 질문
진단을 시작하기 전에 의뢰자와 세 가지를 합의한다.
| 합의 항목 | 질문 | 예 |
|---|---|---|
| 목적 | 진단 결과로 무엇을 결정하려 하는가 | 내년 품질 투자 우선순위 결정 |
| 범위 | 어느 조직·제품·프로세스를 보는가 | 커머스 본부 3개 팀, 요구사항~출시 |
| 기준 | 무엇에 비추어 판단하는가 | TMMi 레벨 2~3 프로세스 영역 + 내부 목표 |
목적이 없으면 진단은 "이것도 문제, 저것도 문제"의 목록이 된다. 목적은 발견 사항의 우선순위 기준 이 된다.
2단계 — 인터뷰
인터뷰는 진단의 핵심 증거원이지만 가장 편향되기 쉬운 증거이기도 하다. 원칙 네 가지.
- 역할을 골고루 — QA만 인터뷰하면 "개발이 문제"가 결론이 된다. 개발·기획·운영·관리자를 모두 만난다
- 열린 질문, 사례 요청 — "테스트 계획을 세우나요?"(예/아니오) 대신 "최근 프로젝트의 테스트 범위는 어떻게 정해졌나요? 그 과정을 보여 주실 수 있나요?"
- 1:1 또는 동일 역할 소그룹 — 상사와 부하를 같은 자리에 두면 솔직한 답이 안 나온다
- 익명성 약속과 준수 — 보고서에는 발언자를 특정하지 않는다
[역할별 인터뷰 질문 예]
QA 최근 운영에서 발견된 결함 하나를 골라, 왜 테스트에서 못 잡았는지 이야기해 주세요.
테스트 범위를 줄여야 했던 가장 최근 상황은? 누가 어떻게 정했나요?
개발 QA에서 받은 결함 보고 중 가장 도움이 된 것과 가장 곤란했던 것은?
단위 테스트는 어떤 기준으로 작성하나요? 누가 확인하나요?
기획 요구사항이 바뀌면 QA는 언제 어떻게 알게 되나요?
수용 기준은 누가 쓰나요? 예시를 보여 주실 수 있나요?
운영 지난 분기 장애 중 사전에 막을 수 있었다고 보는 건?
관리자 품질 상태를 무엇으로 판단하나요? 지금 받는 보고에서 부족한 건?"보여 주실 수 있나요?"가 중요한 질문이다. 말로 들은 것을 문서·도구 화면으로 확인할 수 있는지 바로 알 수 있다.
3단계 — 문서와 데이터
인터뷰가 사람들이 믿는 것 을 보여 준다면, 문서와 데이터는 실제로 일어난 것 을 보여 준다.
| 증거 종류 | 무엇을 보나 | 알 수 있는 것 |
|---|---|---|
| 테스트 계획·전략 | 최근 프로젝트 3개 | 계획이 실제로 있는가, 위험 기반인가, 복사본인가 |
| 테스트 케이스·실행 기록 | 표본 추출 | 추적성, 기대 결과의 질, 실행 빈도 |
| 결함 데이터 | 최근 6~12개월 전체 | 유입 단계, 심각도 분포, 탈출률, 재오픈율, 발견 시점 |
| 장애 보고서 | 최근 1년 | 원인 유형, 테스트로 막을 수 있었는지 |
| 일정 기록 | 계획 대비 실제 | 테스트 기간이 어떻게 압축되었는가 |
결함 데이터에서 가장 많은 정보가 나온다. 특히 결함이 만들어진 단계 (요구사항·설계·코딩·환경)와 발견된 단계 를 교차하면, 결함이 어디서 새고 있는지 보인다.
[결함 유입·발견 단계 교차표 — 최근 12개월 운영 결함 84건]
만들어진 단계 → 요구사항 설계 코딩 설정·환경
운영에서 발견 41 9 22 12
(49%)
→ 운영 결함의 절반이 요구사항 단계에서 만들어졌다.
테스트 실행을 늘리는 것보다 요구사항 리뷰가 더 효과적일 가능성.4단계 — 삼각측량
하나의 출처만으로 결론을 내리지 않는다. 인터뷰·문서·데이터 세 출처 중 최소 두 곳에서 같은 방향의 증거가 나올 때 발견 사항으로 확정한다.
| 발견 후보 | 인터뷰 | 문서 | 데이터 | 판정 |
|---|---|---|---|---|
| 요구사항 변경이 QA에 늦게 전달된다 | QA 5명 중 5명 언급 | 변경 이력에 QA 통보 기록 없음 | 요구사항 원인 운영 결함 49% | 확정 |
| 테스트 계획이 형식적이다 | QA 2명 언급 | 계획 3건 중 2건이 이전 계획 복사 | - | 확정(2출처) |
| 개발자가 단위 테스트를 안 쓴다 | QA 3명 언급 | - | 커버리지 측정 안 함 | 보류 — 개발 측 인터뷰·저장소 확인 필요 |
"보류" 판정이 중요하다. 한쪽 역할의 인터뷰에서만 나온 불만은 사실일 수도 있지만, 그대로 보고서에 쓰면 진단의 신뢰가 무너진다.
5단계 — 원인 분석과 우선순위
확정된 발견 사항을 현상 → 원인 → 증거 로 정리한다. 원인을 찾을 때는 "왜"를 반복하되, 사람 탓("QA가 꼼꼼하지 않다")에서 멈추지 말고 구조(절차·도구·역할·유인)까지 내려간다.
현상 운영 결함의 49%가 요구사항 원인
원인1 요구사항 변경 통보 절차가 없다(구조: 절차)
원인2 수용 기준을 쓰는 역할이 정해져 있지 않다(구조: 역할)
원인3 기획 일정에 리뷰 시간이 없다(구조: 계획)
증거 인터뷰 11건, 변경 이력, 결함 교차표우선순위는 1단계에서 합의한 목적 에 비추어 매긴다. 흔히 쓰는 기준은 영향(해결하면 얼마나 좋아지나) × 실행 용이성(얼마나 빨리, 싸게 할 수 있나)이다. 영향이 크고 쉬운 것이 첫 파일럿 후보가 된다(레슨 5).
TMMi 평가 — 공식과 비공식
성숙도 모델로 진단할 때는 TMMi가 가장 많이 쓰인다. 구조를 알아 두면 진단의 언어가 정확해진다.
- TMMi 모델 — 5개 성숙도 레벨, 레벨마다 프로세스 영역(예: 레벨 2의 테스트 정책·전략, 테스트 계획, 테스트 모니터링·통제, 테스트 설계·실행, 테스트 환경)
- TAMAR(TMMi Assessment Method Application Requirements) — TMMi 평가 방법이 갖춰야 할 요구사항. 그 자체는 평가 방법이 아니다
- TAM(TMMi Assessment Method) — TMMi 재단이 제공하는 평가 방법. 인증된 평가자(Assessor)·선임 평가자(Lead Assessor)가 라이선스를 받아 사용한다
- 공식 평가 — 인증된 선임 평가자가 TAMAR 요건에 따라 수행. 결과로 성숙도 레벨이 공식 인정된다
- 비공식 평가 — 빠르고 가볍게 현재 상태와 개선 방향을 파악. 레벨 인정은 되지 않는다
대부분의 사내 진단은 비공식 평가 수준이면 충분하다. 공식 레벨 인정이 필요한 경우는 입찰 요건이나 대외 신뢰 확보처럼 외부에 증명해야 할 때 다. 개인이 TMMi를 공부했다는 것을 보여 주려면 TMMi Professional 자격이 있다.
진단 보고서 구조
1. 요약(1쪽) — 목적, 핵심 발견 3개, 권고 3개
2. 진단 범위·기준·방법 — 인터뷰 N명(역할별), 문서 N건, 데이터 기간
3. 발견 사항 — 현상·원인·증거(삼각측량 표 포함)
4. 성숙도 관점(선택) — TMMi 프로세스 영역별 강점·약점
5. 권고와 우선순위 — 영향 × 용이성
6. 다음 단계 — 파일럿 제안(레슨 5)
부록 — 인터뷰 질문, 데이터 분석 상세실무에서 왜 필요한가
진단 없이 시작한 개선은 대개 가장 눈에 띄는 증상을 고친다. 운영 결함이 많으니 테스트 인원을 늘리는데, 실제 원인은 요구사항 단계에 있어서 효과가 없다. 삼각측량한 진단은 돈을 쓸 곳을 정확하게 만든다. 또 증거에 기반한 진단 보고서는 조직 내 정치적 논쟁("QA 탓이다", "개발 탓이다")을 사실의 논의로 바꾼다.
채용시장에서의 위치
테스트 컨설턴트, 품질 혁신, QMO 공고는 "현행 프로세스 진단", "개선 과제 도출", "TMMi 기반 성숙도 평가"를 요구한다. 면접에서 삼각측량과 결함 유입·발견 교차표를 설명할 수 있으면 진단을 실제로 해 본 사람으로 보인다.