프로젝트 일정 산출 - QA

프로젝트 일정 산출 방법에는 여러가지가 있습니다.

 

그 중, 산출이 간단하면서도 일정에 차질이 없으면서도, 효율적인 방안을 고민 후 내린 결론입니다.

• 개발 기간보다 QA 기간이 긴 경우는 한 번도 듣거나 보거나 경험해보지 못했으며,
• 7년간 제 경험과 여러 사례를 접하고 현재 제 업무 방식이기도 합니다.

---

프로젝트 일정 산출 방법입니다.

개발 기간의 20%를 QA 테스트 기간으로 정합니다. (Dev. working day * 0.2 = QA working day)
20%는 기존 솔루션에 결함이 많다고 판단한 최장 산정 기한입니다.

• 개발자가 여러명이라면?(개발자:QA 비율이 회사마다 천차만별입니다, 지금은 10:1 비율로 설명합니다)
  → 총 개발 기간의 20% 산출
• 개발이 파트별로 진행된다면?(Browser 별, App 별, Device OS 별)
  → 테스트 범위 협의가 필요한 부분입니다, 파트별로 테스트를 나누어 진행하거나 우선순위나 대상 결과물(예. Android 내 Chrome)에 따라 QA 테스트를 수행합니다.
• 일정 내 QA 테스트 수행이 어렵다면?
  → 자원(개발자 리소스 등), Deadline 등의 상황에 따라 PM과 협의 후 QA 테스트를 진행합니다.
       즉, 현재 저는 1인 QA로 업무를 진행 중인데, 통합테스트 기한이 한없이 부족할 때는 테스트를 기획자/개발자 등 가용 인원을 활용하여 테스트를 진행합니다. 보다 다양한 Case 별로 테스트될 수 있도록 끝까지 노력합니다.
• 이전 담당한 프로젝트의 후속 프로젝트라면?
  → 이미 익숙한 부분이 있기에 20%가 아닌, 10~15%로 정합니다.
      후속 프로젝트 시작 텀이 짧다면 10%, 길다면(예. 1년 후) 15%로 정하여 수행합니다.
• 외적 요인(실행환경, HW 등)이 발생한 경우는?
  → +1MD(Man/Month)

---

위에서는 간략하게 말씀드렸지만, 프로젝트 일정 산출 세부사항은 상세할 수 밖에 없습니다.

• 기획서 내용 파악
• 기획/디자인/개발 일정 파악 및 협의
• Deadline 확인( 및 프로젝트 연기 가능성 유/무 파악)
• Stag 환경 테스트, Master 환경 테스트 일정 협의
• 추정시간
  • 테스트 대상의 구조 기반 관점(기능; Function); 기능 위주로 산정
  • TC(Test Case) 위주로 산정
  • 경험 기반으로 산정 ⇒ CL(Checklist)
• 나의 working day 파악 등

 

끝으로 드리고 싶은 말씀은, 기능이 많고 복잡하고 파악에 지치고 어렵다고 낙심하지 마시고, 간단하게 시작부터 해보시는건 어떠실까요?

 

응원합니다.