테스트 계획서는 구축의 총괄적인 테스트 전략과 프로젝트 기간 중에 수행될 모든 테스트 활동의 범위, 절차, 요구되는 계획 일정에 대하여 기술하는 문서입니다. 테스트 계획서 작성의 목적은 시스템 검증, 결함발견, 기능 중심의 컴포넌트 테스트와 통합테스트, 통합테스트를 통해 분석단계에서 도출한 현업요구사항 및 설계 사양을 시스템이 만족하는지를 검증합니다. 또한 연계 시스템 간의 인터페이스 기능이 정상적으로 수행되고 있는지를 검증합니다. 오늘은 테스트 종류, 테스트 조직 및 역할, 테스트 절차 및 통합테스트의 중요성에 대해 알아보도록 하겠습니다.
다음은 행복재단에 그룹웨어를 납품하여 테스트한다는 가정하에 작성된 내용입니다.
첫째, 시스템 개발 범위(scope)에 큰 변동이 없는 것을 가정합니다. 즉 요구사항 정의서에 정의된 개발 범위를 준수하는 것을 가정합니다.
둘째, 상세일정표 상의 일정에 따라 개발이 진행되는 것을 가정하여 단위, 통합 및 인수테스트 일정을 계획합니다.
셋째, 행복재단그룹웨어 시스템 테스트 시 운영 환경에서 테스트가 가능한 것을 가정합니다.
넷째, 행복재단그룹웨어 시스템 재구축 요구사항정의서에 정의된 개발 범위로 진행하며 범위 외의 추가 사항에 대해서는 별도로 내용을 정리합니다.
행복재단그룹웨어 구축을 위해 테스트해야 하는 H/W, S/W 및 연계 시스템은 본 사업에서 도입되는 H/W, S/W 및 솔루션 전체로 합니다.
도입된 운영시스템에서의 테스트를 원칙으로 하되 환경적인 이유로 인해 단위테스트의 경우 개발서버를 사용할 수도 있다. 불가피한 경우는 행복재단그룹웨어 프로젝트 개발서버에서 테스트합니다.
테스트 범위는 구축되는 행복재단그룹웨어 시스템의 기본 공통 기능과 요구사항 정의서에 기술된 개발 범위를 대상으로 합니다. 단, 타 시스템 연계 테스트는 개별 업무의 통합 테스트 시 수행합니다.
테스트 종류는 단위테스트, 통합테스트, 시스템테스트, 인수테스트가 있으며, 아래 사항은 각 종류에 대한 테스트 방법입니다.
종류 | 테스트 방법 |
단위 테스트 |
행복재단그룹웨어 시스템 단위테스트는 시스템 개발자가 테스트 케이스 단위를 설정하여 테스트를 수행한다. 테스트 후 처리하지 못하고 남아있는 사항들은 결함내용에 반영한 후 결함내용을 수정 보완한다. |
통합 테스트 |
통합테스트에서는 기능 통합적 관점에서 테스트를 수행한다. 각 기능별 및 사용자와 관리자 영역별로 전반적 업무 흐름을 테스트 한다. 신규 어플리케이션 프로그램들 간의 인터페이스를 테스트하여 연동기능이 수행되는지 검증한다. 통합 기능테스트는 단위테스트를 통해 시스템의 단순 결함들이 걸러진 후 이루어지며, 각 개발팀 개발/담당자가 통합된 기능을 테스트한다. |
시스템테스트 | 시작기준 * 시스템테스트는 시스템 이슈(서버/상용SW Upgrade, Patch 적용 등)의 시스템 전체의 기능요구사항에 대한 검증이 필요한 경우 진행 * 시스템 이슈 발생에 따라 전체 시스템의 기능요구사항에 대한 테스트 요청 종료기준 * 고객의 시스템테스트 결과에 대한 승인 * 테스트한 결과 결함이 발견되지 않음 |
인수 테스트 |
검사기준서에 요구사항과 관련한 화면을 캡쳐한 증적 내용을 보고 요구사항에 부합되었는지 고객사 담당자가 확인한다. |
테스트 조직은 수행사 PM과 IT 운영처와 콘트롤 타워가 되어 협의를 진행하며, 수행사PM의 총괄 지휘하에, 개발자, 품질관리자, 테스트지원인력이 각 역할별로 업무를 담당하게 됩니다.
다음은 각 역할별 수행 내역을 작성한 것입니다.
역할명 | 역할 | 담당자 |
총괄 | - 총괄 테스트 계획 수립 - 테스트 활동의 전반적인 관리 및 조정 - 테스트 관련 이슈 사항 모니터링 및 해결 지원 - 테스트 계획 대비 진행상황 체크 - 테스트 산출물 관리 |
이OOPM |
IT운영처 | - 개발팀에서 진행한 테스트 프로그램에 대하여 확인 - 개발팀에서 진행한 통합테스트 확인 |
김OO부장 |
개발자 | - 단위테스트 시나리오 작성 - 개발자 테스트 완료한 프로그램 단위테스트 수행 - 통합테스트 시나리오 작성 및 테스트 수행 - 시스템 테스트 지원 |
강OO부장 최OO부장 |
QA/테스트지원 | - 테스트 환경구성 - 기능 테스트 수행 - 테스트 결과서 작성 |
수행사 테스트 지원팀/QA |
테스트 단계별 담당 및 승인자
각 테스트 단계별 담당자와 승인자는 각각 다르며, 아래와 같이 나뉘어 집니다.
테스트 단계 | 담당자 | 승인자 |
단위테스트 | 개발자, 연구소(본사 연구소 개발 기능일 경우) | 사업 PM |
통합테스트 | 개발자, 설계자 | 사업 PM |
시스템테스트 | 수행사 테스트 지원팀/QA | 사업 PM |
인수테스트 | 고객 담당자 | 고객 승인자 |
테스트 절차 및 계획은 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트별로 수행 절차와 테스트 승인기준, 예외사항 등에 기술합니다.
구분 | 단위테스트 | 통합테스트 | 시스템테스트 | 인수테스트 |
일정 | 개발된 프로그램에 대하여 수시로 실시 | 상세일정표에 맞게 통합테스트 실시 | 상세일정표에 맞게 시스템테스트 실시 | 상세일정표에 맞게 인수테스트 실시 |
테스트 대상 | 모듈, 단위기능 | 개발된 모듈간의 인터페이스, 연계 연동 기능 | 성능, 보안 및 품질 요구사항 | 요구사항 충족성 |
목적 | 단위 모듈이 프로그램 명세서의 기능에 부합되는지 검증 | 업무흐름, 연계연동 검증 | 성능, 보안, 품질 테스트 | 요구사항에 맞게 시스템이 예상대로 작동하는지 확인 |
담당자 | 개발자 | 개발자, 설계자 | 수행사 테스트 지원팀/QA | 고객(사용자) |
기준선 | 프로그램 명세서 | 요구사항정의서 | 요구사항정의서 | 요구사항정의서 |
테스트 환경 | 개발환경 | 개발환경/운영환경 | 개발환경/운영환경 | 운영환경 |
테스트 시 기본적으로 준수해야 할 기본적인 절차를 다음과 같이 정의합니다.
1) 테스트 환경 구성
2) 테스트 수행
3) 테스트 결과 반영 및 보고
테스트 완료 후 단계별 테스트의 종료에 대한 승인 기준을 정의하고, 각 단위시스템의 테스트 조직에서는 다음과 같은 경우 테스트를 종료합니다.
기계 또는 소프트웨어적인 오류에 의해 테스트를 중단해야 할 경우에 대해 기술합니다. 중단 후 재개 할 경우에 대한 요구사항도 기술합니다.
다음은 중단기준과 재개 시 요구되는 사항에 대한 내역입니다.
중단 기준 | 재개 시 요구사항 |
테스트 케이스가 잘못 들어가 시스템에 무리를 줄 경우 | 테스트 케이스 수정 및 보완 후 해당 단위테스트를 재 수행 한다. |
시스템이 무한 loop을 돌 경우 | 원인 파악 및 문제점 해결 후 중단이 되게 했던 테스트 케이스부터 테스트를 재개한다. |
시스템 이상으로 시스템 테스트 시 사용자 입력을 받아 들이려 하지 않을 때 | 원인을 찾아내어 문제점 해결 후 시스템 테스트를 다시 수행한다. |
단위테스트는 기능단위의 프로그램 모듈에 대한 테스트를 말합니다. 다음과 같이 단위테스트가 달성해야 할 목표를 정의합니다.
단위테스트를 수행하기 위한 상세 절차는 다음과 같습니다.
단위테스트 성공에 대한 완료기준은 다음과 같이 정의합니다.
단위테스트 수행 시 필요한 자원이나 협조사항, 테스트 시 제약 사항 등을 조사하여 개발팀이 작성하도록 합니다. 테스트 방법에 대한 자세한 지침은 단위테스트 케이스를 참조합니다.
통합테스트는 단위 테스트를 통해 단위 프로그램 별 업무 처리 기능과 데이터 처리 기능이 검증된 단위 프로그램에 대해 통합 시나리오에 따라 업무 흐름을 중심으로 정확히 실행되는가를 종합적으로 검증하는데 그 목적이 있습니다.
통합테스트가 달성해야 할 목표는 다음과 같습니다.
통합테스트를 수행하기 위한 상세 절차는 다음과 같습니다.
통합테스트 성공에 대한 완료기준은 다음과 같습니다.
통합테스트 수행 시 필요한 자원이나 협조사항, 테스트 시 제약사항 등을 조사하여 현업과 협의하여 작성하도록 합니다. 테스트 방법에 대한 자세한 지침은 통합테스트 시나리오를 참조합니다.
시스템테스트는 시스템 운영 전에 실제 운영 시스템의 환경을 구성하고 시스템의 정상적인 서비스 확인을 위한 성능평가를 실시하고 추가 보완사항을 도출하여 서비스에 지장을 줄 수 있는 요인들을 제거하는데 그 목적이 있다.
시스템테스트가 달성해야 할 목표는 다음과 같습니다.
시스템테스트를 수행하기 위한 상세 절차는 다음과 같습니다.
시스템 테스트 성공에 대한 완료기준은 다음과 같습니다.
시스템 테스트 수행 시 필요한 자원이나 협조사항, 테스트 시 제약 사항 등을 조사하여 수행사 테스트 지원팀/QA이 작성하도록 합니다.
인수테스트는 개발 결과물을 사용자가 인수하기 전에 요구사항대로 시스템이 구현되고, 기능이 예상대로 동작하는지를 최종 확인하는 테스트입니다.
다음은 인수테스트를 수행하기 위한 상세 절차를 기술한 것입니다.
인수 테스트 성공에 대한 완료기준은 다음과 같습니다.
테스트 수행 시 필요한 자원이나 협조사항, 테스트 시 제약 사항 등을 조사하여 현업과 협의하여 작성하도록 합니다. (단, 단납기 일때는 별도의 인수테스트는 실시하지 않고 검사기준서의 증적을 검토 승인하는 걸로 대체합니다)
다음은 테스트 준비, 테스트 시나리오 작성, 테스트 실시, 테스트 결과의 단계별 활동과 내역을 구분한 내용입니다.
활동 | 내용 | |
테스트 준비 |
1. 시스템 사용목적 및 개발전략을 검토하여 인수테스트 방안을 정함. 2. 인수기준서를 근거로 인수테스트방안을 정하여 이를 근거로 점검기준을 정하고 점검기준을 근거로 테스트기법을 정함. 3. 인수테스트 방안 및 인수테스트기법에 따라 인수테스트 시나리오를 작성함. 4. 인수테스트시나리오에 따라 인수테스트 사례 및 테스트자료를 준비함. 5. 인수테스트절차에 따라 인수테스트시나리오, 테스트사례을 기준으로 인수테스트시기 및 환경을 정의함. 6. 시스템 사용목적 및 개발전략을 추적할 수 있도록 인수테스트대상/일정/환경 준비/조직 등의 인수테스트계획(절차 포함)을 정함. 7. 테스트계획을 발주자, 개발자 등의 이해관계자와 검토하고 확정함. |
- 인수테스트를 위한 사용자 교육이 이행되고 업무별 담당자는 시스템을 이해하고 있는가를 확인함 -인수테스트시나리오/사례/자료 준비에 사용자(담당자)가 충분히 참여했는가를 확인함 -인수테스트 개시 전에 단위, 통합, 시스템 테스트 결과를 담당자가 충분히 숙지하고 있는가를 확인함 |
테스트시나리오 |
1. 정보관리: 권한별 정보생성/변경/삭제 및 조회 2. 기능 사용: 포털/메일/게시판/전자결재/문서보안 등 그룹웨어 가동에서부터 업무마무리까지 기능 확인 3. 정보연계: 실시간 연계로 정보무결/정확성 유지 |
모든 요구사항 그리고 컴포넌트 및 인터페이스를 테스트의 대상으로 함 |
테스트실시 |
1. 인수테스트 조건을 달성하고 있는가를 확인함 2. 인수테스트계획에 따라 업무별 테스트담당의 주관으로 인증환경(모의운용환경도 가능)에서 인수테스트를 실시함. 3. 인수테스트 시나리오, 사례, 자료를 통하여 테스트 수행에 따라 발견된 오류수정 및 재테스트를 실시함. |
인수테스트결과를 평가 기준에 따라 확인하고 오류 시에 이전 단계 테스트(시스템 테스트 등) 결과와 비교/점검/확인함 |
테스트결과 평가 |
1. 인수테스트계획서/수행보고서를 분석하여 인수테스트결과를 요약함. 2. 인수테스트결과를 검토하여 승인여부를 정리함. |
시스템 인수 여부를 결정할 수 있는 수준으로 테스트결과가 정리되어 있는가를 점검함 |
테스트 진행 일정은 고객과 협의하여 최종 일정을 확정합니다. 일반적으로 단위테스트는 개발이 끝나는 중간중간 실시를 하며, 단납기일때는 생략하는 편입니다. 통합테스트는 시스템 테스트 전이나 가오픈전에 주로 실시를 하며, 시스템 테스트는 오픈전에 실시를 합니다. 최종적으로 인수테스트를 통해 검수를 수행합니다.
활동 | 세부 작업 | 일정 | 담당자 |
단위테스트 | - 단위 테스트 케이스 작성 - 테스트 방법 및 절차 교육 - 단위 테스트 수행 - 단위 테스트 결과서 작성 |
개발 완료 후 | 개발자 |
통합테스트 | - 테스트 시나리오 작성 - 테스트 방법 및 절차 교육 - 테스트 환경 점검 - 통합테스트 수행 - 통합테스트 평가 - 통합테스트 결과서 작성 |
가 오픈 전 | 개발자 및 설계자 |
시스템테스트 | - 테스트 시나리오 작성 - 테스트 방법 및 절차 교육 - 테스트 환경 점검 - 시스템테스트 수행 - 시스템테스트 평가 - 시스템테스트 결과서 작성 |
오픈 전 | 수행사 테스트 지원팀/QA |
인수테스트 | - 검수기준서 작성 - 테스트 방법 및 절차 교육 - 테스트 환경 점검 - 인수테스트 수행 - 인수테스트 결과 평가 - 인수테스트 결과서 작성 - 미비사항 발견 시 보완 후 재시험 |
검수 전 | 고객사 담당자 |
오늘은 구현 단계 산출물 중 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 계획서 작성법에 대해 알아보왔습니다.
단위테스트는 기능단위의 프로그램 모듈에 대한 테스트를 말하며, 통합테스트는 단위 테스트를 통해 단위 프로그램 별 업무 처리 기능과 데이터 처리 기능이 검증된 단위 프로그램에 대해 통합 시나리오에 따라 업무 흐름을 중심으로 정확히 실행되는가를 종합적으로 검증하는 테스트입니다. 시스템테스트는 시스템 운영 전에 실제 운영 시스템의 환경을 구성하고 시스템의 정상적인 서비스 확인을 위한 성능평가를 실시하고 추가 보완사항을 도출하여 서비스에 지장을 줄 수 있는 요인들을 제거하고자 할 때 하는 테스트이며, 인수테스트는 개발 결과물을 사용자가 인수하기 전에 요구사항대로 시스템이 구현되고, 기능이 예상대로 동작하는지를 최종 확인하는 테스트입니다 여기서 테스트 종류 중에 통합테스트는 왜 해야하는지에 대해 잠깐 다루고 마무리 하겠습니다.
일명 통테를 하지 않으면 오픈 후 많은 시련에 봉착하게 됩니다. 설치 문제, 기능 오류 및 사용자 요구사항 오류 그리고 요구사항 누락 등 각종 문제들로 아마 롤백을 해야 할 수도 있는 상황까지 올 수 있습니다. 이렇게 된다면 오픈 연기는 물론 프로젝트 지연과 함께 엄청난 압박감이 찾아오게 됩니다. 통테를 한다는 것은 이런 많은 리스크를 해결할 수 있는 마지막 수단이라고 생각하면 될 것 같습니다. 일단, 통테를 하게 되면 가장 중요한 부분이 기존시스템과의 연계테스트를 통한 업무 절차의 검증이 될 것입니다. 이때 제대로 된 검증이 이루어지지 않으면 결과적으로 오픈 후에 리스크가 그대로 남아 있다고 생각하면 됩니다. 이런 리스크는 개발서버가 없거나 개발서버가 있더라도 운영서버와 동기화되어 있지 않거나 데이터가 현행화되지 않으므로 해서 발생할수 있습니다. 사실 대부분의 고객은 개발서버가 현행화 되지 않은채로 운영을 하는 경우가 대부분이기 때문에 프로젝트 시점부터 이미 많은 문제점을 내포하고 있다고 할 수 있습니다. 이런 부분은 기술협상 때 논의가 되거나, 운영서버 테스트 방안이 있어야 한다는 것과 같습니다. 하지만, 이런 부분은 간과한 채 프로젝트가 시작되고 결국은 프로젝트 수행팀이 그냥 껴안고 가는 문제인 것처럼 인식이 되어 있는 놀라운 사실이 있습니다. 아무쪼록 수행팀이라면 이런 부분은 프로젝트 시작 전에 꼭 집고 넘어가야 할 사항이며, 어떻게 해결할 것인지에 대한 논의가 반드시 필요하다는 점을 인식하시기 바랍니다.
프로젝트에 대해 다른 사항이 궁금하시면 아래 링크를 클릭하세요
(1편) 프로젝트: 기술협상서 작성하기
(2편) 프로젝트: 사업수행계획서, WBS 작성하기
(7편) 분석 산출물 요구사항정의서 등 작성법 알아보기
(10편) 설계 산출물3: 프로그램 목록, 프로그램 명세서 작성법 알아보기
(11편) 설계 산출물4: 인터페이스 정의서 및 설계서 작성법 알아보기