개념
리드와 매니저의 경계
모듈 43의 테스트 리드는 주어진 범위와 인원 안에서 팀을 움직인다. 테스트 매니저는 범위와 인원 자체를 정한다. 이 차이가 매니저의 모든 일을 바꾼다.
| 테스트 리드 | 테스트 매니저 | |
|---|---|---|
| 주어진 것 | 범위·인원·일정 | 사업 목표·제품 위험·예산 한도 |
| 결정하는 것 | 팀 내 배분·우선순위 | 테스트 범위·자원·일정·예산·외부 협력 |
| 협상 상대 | 개발 리드, 기획자 | 프로젝트 관리자, 제품 책임자, 재무, 경영진, 외주사 |
| 주요 결과물 | 배분표, 일일 보고 | 테스트 전략·계획, 예산안, 비즈니스 케이스, 회고 기반 개선 |
ISTQB CTAL-TM v3.0은 테스트 매니저의 성과를 "테스트 관리 프로세스 적용, 이해관계자와 생명주기 파악, 위험 식별·평가 세션 진행, 조직 목표에 맞는 프로젝트 테스트 전략 정의, 진척 모니터링· 통제·보고, 팀 역량 파악과 개발, 비즈니스 케이스 제시, 프로세스 개선 주도"로 정리한다. 이 레슨은 그중 전략 → 자원 → 비즈니스 케이스 → 협상 의 흐름을 다룬다.
정책에서 전략으로, 전략에서 계획으로
테스트 문서에는 층이 있다. ISO/IEC/IEEE 29119-3과 모듈 8에서 본 구조다.
| 층 | 문서 | 누가 | 바뀌는 주기 |
|---|---|---|---|
| 조직 | 테스트 정책 | QA 조직 책임자·QMO | 몇 년 |
| 조직 | 조직 테스트 전략(공통 관행) | QMO | 1년 |
| 프로젝트 | 프로젝트 테스트 전략·계획 | 테스트 매니저 | 프로젝트마다 |
| 레벨·유형 | 레벨별 계획(시스템·인수 등) | 테스트 매니저·리드 | 단계마다 |
테스트 매니저의 전략은 조직 정책을 이 프로젝트의 위험과 제약에 맞게 구체화 한 것이다. 조직 정책이 "핵심 결제 경로는 자동 회귀 필수"라면, 프로젝트 전략은 "이번 결제 개편에서 자동 회귀 대상은 이 40개 시나리오, 도구는 기존 Playwright 스위트 확장, 추가 공수 12인일"로 내려온다.
위험에서 자원을 도출한다
자원 산정은 "작년에 이 정도 했으니까"가 아니라 위험에서 출발한다. 모듈 4 레슨 2의 위험 목록과 레슨 4의 산정 기법을 연결한다.
[위험 → 테스트 강도 → 공수]
위험 항목 등급 테스트 강도 공수(인일)
결제 금액 계산 오류 상 결정표 전수 + 경계값 + 자동 회귀 14
PG 연동 장애 처리 상 장애 주입 + 타임아웃 시나리오 8
정산 배치 정합성 상 원장 대사 자동화 10
주문 조회 화면 중 주요 흐름 + 탐색 세션 2회 5
관리자 통계 하 스모크 2
────────────────────────────────────────────────────────
소계 39 + 회귀·재확인 배수(1.4) + 관리·보고(10%) ≈ 60인일회귀·재확인 배수는 모듈 4 레슨 4에서 본 "테스트는 한 번으로 끝나지 않는다"의 반영이다. 과거 프로젝트의 실제 값(결함 수정 후 재확인 비율, 빌드 횟수)으로 보정한다.
이렇게 도출하면 협상할 때 위험 항목 단위로 이야기할 수 있다. "60인일이 너무 많다"는 말에 "그럼 관리자 통계 스모크를 빼면 2인일, 정산 대사 자동화를 수동 샘플링으로 바꾸면 6인일이 줄지만 정산 위험은 이만큼 커진다"고 답할 수 있다.
인력 구성의 선택
자원이 정해지면 누구로 채울지 정한다. 선택지는 넓다.
| 구성 | 강점 | 약점 | 잘 맞는 일 |
|---|---|---|---|
| 내부 정규 인력 | 도메인 지식 축적, 장기 품질 | 고정비, 채용 시간 | 핵심 도메인, 자동화 자산 |
| 외주 테스트 전문 기업 | 빠른 증원, 전문 기법 | 도메인 학습 비용, 지식 유출 | 대규모 통합 시험, 성능·보안 전문 영역 |
| 파견·계약 인력 | 유연한 기간 | 관리 부담, 동기 부여 | 프로젝트 피크 기간 실행 |
| 크라우드 테스트 | 기기·지역 다양성, 짧은 시간 | 결과 편차, 보안 제약 | 호환성, 현지화, 탐색적 테스트 |
모듈 7 레슨 9의 아웃소싱 판단 기준이 여기서 쓰인다. 매니저가 추가로 챙길 것은 외부 인력의 결과물 품질을 어떻게 보증하는가 다. 계약서에 결함 보고서 품질 기준(모듈 43 레슨 2의 체크리스트), 산출물 인수 기준, 보안 조건을 넣는다.
비즈니스 케이스 — 테스트 투자를 돈의 언어로
테스트 매니저가 가장 자주 하는 설득은 투자 요청 이다. 자동화 도입, 성능 테스트 환경, 인원 증원, 도구 라이선스. 이때 "품질이 좋아진다"는 말은 설득력이 없다. 비즈니스 케이스는 다음 구조로 쓴다.
| 항목 | 내용 |
|---|---|
| 문제 | 현재 무엇이 얼마의 비용을 만드는가 |
| 제안 | 무엇에 얼마를 투자하는가 |
| 효과 | 무엇이 얼마나 줄어드는가(비용·시간·위험) |
| 회수 기간 | 언제 투자금이 회수되는가 |
| 대안 | 하지 않으면 / 다른 방법이면 |
| 위험 | 효과가 안 나올 가능성과 조기 판단 지표 |
[비즈니스 케이스 요약 — 결제 회귀 자동화]
문제 릴리스마다 결제 수동 회귀 5인일 × 연 24회 = 120인일(약 4,800만 원)
최근 1년 결제 관련 운영 장애 3건, 건당 복구·보상 평균 2,000만 원
제안 자동화 구축 40인일 + 유지보수 연 20인일 + CI 인프라 연 600만 원
효과 수동 회귀 5 → 1인일, 연 96인일 절감(약 3,840만 원)
장애 1건 예방 가정 시 2,000만 원
회수 구축 비용(약 1,600만 원 + 인프라) 기준 약 6~7개월
대안 현상 유지: 연 4,800만 원 + 장애 위험 지속
위험 UI 변경이 잦으면 유지보수 증가 → 3개월 후 플래키율 5% 초과 시 범위 재검토금액은 인일 단가 같은 조직이 이미 쓰는 기준 으로 환산한다. 재무 담당자가 받아들이는 단가를 먼저 확인하는 것이 첫 단계다. 품질 비용(CoQ)의 예방·평가·실패 비용 분류(모듈 7 레슨 9)를 쓰면 "평가 비용을 늘려 실패 비용을 줄인다"는 구조가 명확해진다.
품질·비용·납기 협상
매니저는 늘 세 꼭짓점 사이에서 협상한다. 좋은 협상의 원칙은 두 가지다.
- 하나를 정하면 나머지 둘이 어떻게 되는지 보여 준다 — "납기를 고정하면, 범위를 줄이거나 인원을 늘리거나 위험을 감수해야 합니다. 세 선택지의 구체적인 모습은 이렇습니다."
- 품질을 협상 변수로 숨기지 않는다 — "테스트 기간을 줄이자"는 요청은 사실 "위험을 더 감수하자"는 결정이다. 그 위험을 명시적으로 이름 붙여 결정권자가 감수하게 한다(모듈 43 레슨 6의 위험 감수 기록)
[협상 문장 예]
"테스트 기간을 3주에서 2주로 줄이면, 위험 등급 '중' 이하 항목의 테스트를 스모크로 낮춰야 합니다.
그 경우 주문 조회·관리자 통계에서 결함이 운영으로 나갈 가능성이 커집니다.
과거 비슷한 범위에서 운영 결함이 평균 4건 나왔습니다. 이 위험을 감수하는 결정이면
운영 첫 주 모니터링 강화와 핫픽스 대기 인원을 함께 준비하겠습니다."회고로 체계를 개선한다
프로젝트가 끝나면 매니저는 산정과 실제의 차이 를 기록한다. 위험 항목별 계획 공수 대비 실제, 예상 결함 대비 실제, 운영 탈출 결함. 이 데이터가 쌓여야 다음 산정이 정확해지고, 조직의 테스트 전략(QMO의 일, 레슨 2)이 개선된다.
실무에서 왜 필요한가
테스트 예산은 늘 가장 먼저 깎인다. 근거 없는 예산은 방어할 수 없고, 위험 단위로 도출된 예산은 깎이더라도 무엇이 빠지고 어떤 위험이 생기는지 합의된 채로 깎인다. 이 차이가 운영 장애 뒤의 책임 논쟁에서 QA 조직을 지킨다.
채용시장에서의 위치
테스트 매니저 면접의 단골 질문은 "예산이나 인원이 부족할 때 어떻게 했나", "자동화 투자를 어떻게 설득했나"다. 위험→공수 도출표와 비즈니스 케이스 한 장을 보여 줄 수 있으면 다른 지원자와 확실히 구분된다.