CONFIDENTIALITY/SECURITY WARNING
이 문서에 포함되어 있는 정보는 313 DEV GRP의 자산이며, 313 DEV GRP의 서면 허락 없이 사용되거나, 재 가공 되거나, 외부로 반출 할 수 없습니다.
이 문서에 대한 열람 및 보관할 수 있는 사람은 분실, 도난, 반출에 대한 책임을 자동 승계하는 것에 대하여 동의하는 자에 한 합니다.
문서정보
Draft Edit
marked by 이동민/연구혁신팀 on 2월 20, 2018 16:30
프로젝트명 / 버전
Project Name / X.X.X.X(BuildXXX)
소속/ 작성자
소프트웨어개발실 / 홍길동 수석연구원 '@를 적고 사용자 이름을 적으세요'
DOCS 내 모든 문서의 생성, 열람, 편집은 시스템 로그에 기록/관리되며, 문서의 중요도가 높은 문서는 열람, 편집을 제한해야 하는 경우 페이지 제한 기능 이용 가능
목 차
본 문서의 개요를 적는다.
본 문서의 목적 및 내용, 본 문에서 언급하고 있는 테스트의 목적을 간략히 설명한다. 하나의 프로젝트 전 과정에서 진행되는 테스트는 여러 종류가 있을 수 있다. 그러나 특정 목적의 테스트(예를 들어 BMT)는 목적이 분명하다.
본 문서의 대상이 되는 시스템, 소프트웨어 또는 서비스를 테스팅해야 하는 배경에 대해서 기술한다
본 문서에 기술되는 테스팅의 범위를 기술한다.
본 테스트에 투입되는 인력을 기술한다.
본 테스트를 진행함에 있어서 필요한 일정 계획을 작성한다.
테스트 일정 계획 | |||||
항목 | 시작일 | 종료일 | 기간 | 담당자 | 리뷰어 |
SRS 분석/리뷰 |
|
|
|
|
|
TP작성 |
|
|
|
|
|
TP리뷰 |
|
|
|
|
|
TDS 작성 |
|
|
|
|
|
TDS 리뷰 |
|
|
|
|
|
TCL작성 |
|
|
|
|
|
Alpha Test(Cycle1) |
|
|
|
|
|
Beta Test(Cycle2) |
|
|
|
|
|
RC Test(Cycle3) |
|
|
|
|
|
RTM |
|
|
|
|
|
Inside Live Test |
|
|
|
|
|
QA확인서 |
|
|
|
|
|
합계 |
|
|
|
|
|
본 문서 작성을 위해 참고하는 관련 문서 목록(Testing Basis)를 기술한다.
시험할 항목들을 적는다. Test Plan에서는 개개의 기능을 언급할 필요는 없으며, 어떤 대상을 테스트 대상으로 할 것인지, 특별히 고려할 하드웨어적인 특성 등을 적는다.
테스트에 고려되는 소프트웨어적인 특성이나 조합들을 명시한다.
테스트에 제외되는 특성이나 조합, 제외하는 이유를 명시한다. 테스트에서 고려할 수 있는 사항 중에서 제외한다고 명시하지 않으면 "당연히 테스트되어야 하지 않느냐?"라는 질문을 받을 수 있으므로 명확하게 해주는 것이 필요하다.
각 주요 테스트별로 전략을 명시한다. TCL을 기반으로 하는 테스트와 탐색적 테스트, 여러 품질 특성을 테스트하는 전략들을 고려한다.
각각의 기능 항목의 Pass/Fail을 모두 적을 필요는 없다. 프로젝트 또는 이 계획서에서 의도하고 있는 테스트의 "Pass/Fail" 을 판단하기에 적합하다고 생각되는 기준들을 명시한다.
이 기준이 특별히 필요한 경우에는 BVT를 테스트 진입 절차의 Critical Path로 정했을 때, BVT는 Pass/Faill 의 판단 기준이 필요하다. BVT 케이스를 100% 통과해야 하는지 등을 정해 두는 것이다.
알파나 베타와 같은 마일스톤의 통과 기준 역시 마찬가지이다. 진입 기준으로 BVT로 한다면 종료 기준은 무엇인지 미리 정해 두는 것은 테스트를 진행할 때 많은 도움이 된다.
각각의 테스트하는 것이 의미가 없거나 테스트가 불간으할 경우가 발생할 수 있다. 어떤 경우에 테스트가 중지될 수 있고, 어떤 조건을 충족시켜야 중지된 테스트가 다시 시작될 수 있는지 명시한다.
예를 들어 위의 "6. 성공/실패 판단 기준"에서 언급하고 있는 기준에 명시되어 있는 내용이 있거나, 개발팀과 QA간에 사전 합의된 "BVT"를 테스트용 버전이 통과하지 못했을 때(이 경우 테스트를 중지할 수 있다고 사전에 합의되었다는 전제하에), 더 이상 테스트를 진행할 수 없는 심각한 버그("Block")가 발생했을 경우 등등이 있을 수 있다.
주의할 점은 각 프로젝트의 성격에 따라서 기준은 달라질 수 있기 때문에 각 프로젝트에서 그 기준을 정해서 개발팀의 동의를 사전에 얻는 것이다.
테스트는 전체가 중지될 수도 있고, 일부 항목에 대해서만 중지될 수도 있다. 예를 들어 "성능"이라는 테스트 항목을 테스트하기 위해 충족되어야 되는 최소한의 요구 조건이 사전에 정의되어 있는 경우 그 조건을 충족하지 못한 테스트 버전인 경우에 "성능" 테스트는 중지되지만 다른 테스트들은 진행한다는 의미이다.
"Show Stopper"로 판단할 수 있는 경우를 명시한다.
일시 중지는 2가지 형태가 있다. 하나는 전체 테스트가 중지되는 경우가 있고, 특정 테스트 영역만 중지되는 경우가 있을 수 있다.
테스트가 중지되는 이유는 대체로 테스트를 진행할 수 없을 정도로 심각한 버그들이 많아서 테스트에 의미가 없을 경우가 있을 수 있고, 다른 이유로는 특정 기능이 동작하지 않아서 이후 테스트가 불가능하기 때문일 수 있다.
예를 들어 설치가 되지 않는 경우에는 전체 테스트를 중지할 만한 사유가 될 수 있고(설치가 안되면 어떤 테스트도 할 수 없으니), 엔진이 동작하지 않는다면 바이러스 관련된 기능 전체가 테스트를 중지할 수 밖에 없다.
테스트가 "일시 중지"가 된 경우 이를 재개하기 위한 기준을 명시한다.
테스트의 산출물은 각종 문서와 테스트에 사용되는 데이터이다. 어떤 것들이 있는지 명시해야 한다. 그 산출물들은 만들어 내는 것은 다음의 "9. 태스크 및 수행 계획"에 명시하면 된다.
테스트 과정에서 작성될 문서를 모두 명시한다. 프로세스에 정의된 필수 산출물이 아니라 하더라도 해당 프로젝트에서 테스트를 위해서 작성할 문서들은 모두 명시한다.
테스트를 위해서 준비되는 데이터들이 있을 수 있다. 예를 들어 AV엔진의 경우 바이러스 파일 샘플이나 정상 파일 샘플 등이 준비되어야 한다. 데이터베이스 기반으로 동작하는 제품인 경우에 데이터베이스에 일정량의 데이터가 있어야 제대로된 테스트가 가능하다. 이런 데이터들을 준비하고 유지하는 것 자체가 모두 시간과 노력을 필요로 하는 것이다. 어떤 데이터가 준비되어야 하는지도 정의한다.
문서나 시험용 데이터의 보관 위치를 정해 둔다. 회사에 표준적으로 사용되는 시스템이 있다면 그 시스템을 그대로 이용하는 것으로 충분할 수 있다.
일반적으로 사용되는 WBS(Work Breakdown Structure)를 기초로 하여 일정과 수행자까지를 명시하면 된다. Task 자체만으로는 실제로 무엇을 해야 할지 파악하기 어려운 경우에는 breakdown해서 실제 수행할 수 있는 Activity들을 도출해야 하고, 그 Depth는 하나의 Activity의 수행기간이 1일이 넘지 않도록 하는 것이 좋다.
필요한 하드웨어와 하드웨어의 구성에 대해서 명시한다. 가능하다면 조달 방법도 정해 두는 것이 필요하다.(구매가 외부에서 조달해야 하는 것들과 그 시기는 때로 테스트 일정 지연의 요인이 되기도 한다.)
사용될 운영체와 필수 소프트웨어들을 명시한다. 예를 들어 메일 보안 소프트웨어일 경우 메일 서버가 필요할 것이다. 또한 이 소프트웨어들의 조달 방법 역시 정해두어야 한다.
커뮤니케이션 방법이 프로젝트마다 모두 다른 것은 아니다. 그러나 다시 한번 분명히 해두는 것이 필요하다. 예를 들어 산출물은 어떤 내용은 메일을, 어떤 내용은 형상 관리 시스템에 산출물을 업로드하는 것으로, 또 Bug들은 어떤 방법으로 보고하고 변경 내역들을 관리할 것인지 등을 정해둔다.
특히 여러조직(또는 회사)의 사람들간에 협업할 때 커뮤니케이션 방법을 분명히 해 두는 것은 매우 중요하다.
테스트에 필요한 툴이 있다면 적는다. 예를 들어서 샘플 데이터를 생성하기 위한 별도 툴이 필요하다든지 하는 내용들은 적어둘 필요가 있다. 이 도구들은 테스트 자체에 직접 사용되지는 않지만, 테스트를 준비하거나 결과를 분석하거나 등의 용도로 사용될 수 있다.
테스트에 관련되는 구성원들을 명시한다. 그 숫자와 각각의 역할을 분명히 해두어야 한다. 구성원 중에 별도의 교육을 필요로 하는 사람이 있다면 그 내용도 적으며, 비용이 발생할 것이라면 그것 역시 고려한다.
테스트가 진행되는 도중에 위험을 발생시킬 수 있는 내용들이 있다. 예를 들어 네트워크 장비를 실제 업무용 네트워크에서 온라인으로 설치하여 테스트를 수행할 경우에는 장비로 인해 전체 네트워크나 일부 네트워크에 장애가 발생할 수 있다. 운영중인 서버를 실제 테스트에 이용해야 하는 경우에는 테스트로 인해 발생한 부하 때문에 업무에 지장을 줄 수 있다. 그 외에 바이러스는 언제든지 전염될 위험이 있다.
이런 위험 요소들을 제거하거나 방지하기 위한 대책들을 함께 기술한다. 네트워크 장비는 별도의 테스트 망을 구성해서 테스트한다든지, 업무 시간을 피해서 테스트를 진행한다든지 등 각 위험요소마다 대책들은 준비되어야 한다.