일정을 제시하라고 상사로부터 말을 들으면 심히 불안하고 초조해집니다. 그럴 때 조금은 도움이 될만한 방법을 소개해드립니다.
Test Schedule
보통 개발일정, 테스트일정, 테스트 공수 라고 부르는데요, 해당 업무를 진행하는데에 소요될 것으로 예상되는 일정을 의미합니다. 보통 MD(Man/Day, 한 사람이 하루 8시간 기준으로 일할 수 있는 양)으로 계산하고, 대형프로젝트일 경우에는 MM(Man/Month, 한 사람이 한 달 기준으로 일할 수 있는 양) 으로 계산합니다.
때문에 가령 2MD일 경우에는 혼자서 할 경우 2일이 소요되지만, 2명인 경우에는 1일 소요될 일정이라고 생각하시면 됩니다. 보통 30MD를 1MM라고 합니다.
개발이나 테스트 일정은, 이렇게 계산한대로 스무스하게 풀리진 않습니다. 일정 계산하고 진행하여도 도중에 Spec의 변경이라던지 요구사항의 추가가 이루어질 경우 이 일정을 다시 산정해야하기도 합니다. 발생한 Bug의 수정예상시간이 큰 경우에도 전체적인 일정이 틀어지는 일은 허다합니다.
고객 혹은 사업부는 세월아내월아 기다려주지 않습니다. 대부분 언제까지의 납기일(DeadLine)을 정해놓습니다. 또는 사업 측에서, 다른 사업자와의 경쟁관계로 인하여 좀 더 빠르게 서비스를 런칭하고자 하는 경우들이 많습니다. 보통 이럴때 사업측에서 전체적인 일정을 정해놓고, 각각의 부서에 일정을 계산해달라고 하기도 합니다. 마음대로 풀리지 않는 것이 개발/테스트 일정이긴하나, 어느정도 기준값을 가지고 제시를 할 수 있어야 합니다. 이럴때 그나마 도움이 될 방법 몇가지를 소개해드리고자 합니다.
Test schedule을 도출해낼 때의 몇가지 관점
보통 테스트 일정을 산정할 때에는 몇가지 관점이 존재합니다.
- 테스트 대상의 구조 기반
- 테스트 케이스 기반
- 경험 기반
- 그 외...?
이번 포스트에서는 위 세가지 관점 중, 테스트 대상의 구조 를 기반으로 하여 테스트 일정을 산출해내는 방법에 대해 초점을 맞추어보고자 합니다.
Test schedule을 도출해낼 때의 필요한 요소
테스트 일정을 산정할 때의 두 가지정도 필요한 것이 있습니다.
바로 가정 과 경험 입니다.
특히, 처음 테스트하는 서비스/프로덕트 인 경우 실시이력이나 경험 등이 없기 때문에, 일정을 계산하는 모든 것을 가정할 수 밖에 없고 매우 조심스러워집니다.
테스트 일정은 대부분의 경우 비슷한 서비스/프로덕트 를 이전에 테스트한 내용으로부터의 경험을 바탕으로 도출되는 경우가 있습니다.물론, 이전 테스트는 몇일 걸렸으니 이번엔 몇일이다! 라는 방법은 틀립니다만, 일정 산정에 있어서 경험은 무시할 수 없습니다.
테스트 대상의 구조에 기반을 둔 관점
보통의 소프트웨어는 기능(feature) 에 기반하고 있으며, 그 기능들의 복잡도를 고려한 테스트 일정 산출 방법이 몇가지 있습니다.
PERT, The Program/Project Evaluation and Review Technique
계획(혹은 사업) 평가 및 재검토 기술(The Program/Project Evaluation and Review Technique)은 보통 퍼트(PERT)라고 불리며, 프로젝트 관리를 분석하거나, 주어진 완성 프로젝트를 포함한 일을 묘사하는 데 쓰이는 모델이다.
(중략)
한편 PERT의 특징을 보면 다음과 같다.① 주어진 계획을 완수하기 위하여 각 책임의 모두를 명세화, 사상과 활동을 포함하는 계획공정로(network)로 표시한다. 사상이라 함은 어떤 특수한 시점에서 특정된 계획의 성취를 나타낸다. 그리고 활동이라 함은 어떠한 사상(事象)에서 다음 사상(事象)으로 진행하는 데 필요한 시간과 자원을 나타내는 것이다.
② 사상과 행동은 어떤 논리적인 규칙에 의하여서 네트워크(network)라는 계획공정로로서 연속되고 있다.
③ 추정시간, 즉 각 활동에서 소요되는 시간은 3가지 방법으로 추정된다. 즉 낙관시간치(optimstic time：to), 정상시간치(most likely time：tm), 비관시간치(pessimistic time：tp)가 이와 관계가 있는 활동을 가장 잘 아는 사람에 의하여 추정(推定)되는 것이다.
④ 주공정(critical path)이 계산된다. 이것은 완성하기에 가장 긴 예상시간을 요하는 활동과 사상의 연속이라 할 수 있다.
PERT는 1958년에 고안된 오래된 방법이나, 지금도 충분히 참고할만한 방법입니다. 테스트 일정 산정에서는 3번, 3가지 방법을 이용한 추정방법을 주로 사용합니다.
일단 각각의 기능들을 아래 3가지 기준으로 일정을 대략적으로 산정합니다.
- 문제없이, 빠르게 진행되었을 때의 낙관값
- 현실적으로 생각했을 때 이 정도는 걸리겠다~ 싶은 표준값
- 최악의 경우에 이 정도는 걸리겠다~ 비관값
그리고 위 3가지의 기준으로 실제 테스트에 소요될만한 값인 기댓값 을 도출해냅니다.
계산 방법
기댓값은 아래와 같이 도출해냅니다.
- (낙관값 + 4 * 표준값 + 비관값) / 6
예를들어 쇼핑몰사이트의 테스트 일정을 도출한다고 해봅시다.
| Task | 낙관값 | 표준값 | 비관값 | 기댓값(MD) |
|---|---|---|---|---|
| 카테고리 기능 | 2 | 4 | 9 | 4.5 |
| 상품 기능 | 4 | 6 | 12 | 6.6 |
| 유저 관리 기능 | 3 | 5 | 10 | 5.5 |
| 매출 관리 기능 | 1 | 2 | 6 | 2.5 |
카테고리 기능의 테스트의 경우라면,
- (2+4*4+9)/6 = 4.5
가 되는 식입니다.
여기서 주의할 점으로는, 표준값을 낙관값과 비슷한 수치로 책정했기 때문에, 표준값에 대해 기댓값이 약 0.5MD 계산상 차이가 발생하고 있습니다. 이 계산값의 차이가 많이 나면 날수록, 실제 테스트 진행 시에 일정이 크게 뒤틀릴 수도 있으니 주의하셔야겠습니다.
전체 일정은, 이 기댓값들을 전부 더한 값이라고 말할 수 있겠습니다.
FP, Function Point
SW의 규모를 측정 및 예측하는 기법으로써 1979년 미국 IBM의 Allen J. Albrecht에 의해 제안되었다.
기능점수는 최초 SW개발 프로젝트의 규모측정(measurement)을 위해 고안되었으나, 현재는 SW공학적접근을 통한 다양한
방법으로 활용되고 있다. 그 적용범위를 살펴보면, 다음과 같다.
- SW 구매 및 생산성 벤치마킹
- 어플리케이션 SW 개발 비용 산정
- 어플리케이션 SW 유지보수 비용 산정
- SW계약에 관련된 소송
- IT아웃소싱 계약
- SW 엔지니어링 프로세스 개선 분석
- 품질비용 산정
- 품질측정
미국에 본부를 둔 IFPUG(International Function Point User Group )에서는 기능점수 분석 매뉴얼 제작 및 배포,
기능점수 관련 사용자그룹과의 교류를 통한 기능점수의 세계적인 확산을 담당하고 있다.
기능 점수, 펑션 포인트(function point)는 (제품이) 사용자에게 제공하는 정보 시스템의 비즈니스 기능의 양을 표현하기 위한 측정 단위이다. 소프트웨어의 기능 크기 측정(functional size measurement, FSM)을 계산하기 위해 기능 함수를 사용한다. 단일 단위의 비용(달러 또는 시간)은 과거 프로젝트를 통해 계산된다.
https://ko.wikipedia.org/wiki/%EA%B8%B0%EB%8A%A5_%EC%A0%90%EC%88%98
FP방법은 주로 소프트웨어의 크기를 계산하는데에 사용합니다. 각 기능별로 구현의 복잡도정도에 따라 점수 혹은 개발비용을 계산하는데요, 각종 일정 산정에서도 이를 응용하여 할 수 있습니다.
계산 방법
1. 테스트 대상을 기능 별로 나눈다.
| 대분류 | 중분류 | 소분류 |
|---|---|---|
| 계정 생성 | 전화번호로 인증 | SMS수신확인, 진행 확인 |
| 닉네임, 아이콘 설정 | ||
| 패스워드 설정 | ||
| facebook으로 인증 | facebook ID로 로그인하여 인증 | |
| 닉네임, 아이콘 설정 | ||
| 설정 | 계정 정보 | 전화번호 등록 및 변경 |
| 메일 주소의 등록 및 변경 |
등등...으로 나눕니다. 각 기능을 세부적으로 나눌때에는 되도록 같은 정도 / 단위로 나누는 것이 좋습니다.
2. 실시할 테스트 방법, 걸릴 것으로 예상되는 시간을 기재하고, 어떤 기능을 실시할 것인지를 확인한다.
여기서 시간의 기준은 프로젝트에 따라 임의로 정하시면 됩니다. 저는 1h를 기준으로 작성하여, 대강 0.25정도면 15분이 기준이 되겠습니다. 0.05정도면 약 3분정도겠네요.
| 대분류 | 중분류 | 소분류 | Testcase를 작성하여 실시 | 시간(h) | ad-hoc으로 실시 | 시간(h) |
|---|---|---|---|---|---|---|
| 계정 생성 | 전화번호로 인증 | SMS수신확인, 진행 확인 | 〇 | 0.05 | 〇 | 0.25 |
| 닉네임, 아이콘 설정 | 〇 | 0.05 | 〇 | 0.25 | ||
| 패스워드 설정 | 〇 | 0.05 | 〇 | 0.25 | ||
| facebook으로 인증 | facebook ID로 로그인하여 인증 | 〇 | 0.05 | 〇 | 0.25 | |
| 닉네임, 아이콘 설정 | 〇 | 0.05 | 〇 | 0.25 | ||
| 설정 | 계정 정보 | 전화번호 등록 및 변경 | - | - | 〇 | 0.25 |
| 메일 주소의 등록 및 변경 | - | - | 〇 | 0.25 |
시간을 기재하실 때, 실시기록이 없는 새로운 안건인 경우에는 어디까지나 대략적인 추정치가 되겠으나, 이전에 테스트한 이력이 있는 프로젝트이면서, 혹은 테스트했던 기능과 비슷한 기능이라면 과거 소요되었던 시간을 기재하셔도 됩니다.
3. 전체 테스트의 예상 소요 시간의 합계를 확인한다.
위 예시의 경우라면,
- testcase를 작성하여 실시하는 경우 : 합계 0.25h = 15m
- ad-hoc으로 실시하는 경우 : 합계 1.75h = 1h 45m
총 2시간이 소요된다고 보시면 됩니다.
Testcase에 기반을 둔 관점
테스트케이스의 숫자와 해당 테스트케이스를 실행해야하는 실행환경을 기반으로 한 관점이 있습니다.
계산 방법
- Testcase의 개수 : 100개
- 실행해야하는 환경(브라우저)의 개수 : Chrome, Firefox (총 2개)
- Ad-hoc : 하나의 브라우저 당 2시간 정도 소요된다고 가정
위의 경우, 실행해야하는 테스트케이스의 개수는 총 200개 입니다. 200개를 1명이 1시간 당 소화할 수 있는 테스트케이스를 20개정도라고 가정 한다면,
- 200개 / 20 = 10시간
Ad-hoc test 진행 시 하나의 브라우저 당 2시간 이므로, 총 4시간입니다.
즉 총 14시간정도가 필요하다는 계산입니다.
이라는 단순 계산이 나옵니다.
경험에 기반을 둔 관점
과거 진행한 테스트에서 얼마나 시간이 걸렸는지를 참고해가며 계산하는 방법입니다. 반복적인 테스트케이스의 실시나, 비슷한 유형의 기능을 테스트 할 시에 참고할 수 있을 것 입니다. 이 경우라면 좀 더 정확한 일정 산출이 가능합니다.
단, 이 방법을 위해서는 과거 테스트 실시 이력에 날짜를 기록하고 있어야겠습니다.
계산 방법
1. 과거 테스트 실시 이력에서 걸렸던 시간을 계산한다.
보통 계산할때는 하루에 몇개의 Testcase가 소화되었는지를 도출해냅니다. 또한 Bug Tracking System(BTS)에 bug를 등록한 개수도 확인합니다. 보통 등록일로부터 유추해낼 수 있습니다.
2. 실시 예정인 테스트케이스에서 비슷한 기능/테스트케이스 들이 있는지 확인하고, 이전 실시했던 테스트케이스의 총 갯수에서 얼마만큼 줄어들고 늘어났는지 확인한다.
이전 테스트 이력을 참고하여, 금번 실시예정인 테스트케이스에서, 이전 테스트케이스의 증감분을 고려하여 소요 일정을 계산해나갑니다.
이 때 BTS에 등록한 bug ticket의 개수도 고려해야합니다.
그 외 계산방법?
그 외로는 아주 단순하게, 서비스 / 프로덕트 Release 예정 시점과, Test가능 시점을 확인하여 도출된 Test가 가능한 전체 일정으로 총 Testcase의 수를 나누는 것입니다.
가령, Test가능 일정이 총 10일이고, 총 testcase의 수는 1000개 (실행해야하는 브라우저 및 환경을 모두 합하여 계산한 값)이라고 하였을 때, 하루에 100개의 testcase를 소화해야하고, 여기서 다시 QA/Test 팀의 총 인원으로 나누어 주어 계산할 수 있을 것 입니다.
| Day 1 | Day 2 | ・・・ | Day 10 (Test Sign-off target) | |
|---|---|---|---|---|
| 일당 실시 건수 | 100 | 100 | 100 | |
| 누적 실시 건수 | 100 | 200 | 1000 |
잊지말아야할 것
Issue 해결에 걸리는 시간
위 일정계산을 한 후에, 반드시 아래 사항을 고려해야합니다.
- Bug 등, 서비스/프로덕트 내부 등, 내적요인에서의 issue가 발생하였을 때, 해당 내용을 수정하고 재확인하는데 걸리는 시간
- 실행환경, 서버(하드웨어) 등의 외적요인으로부터 발생한 issue를 해결하는데 걸리는 시간
보통 Bug 등을 수정하고, 재확인하는데에 필요한 일정으로는, 전체 일정의 약 15%정도를 추가로 더하곤 합니다. 이 Bug 수정에 걸리는 시간은 테스트 대상의 규모나 복잡도에 따라 유연하게 생각하셔야겠습니다.
전체 일정이 아니라 각 기능별 / 테스트케이스 건별로 추가 시간을 계산해내기도 합니다. 즉 방법은 천차만별입니다.
외적요인으로부터 발생한 issue를 해결하는데에 걸리는 시간은 좀 더 걸리기도 합니다. 외적요인으로 인한 issue가 우려되는 경우에는 +1MD 정도를 더하여 계산합니다.
고려하는 기준이나 고려하는 시간은 조금씩 다르나, 어찌되었던 Bug를 포함한 issue 수정을 위한 추가 일정을, 전체 테스트일정에 고려해야한다는 점입니다.
예상된 일정보다 빨리 끝내면 좋은거고, issue가 터져도 여유 일정 덕분에 조금은 안심할 수도 있을 것 입니다.
테스트 담당자의 테스트 외의 업무
테스트 담당자가 테스트 외의 업무로 인하여, 테스트에 집중할 수 없을때에도 어느정도의 시간을 고려해주어야 합니다.
가령, 테스트 담당자가, 테스트가 진행되고 있지만 동시에 다음 version에 대한 테스트케이스를 작성해야한다던지, 다음 version의 spec review 회의에 참여한다던지 한다면, 그 시간만큼은 테스트를 할 수 없는 것입니다.
때문에 테스트 담당자의 테스트 기간 중, 업무를 확인하고 테스트 일정을 고려해야합니다.
이렇게 많은 내용을 알아보았습니다. 릴리즈 / 공개일정을 정해놓지 않고 일을 진행하면 참 좋을텐데, 아쉽게도 그런회사는 정말 별로 없습니다. 테스트 혹은 개발 일정 산출하실 때 꼭 도움되면 좋겠습니다.
Ref
