📘 QA WBS는 일정을 ‘맞추는’ 도구가 아니라 일정을 ‘증명하는’ 도구입니다

 

 

프로젝트에서 QA가 가장 힘들어하는 질문이 있습니다.

 

“테스트 기간 얼마나 필요하세요?”

“대충 2주 정도면 되지 않을까요?”

 

이 질문에 “2주면 될 것 같아요” 라고 답하는 순간,

QA는 협상력을 잃습니다.

‘감각’으로 이야기하는 순간 일정은 누가 더 목소리가 큰가의 문제가 되어버리죠.

 

하지만 이렇게 답하면 상황이 달라집니다.

 

 

 

“이번 테스트는 67개 작업, 총 120시간이 필요합니다.”

 

이 말은 요구가 아니라 증명입니다.

그리고 그것을 가능하게 하는 도구가 바로 QA WBS입니다.

 

 

 

 

WBS는 단순히 해야 할 일을 나열하는 문서가 아닙니다.

QA가 품질을 위해 필요한 시간을 논리적으로 설명하는 가장 강력한 수단입니다.

 

- 왜 2주가 필요한지

- 어떤 작업이 쌓여 있는지

- 어떤 테스트가 병렬 진행 불가한지

개발 지연이 QA 일정에 어떤 영향을 주는지

 

이 모든 것이 ‘근거 있는 일정’으로 제시됩니다.

결국 WBS는 일정을 ‘요구’하는 문서가 아니라

일정을 ‘사실로 만드는 문서’가 됩니다.

 

 

QA WBS 구조 (5단계 작업 분해)

WBS는 다음 5단계로 작업을 나눕니다.

 

WBS 레벨	작업 단위	예시	산정 기준
Level 1	프로젝트 전체	○○ 서비스 품질 보증	전체 프로젝트 기간
Level 2	테스트 단계	계획 / 설계 / 실행 / 정리	단계별 기간 배분 (10% / 25% / 55% / 10%)
Level 3	테스트 유형	기능 / 통합 / 회귀 테스트	테스트케이스 수 기반
Level 4	세부 활동	환경 구축 / TC 작성 / 결함 검증	활동별 표준 공수
Level 5	개별 작업	로그인 시나리오 TC 10건 작성	케이스당 30분~1시간

작업을 이렇게까지 쪼개는 이유는 단 하나입니다.

일정을 감이 아닌 ‘수치’로 설명하기 위해서!

 

 

🛠️ QA 공수 산정 공식

 

QA 공수는 보통 계획 10% → 설계 25% → 실행 55% → 정리 10%의 구조로 진행됩니다.

 

먼저 테스트 계획(10%)에서는 요구사항을 분석하고

범위와 전략을 정해 전체 테스트의 방향을 잡습니다.

 

이어지는 설계 단계(25%)에서는

테스트케이스를 작성(1건당 30분~1시간),

테스트 데이터 준비, 환경 설정 계획 등

실제 실행을 위한 기반 작업이 이루어집니다.

 

가장 많은 시간이 소요되는 실행 단계(55%)에서는

초도 테스트(1~2시간/건), 결함 재검증, 회귀 테스트 등

실제 품질 확보를 위한 테스트 활동이 집중됩니다.

 

마지막으로 정리 단계(10%)에서

결과 리포트, 품질 지표, 인수인계 등

테스트를 문서로 남기는 작업이 진행되며 전체 과정이 마무리됩니다.

숙련도에 따라 공수는 달라지며,

경험 많은 QA는 평균 20% 단축이 가능하고

신입은 약 30% 추가 시간을 고려하는 것이 일반적입니다.

 

 

<WBS 산정 시 반드시 포함해야 하는 ‘숨은 작업들’>

 

많은 팀이 이 부분을 누락하여

실제 필요한 시간의 ‘절반만’ 산정하는 오류를 범합니다.

 

빠지면 안 되는 필수 항목들

결함 회의/이슈 트래킹: 실제 테스트 시간의 15~20%

테스트 환경 대기/복구: 불안정 시 10% 지연

요구사항 변경 대응: 중반 변경률 평균 20%

개발 일정 지연에 따른 대기: 개발 지연률 평균 30%

크로스팀 커뮤니케이션: 일 평균 1시간

 

이 작업들을 포함하지 않으면 일정은 항상 부족해지고,

결국 QA가 책임을 떠안게 됩니다.

 

 

<정확한 WBS가 가져오는 3가지 변화>

 

1) 일정 협상력 확보

“안 될 것 같습니다”가 아니라

“이 업무량으로는 물리적으로 불가능합니다”라고 말할 수 있습니다.

정량 데이터는 설득이 아니라 설명이 됩니다.

 

2) 리소스 투입 시점 명확화

병목 구간 파악

인력 증원 또는 외부 QA 투입 시점 산정

일정 조율이 빠르고 정확함

 

 

3) 진행률 추적 가능

“거의 다 됐어요” 대신

“67개 중 42개 완료 → 진행률 63%”처럼 사실 기반 보고가 가능합니다.

지연이 발생해도,

어디서 문제가 생겼는지 정량적으로 파악할 수 있습니다.

 

 

<이런 조직이라면 꼭 필요합니다!>

- QA 일정이 늘 부족한데 근거를 제시하지 못하는 조직

- “테스트 기간을 줄여주세요”라는 요청을 거절하기 어려운 조직

- 누가 어떤 작업을 하는지 내부적으로도 불명확한 팀

- 테스트 현황을 물으면 “거의 다 했어요” 같은 추상적 답변이 나오는 조직

 

 

QA WBS는 복잡한 관리 기법이 아닙니다.

 

내가 해야 할 일을 구조화하고 그 시간의 이유를 설명하는 도구입니다.

일정을 맞추는 가장 확실한 방법은 현실적인 일정을 만드는 것인데요.

WBS 없이 일정을 관리하는 조직은 언제나 같은 위기를 반복합니다.

 

하지만

작업을 분해하고 시간을 측정하고 그 근거를 명확히 설명하는 팀은

일정을 약속이 아닌 사실로 만듭니다.

 

품질을 지키는 첫 번째 조건은 변함없이 충분한 시간 확보입니다.