새로운 프로젝트가 시작될 때, 기획자나 프로젝트 매니저(PM)는 QA에게 종종 이렇게 묻습니다.
“이번 테스트는 얼마나 걸릴까요? QA는 몇 명 필요하죠? 언제쯤이면 끝날까요?”
이런 질문에 계획 없이 “해봐야 알 것 같다”고 답한다면, 프로젝트는 시작부터 안갯속을 헤매게 됩니다. 테스트 활동을 예측 가능하고 관리 가능한 영역으로 이끌어주는 것, 그것이 바로 ‘테스트 계획서(Test Plan)’의 역할입니다.
Q. 테스트 계획서, 정확히 무엇인가요?
특정 프로젝트나 기능의 전체 테스트 활동에 대한 ‘전략, 목표, 범위, 일정, 리소스’ 등을 명확하게 정의한 공식 문서를 말합니다.
- 비유: 여행을 떠나기 전에 작성하는 ‘상세한 여행 계획표’와 같습니다. 어디를 갈지(테스트 범위), 왜 가는지(목표), 얼마의 예산과 시간으로(리소스/일정), 무엇을 준비해야 할지(테스트 환경) 등을 미리 정하는 것입니다. 계획 없이 떠나는 여행은 길을 잃기 쉽습니다.
Q. 왜 그렇게 중요한가요?
모든 팀원이 테스트에 대해 동일한 그림을 보게 해주는 ‘소통의 중심’이기 때문입니다.
- 테스트의 목표와 범위를 명확히 하여 ‘이번엔 이것을 테스트하고, 저것은 다음번에 한다’는 공감대를 형성합니다.
- 필요한 인력, 장비, 시간을 미리 예측하여 프로젝트 전체 계획의 정확도를 높입니다.
- 테스트 진행 상황을 추적하고, “우리는 계획 대비 80% 진행했습니다”라고 객관적으로 보고하는 기준이 됩니다.
- 개발자, 기획자, 경영진 등 모든 이해관계자와의 공식적인 소통 자료로 활용됩니다.
Q. 테스트 계획서에는 어떤 내용이 들어가나요?
조직이나 프로젝트의 규모에 따라 다르지만, 일반적으로 다음과 같은 핵심 항목들을 포함합니다.
1. 테스트 범위 (Scope)
- 무엇을 테스트할 것인가? (In-Scope Features)
- 무엇을 테스트하지 않을 것인가? (Out-of-Scope Features)
2. 테스트 전략 (Test Strategy)
- 어떤 테스트 레벨(단위, 통합, 시스템)에 집중할 것인가?
- 어떤 테스트 종류(기능, 성능, 사용성, 보안)를 수행할 것인가?
3. 리소스 및 일정 (Resource & Schedule)
- 누가 테스트를 수행할 것인가? (테스트 팀 구성)
- 언제부터 언제까지 각 테스트를 진행할 것인가? (주요 마일스톤)
4. 테스트 환경 (Test Environment)
- 어떤 OS, 브라우저, 디바이스에서 테스트할 것인가?
- 필요한 서버 사양, 테스트 계정, 데이터는 무엇인가?
5. 테스트 시작/종료 기준 (Entry/Exit Criteria)
- 시작 기준: 언제부터 테스트를 시작할 수 있는가? (예: 개발팀의 단위 테스트 통과, 테스트 환경 구성 완료)
- 종료 기준: 언제 테스트를 ‘완료’했다고 말할 수 있는가? (예: 핵심 기능의 모든 테스트 케이스 통과, 치명적인 버그 없음)
6. 테스트 산출물 (Test Deliverables)
- 테스트가 끝나면 어떤 문서들을 전달할 것인가? (예: 테스트 케이스 문서, 버그 리포트, 최종 테스트 결과 보고서)
결론: 계획이 품질의 절반이다
테스트 계획서는 단순히 형식적인 문서 작성이 아닙니다. 프로젝트 초기에 발생할 수 있는 위험을 미리 식별하고, 한정된 자원으로 최대의 테스트 효과를 내기 위한 ‘전략 수립’ 과정입니다.
“테스트는 언제 끝나는가?”라는 질문에 대한 답은 바로 이 계획서 안에 있습니다. 우리가 정한 ‘종료 기준’을 만족했을 때, 우리는 자신 있게 “계획된 테스트가 성공적으로 완료되었습니다”라고 말할 수 있습니다. 잘 짜인 계획은, 성공적인 제품 출시를 위한 가장 튼튼한 첫걸음입니다.