테스트 계획서는 품질 관리의 핵심 문서이자, 개발·운영팀 간 협업의 기준선입니다.
이번 글에서는 실무에서 바로 활용할 수 있는 테스트 계획서 예시를 구체적으로 정리했습니다.
단순한 형식이 아니라, 실제 프로젝트에서 어떻게 적용되는지 살펴보세요.
테스트 계획서 예시 개요
이 예시는 온라인 쇼핑몰 리뉴얼 프로젝트를 가정한 사례입니다.
테스트 범위, 일정, 역할 분배, 종료 기준 등이 포함된 형태로, 그대로 복사해 응용할 수 있습니다. 🎯
| 구분 | 내용 |
|---|---|
| 프로젝트명 | 쇼핑몰 리뉴얼 프로젝트 (v2.0) |
| 작성일 | 2025년 10월 11일 |
| 작성자 | QA팀 김하늘 |
| 검토자 | 개발팀 박성준 |
| 승인자 | 프로젝트 매니저 이현우 |
테스트 목적 및 목표
이 프로젝트의 목적은 리뉴얼된 쇼핑몰 시스템이 안정적이고 오류 없이 운영 가능한지 검증하는 것입니다.
주요 테스트 목표는 다음과 같습니다.
- 신규 로그인 및 회원가입 기능 정상 작동 확인
- 장바구니 및 결제 모듈 오류 제로화
- 상품 검색 및 필터 기능의 속도·정확성 검증
- 테스트 케이스 통과율 95% 이상 달성
테스트 범위 및 제외 항목
테스트 범위(In-Scope)
- 사용자 로그인 / 회원가입
- 상품 검색, 정렬, 필터링
- 장바구니 담기 / 결제 모듈
- 주문 이력 및 알림 기능
제외 항목(Out-of-Scope)
- 마케팅 배너 관리
- 관리자 통계 페이지 (차기 버전 예정)
테스트 전략 및 접근 방식
테스트는 리스크 기반 접근법으로 진행합니다.
주요 기능 위주로 우선순위를 부여하고, 자동화와 수동 테스트를 병행합니다.
| 구분 | 내용 | 비고 |
|---|---|---|
| 기능 테스트 | 신규 기능 및 수정 기능 검증 | 수동 테스트 중심 |
| 회귀 테스트 | 기존 기능 영향도 확인 | 자동화 스크립트 활용 |
| 성능 테스트 | 페이지 응답 시간, 부하 테스트 | 최대 200명 동시 접속 기준 |
| 보안 테스트 | 로그인, 결제 보안 점검 | OWASP Top 10 기준 |
이 전략을 통해 테스트 커버리지 90% 이상 확보를 목표로 합니다.
테스트 환경 및 도구
- 테스트 서버: AWS EC2 Ubuntu 22.04
- DB: MySQL 8.0
- 브라우저: Chrome, Edge, Safari 최신 버전
- 도구: Jira (버그 추적), Zephyr (케이스 관리), Postman (API 테스트)
실제 사용자 환경을 최대한 반영하기 위해 동일한 네트워크 대역에서 검증을 진행합니다.
테스트 일정 및 마일스톤
| 단계 | 일정 | 주요 작업 |
|---|---|---|
| 계획 수립 | 10/11 ~ 10/13 | 테스트 전략·범위 정의 |
| 테스트 케이스 작성 | 10/14 ~ 10/18 | 기능별 케이스 설계 |
| 환경 구축 | 10/19 ~ 10/20 | 서버 및 데이터 세팅 |
| 테스트 실행 | 10/21 ~ 10/29 | 기능·회귀 테스트 병행 |
| 버그 수정 및 재검증 | 10/30 ~ 11/03 | 수정 항목 집중 검증 |
| 최종 보고 | 11/04 | QA 결과 보고서 제출 |
일정은 개발 일정과 병행되며, 각 단계별 결과물은 공유 회의에서 검토됩니다.
역할 및 책임 분배
| 역할 | 담당자 | 주요 업무 |
|---|---|---|
| QA 리드 | 김하늘 | 전체 테스트 관리 및 보고 |
| QA 엔지니어 | 이도현 | 로그인 / 회원 기능 검증 |
| QA 엔지니어 | 최은지 | 상품 / 장바구니 기능 검증 |
| 개발 리더 | 박성준 | 버그 수정 및 기술 지원 |
| PM | 이현우 | 일정·품질 승인 및 조정 |
이 표처럼 역할을 명확히 구분하면 커뮤니케이션 혼선을 줄일 수 있습니다.
진입 기준 및 종료 조건
진입 기준(Entry Criteria)
- 모든 개발 완료 및 코드 병합
- 테스트 환경 정상 동작
- 기본 테스트 데이터 구축 완료
종료 조건(Exit Criteria)
- 모든 핵심 케이스 통과율 95% 이상
- 치명적 결함(Critical, Blocker) 0건
- 리포트 검토 및 승인 완료
종료 조건이 명확해야 ‘테스트 완료 시점’을 객관적으로 판단할 수 있습니다.
리스크 및 대응 방안
| 리스크 | 영향 | 대응 방안 |
|---|---|---|
| 테스트 환경 구축 지연 | 일정 차질 가능성 | 사전 서버 이미지 백업 활용 |
| 외부 결제 API 불안정 | 기능 오류 위험 | 모의(Mock) API 서버 사용 |
| QA 인력 부족 | 일정 지연 | 타 프로젝트 QA 지원 요청 |
이처럼 리스크를 문서에 포함하면, 예기치 못한 상황에도 빠르게 대응할 수 있습니다.
테스트 산출물 및 보고 방식
- 테스트 케이스 문서 (Excel / Zephyr)
- 버그 리포트 (Jira)
- 테스트 결과 요약 리포트 (PDF)
- 최종 테스트 완료 보고서
리포트는 매주 수요일 정기 회의에서 공유됩니다.
유용한 링크 모음
FAQ (자주 묻는 질문)
테스트 계획서는 누가 작성하나요?
보통 QA 리드 또는 테스트 매니저가 초안을 작성하고, 개발·PM이 함께 검토합니다.
테스트 계획서에 ‘결함 관리 프로세스’를 꼭 포함해야 하나요?
네, 결함의 보고·수정·재검증 절차는 품질 보증의 핵심이므로 반드시 포함해야 합니다.
테스트 일정은 개발 일정보다 얼마나 앞서야 하나요?
개발 완료 시점 기준 최소 3일 전에는 계획서가 확정되어야 합니다.
자동화 테스트는 계획서에 어떻게 표시하나요?
자동화 대상 기능, 도구, 스크립트 관리 위치를 명확히 표기하면 됩니다.
테스트 데이터는 어디에 보관하나요?
보통 테스트 전용 DB 또는 클라우드 공유 폴더에 저장하며, 접근 권한을 제한해야 합니다.
테스트 종료 후 문서 보관은 어떻게 하나요?
최종 승인된 문서는 프로젝트 저장소(Git, Confluence 등)에 업로드하여 버전 관리합니다.
이 예시처럼 테스트 계획서를 구체적으로 작성하면, QA 과정의 효율과 신뢰도가 모두 높아집니다.
한 번 잘 만든 계획서가 이후 모든 프로젝트의 품질 기준이 됩니다.
댓글 남기기