책 요약정리 – 한 페이지 테스트 계획서 by Nguyen

출처: Testing Applications on the Web, 저자 Hung Q. Nguyen, 2001년

6장 테스트 계획하기 기초(Test Planning Fundamentals), 113~147 페이지

 

테스트 계획(Test Planning)

테스트 계획은 개발 일정, 자원 가용성, 회사 재정, 시장 압력, 품질 리스크, 경영진의 변덕 같은 다양한 요인에 영향을 받는 점진적인(evolutionary) 프로세스이다. 테스트 계획은 정보의 수집 및 분석에서부터 시작한다. 먼저 테스트 대상 제품을 철저하게 검토하고, 일정과 목적을 고려하고, 자원(resources)을 평가한다. 모든 관련 정보가 종합된 후에 테스트 계획을 시작한다.

 

테스트 계획서(Test Plans)

테스트 계획서는 프로젝트를 위한 테스팅 노력을 상세화 한 문서이다. 테스팅 일정, 가용한 테스트 자원, 테스트 타입, 테스트 프로젝트에 관여하게 될 사람 등을 자세히 기술하며, 모든 의도된 테스트 요구사항 및 프로세스도 명확하게 기술한다. 테스트 계획서가 테스트케이스, 예상 결과, 통과/실패 기준 같은 아주 상세한 사항들을 포함하는 경우도 간혹 있다.

 

관련자들이 테스트 계획서를 읽는다는 가정에서(현실은 그렇지 않은 경우가 많음) 테스트 계획서가 테스트 프로젝트의 구조(structure)를 제공하고 팀 구성원 간 의사소통을 향상시킴으로써 테스팅을 지원하는 역할을 한다.

 

안타까운 현실은 대부분의 테스트 계획이 테스트 프로세스 동안 읽히지 않고 방치되기 일쑤라는 사실인데, 테스트 계획서가 너무 길어서 읽기 힘들고 매일매일의 버그 찾기 노력에 그다지 도움이 안되는 정보들로 빽빽하기 때문이다. 누군가 테스트 계획서를 읽는다 하더라도 이게 정기적으로 갱신(일정, 작업 위임, 테스트 커버리지 등에 대한 현재 변경 사항을 반영)되는 경우가 드물다.

 

테스트 계획서 템플리트

소프트웨어 테스팅 업계에서 사용하는 표준 테스트 계획서 템플리트는 “ANSI/IEEE Standard 829-1983 for Software Test Documentation”이다. 이 IEEE 표준은 테스트 문서에 포함할 수도 있는 문서 유형(예, 테스트케이스, 기능 목록, 플랫폼 매트릭스)을 정의하고, 또한 표준 테스트 계획서가 포함해야 할 구성 요소들도 정의한다.

 

LogiGear 한 페이지 테스트 계획서

LogiGear의 한 페이지 테스트 계획은 전통적인 테스트 계획이 겪는 문제를 피하기 위해 읽기와 갱신이 더 쉽도록 특별히 설계되었다. 이 “태스크 지향적(task-oriented)” 계획서가 오로지 테스팅 태스크만을 나열하는데, 생산팀 일부 구성원은 "테스트 접근 방식"이나 "테스트 제외 기능" 같은 것에 관심이 없고 그들이 알고자 하는건 단지 무엇이 언제 테스트되는지 뿐이기 때문이다. 한 페이지 테스트 계획은 읽고 참조하기가 매우 쉽기 때문에 자신의 업무 프로세스에 적합하다고 생각하면 참을성 없는 작업자들도 이를 무시할 가능성이 적다.

LogiGear 한 페이지 테스트 계획은 추가 작업의 필요 없이 표준 테스트 계획 노력의 가장 중요한 부분만을 추려서 쉽게 소화 가능한 형식으로 제공한 것이다. 테스팅 팀이 완료해야 하는 테스팅 태스크, 태스크가 수행되어야 하는 횟수, 각 테스팅 태스크가 요구하는 시간 추정치, 소프트웨어 개발 프로세스 중 어느 시기에 태스크가 수행되어야 하는지에 대한 대략적인 아이디어를 제공한다.

 

한 페이지 테스트 계획 개발 프로세스

1 단계: 테스팅 태스크 정의(Test Task Definition)

표준 테스트 타입을 검토하고 프로젝트(테스트 대상 시스템)가 필요로 하는 테스트 타입을 선택한다. 어떤 테스트 타입이 필요한지 정확하게 결정하려면 개발자와의 토론, 시스템 컴포넌트 분석, 테스트 타입에 대한 이해 등이 필요하다.

 

2 단계: 태스크 완료 시간(Task Completion Time)

테스트를 수행하는 데 필요한 시간을 계산한다. 완료 시간 추정에 자원(하드웨어, 소프트웨어, 테스트 툴, 인적 자원, 아웃소싱 등) 가용성 평가가 수반되어야 한다.

 

테스트 계획 준비에서 가장 어려운 측면이 테스트 스위트를 완료하는데 걸리는 시간을 추정하는 일이다. 신규 테스터이거나 또는 숙련된 테스터이지만 새로운 테스트를 해야 하는 경우 시간 추정에 많은 어림짐작(guesswork)이 필요하다. 가장 일반적인 전략은 “분할 및 정복(divide and conquer)”인데, 태스크를 시간 추정이 더 쉬운 작은 서브태스크로 나누고 이 서브태스크 추청치를 다시 종합하는 방법이다. 테스팅 태스크가 과거 프로젝트의 작업과 유사한 경우 정보에 입각한 추정치에 도달 할 수도 있다. 만약 유사한 과거 테스트의 시간 기록이 가용하지 않다면 추정치가 비현실적 일 수 있는데, 한 가지 해결책은 일련의 초기 테스트가 완료된 후 테스트 계획을 갱신하는 것이다.

 

만일의 사태 또는 누락된 태스크 보완을 대비하여 20%의 예비 시간이 테스트 계획에 포함된다. 테스트가 진행됨에 따라 발생하는 프로젝트 일정의 불가피한 변경이 20% 예비 시간으로 커버되지 않는 경우 태스크 완료 시간(the task completion time)을 재협상 해야 할 필요가 있다.

 

3 단계: 테스팅 태스크를 프로젝트 빌드 일정에 따라 배치

테스팅 태스크 목록을 만들고 테스트 시간 추정을 하고 나면 이 태스크들을 프로젝트 계획에 따라 배치한다(개발 팀이 제공한 빌드 일정에 기반).

 

개발 동안 테스트가 실행되는 횟수를 결정한다. 예를 들어, 문서화 테스트(documentation testing)는 한 번만 수행하거나 또는 예비 단계에서 한 번 검토하고 모든 편집이 완료된 후 다시 검토하도록 계획한다. 기능 테스트(functionality tet)의 전 사이클이 개발 단계 당 한 번씩(또는 두 번씩) 실행되도록 계획한다. 승인 테스트(acceptance test)는 매 빌드마다 실행한다. 전체 버그 회귀 테스트(full regression test)는 단계 당 한 번씩(oncec per phase), 부분 회귀 테스트(partial regression test)는 각 빌드마다 발생하도록 계획한다.

 

4 단계: 시간 추정치 계산

표의 숫자들을 곱하고, 개발 단계별 테스트 시간 총계를 계산하며, 이를 종합하여 프로젝트에 필요한 총 테스트 시간 추정치를 구한다. 관리 작업에 필요한 시간도 추가한다(예, 테스트 계획 작성/갱신, 테스트케이스 생성, 버그 데이터베이스 관리, 직원 교육 등에 쓰는 시간)

 

5 단계: 전체 리소스 요구사항 계산

알파 단계에 필요한 총 테스트 시간을 알파 단계의 총 주 수로 나눈다. 이 결과를 주 당 30 시간으로 나누면 그 주에 필요한 테스터 수를 알 수 있다(하루 8시간 일 한다고 했을 때 한 주의 업무 시간이 총 40시간이지만, 경험상 풀타임 테스터가 주 30시간을 테스팅에 쓰고 나머지 10시간은 미팅, 교육, 결함 보고/추적, 연구 등의 기타 업무에 소비함). 예를 들어, 알파 단계가 4주 간이고 필요한 총 테스트 시간이 120시간 이라면 오로지 한 명의 알파 테스터만 있으면 된다. 즉, (120 ÷ 4) ÷ 30 = 1 

이 동일한 프로세스를 베타 단계나 프로젝트 관리에 대한 추정치를 계산하는데도 적용한다.