"이거 얼마나 걸려요?" 테스트 케이스 수행 시간 계산법 (feat. 1인당 200개)

안녕하세요, Kitle입니다.

QA 전략을 세울 때 가장 머리 아픈 순간이 언제일까요? 바로 **"그래서 이거 테스트하는 데 얼마나 걸려요?"**라는 질문을 받을 때입니다. 이론과 현실의 괴리가 가장 큰 지점이기도 하죠.

현업에서 테스트 수행 시간을 정확히 추정하는 것은 결코 쉽지 않습니다. 하지만 그간의 산전수전 겪으며 쌓인 데이터와 현실적인 경험치를 바탕으로, 누구나 참고할 수 있는 테스트 케이스 수행 시간 계산 가이드를 정리해 보았습니다.

1. 현실적인 1인당 테스트 수행 속도 측정

가장 먼저 기준점(Baseline)을 잡아야 합니다. 보통 한 사람의 하루 업무 시간을 8시간으로 잡지만, 회의나 보고 등 부수적인 업무를 제외하고 순수하게 테스트에 몰입할 수 있는 시간은 그보다 적을 수 있습니다.

일단 이런 예외적인 상황을 제거하고 8시간 업무량을 기준으로 산정해봅시다.

경험적으로 숙련된 테스터 1인이 하루 8시간 동안 약 200개의 테스트 케이스(TC)를 수행할 수 있다고 가정해 봅시다.

• 이를 하나의 테스트 케이스 수행시간으로 나누어 본다면 케이스 하나당 약 2분 20초 정도가 소요되는 셈입니다.

 사실 테스트케이스는 셋업만 잘 되어 있으면 수행에 수 초 내에서 끝나는 경우도 있고, 이터레이션을 반복할 수록 외워서 자연적으로 더욱 빨라질 수도 있습니다. 이러한 변수들은 굉장히 많고, 복잡하기 때문에 아주 단순하게, 아주 복잡하지도 그렇다고 너무 단순하지도 않은 테스트케이스를 천천히 수행하는 경우 1인당 200개 정도를 잡을 수 있습니다.

테스트 케이스가 한 단계 -> 결과 확인 이렇게 각 항목마다 잘개 쪼개져 있다면, 수행갯수를 실제 하루 수행정도를 측정해보고 조직에 맞는 갯수를 조정해보시는 것도 좋습니다.

2. 인원 투입에 따른 소요 기간 예측 (1~10명)

위의 200개/일 기준을 바탕으로, 전체 TC 규모가 고정되어 있을 때 인원수별 예상 소요 기간은 다음과 같이 분산됩니다. (단순 산술 계산 기준)

일반적인 회사 내 프로젝트의 테스트 케이스는 1000 ~ 5000개 정도가 경험적으로 가장 중간값이라는 생각이 듭니다.

이를 수행하는데는 어느정도의 인원과 기간이 필요할지 대략적으로 가늠해 볼 수 있습니다.

다만 이 표는 자원 투입 대비 효율을 직관적으로 보여주지만, 인원이 늘어날수록 커뮤니케이션 비용과 인원에 대한 교육 시간, 그리고 인력 변경에 따른 매니징 리소스도 무시할 수 없어서, 단순히 투입 인원을 많이 투입 할 수 있더라도, 커뮤니케이션이나 어려움도 증가합니다.

또한 인력이 너무 적으면 다양한 환경에 대한 테스트가 불가능합니다.

개인적인 경험으로 ad-hoc테스트 할 때, 테스터간 비슷한 이슈가 등록될 확률은 경험적으로 10% 미만이어서, 가능하다면 다양한 많은 테스터를 두는 것이 효과적이긴 합니다.

3. 효율을 깎아먹는 변수를 제거하자

위의 계산은 어디까지나 숙련된 인력이 안정된 소프트웨어를 테스트할 때의 이야기입니다. 실제 프로젝트에서는 다음과 같은 오버헤드를 반드시 고려해야 합니다.

• 초기 품질 하락: 버그가 많이 나오면 이를 리포팅하고, 재현 경로를 확인하고, 수정 후 재 테스트(Retest)하는 시간이 추가됩니다. 이슈가 많고 이슈 등록, 재현에 시간이 오래 걸릴 수록 테스트 케이스 수행 시간은 딜레이 되거나 더욱 늘어날 수 있습니다.

  
  

• 리드 타임(Lead Time): 테스트 케이스의 의도를 파악하고 도메인 지식을 익히는 초기 적응 시간이 필요합니다

  .

• 환경 설정 오버헤드: 테스트 데이터 생성, 계정 세팅이 어렵거나 번거롭다면 준비시간이 더욱 더 많이 걸리게 됩니다. 따라서 사전에 데이터를 세팅해 놓거나, 데이터 상태를 변경할 수 있는 API, 툴, 개발자 메뉴 등을 제공해서 이런 시간을 제거하는 것이 좋습니다.

  
  

  
  

4. 업계 표준 및 통계 데이터 참고

경험적으로 얻은 수치 많으로 다소 부족할 수 있다면, 널리 알려진 추정 기법들을 참고해 볼 수 있습니다.

• TMMi 및 ISTQB 기반 가이드: 일반적인 매뉴얼 테스트의 경우, 복잡도에 따라 시간당 10~15개의 TC 수행을 권장합니다. (8시간 기준 80~120개 수준으로, 제 경험치인 200개보다 보수적입니다.)

  A. ISTQB (International Software Testing Qualifications Board)

  • 근거: ISTQB Foundation 및 Advanced(Test Manager) 실라버스 'Test Estimation' 섹션.

  • 핵심 내용: ISTQB는 **'메트릭 기반 기법(Metrics-Based Approach)'**을 강조합니다.

  • 데이터: 과거 프로젝트의 평균치를 활용하는데, 업계 일반 데이터(Industry Average)에 따르면 매뉴얼 테스트의 경우 시간당 10~15개의 TC가 수행된다고 봅니다. (8시간 중 순수 6시간 수행 시 하루 60~90개). 제 경험치(200개)보다 보수적인 이유는 ISTQB가 복잡한 비즈니스 로직과 분석 과정을 포함한 '테스트 활동 전체'를 고려하기 때문입니다.

  B. TMMi (Test Maturity Model integration)

  • 근거: TMMi Level 4 (Measured) - 'Test Measurement and Prediction' 프로세스 영역.

  • 핵심 내용: TMMi는 조직의 성숙도가 올라갈수록 **'정량적인 데이터(Historical Data)'**를 통해 예측 정확도를 높일 것을 요구합니다.

  • 데이터: 성숙도 높은 조직의 경우 'Test Point Analysis' 기법을 사용합니다. 기능의 가중치에 따라 시간을 배정하는데, 통상적으로 **Preparation(10%) : Specification(40%) : Execution(45%) : Completion(5%)**의 비율로 에너지를 배분할 것을 권장합니다. 즉, 수행(Execution)에 전체 일정의 절반 정도만 쓰는 것이 건강한 모델이라는 뜻입니다.

• 소프트웨어 공학의 'COCOMO' 모델 응용: 프로젝트의 복잡도와 팀의 역량에 따라 노력 지수(Effort)를 산출하며, 보통 전체 개발 기간의 25~30%를 테스트 기간으로 할당하는 것을 신뢰도 높은 기준으로 봅니다.

  예를 들어 총 개발 기간이 10일(2주)가 걸리는 부분이라면,  QA기간은 최소 3-4일(30-40%)를 잡는게 좋습니다.

  제 경험적으로는 테스트 -> 디버깅 -> 수정내용 확인 -> 테스트 -> 디버깅 -> 확인 이터레이션은 최소 2-3회 정도 가져가야 하고, 조직마다 속도는 다르지만 2-3일 이상은 가져가는게 좋습니다. 그 기간동안 테스트 담당자는 내용에 대해 학습하고 지식이 쌓이면서 더 다양한 루트와 예외 케이스를 추가로 발굴 할 수 있습니다.

• Case Study (마이크로소프트 등): 대규모 프로젝트에서는 단순 수행 시간 외에도 '테스트 환경 구축(Setup)'과 '결과 분석(Analysis)'에 수행 시간의 약 20~30%를 추가 배정하는 데이터가 존재합니다.

  
  

결론: 데이터는 '방향'일 뿐, '정답'은 아니다

경험적인 데이터는 프로젝트 초기 계획을 세울 때 훌륭한 기초 가이드가 됩니다. 하지만 테스트 현장은 언제나 변수와 오버헤드로 가득 차 있습니다.

따라서 위에서 계산한 수치를 절대적인 마감 시한으로 못 박기보다는, 초기 계획 수립 및 리소스 확보를 위한 근거 자료로 활용하시길 권장합니다. 실제 수행 단계에서는 반드시 10~20%의 버퍼 타임을 두어 프로젝트의 안정성을 확보하는 것이 진정한 QA 리더의 역량이니까요.