테스트 계획서 구성 항목, 한 번에 정리하는 완성형 가이드

테스트 계획서를 잘 작성하려면, 무엇보다 구성 항목을 명확히 이해하는 것이 중요합니다.
문서의 형식보다 더 중요한 건 ‘무엇을 포함해야 하는가’이기 때문입니다.
이번 글에서는 표준(IEEE 829)과 실무 현장에서 모두 통용되는 테스트 계획서 구성 항목 전체 목록과 작성 팁을 정리했습니다.

테스트 계획서가 필요한 이유

테스트 계획서는 단순한 QA 문서가 아닙니다.
프로젝트 전체의 품질 목표, 범위, 전략, 리스크, 일정 등을 명확히 정리하는 품질 관리 로드맵입니다.

이 문서가 있으면 다음과 같은 장점이 있습니다.

• 개발·QA·기획 간 커뮤니케이션 기준이 명확해짐
• 테스트 누락이나 중복 방지
• 일정·품질 리스크 사전 관리 가능
• 프로젝트 종료 후 회고 및 개선 자료로 활용

테스트 계획서 구성 항목 기본 구조

아래 표는 국제 표준(IEEE 829) 과 국내 실무를 조합한 가장 일반적인 테스트 계획서 구성 예시입니다.

이 표를 기반으로 하면, 어떤 프로젝트에서도 빠짐없이 계획서를 구성할 수 있습니다.

각 항목별 작성 가이드

각 구성 항목의 실제 작성 시 주의할 점을 항목별로 정리했습니다.

1. 문서 정보

문서 버전과 작성일, 작성자, 검토자, 승인자 등은 반드시 포함해야 합니다.
변경 이력(Version History)을 별도 표로 관리하면 좋습니다.

2. 개요 및 목적

프로젝트의 QA 목표를 명확히 제시합니다.
예: “신규 쇼핑몰 시스템의 주요 기능(로그인, 결제 등)에 대한 품질 검증 및 안정성 확보”

3. 테스트 범위

포함/제외 기능을 구체적으로 작성합니다.
예:

• 포함: 로그인, 장바구니, 결제, 주문 내역
• 제외: 관리자 통계 페이지 (추후 개발 예정)

4. 테스트 전략

테스트 접근 방식과 우선순위를 정의합니다.

• 기능 테스트: 수동 테스트 중심
• 회귀 테스트: 자동화 테스트 스크립트 활용
• 성능 테스트: 동시 사용자 200명 기준 부하 테스트

5. 테스트 환경

테스트 환경은 실제 운영 환경과 최대한 유사해야 합니다.
예:

• OS: Windows 11 / macOS Ventura
• Browser: Chrome, Edge, Safari
• Server: AWS EC2, MySQL 8.0

6. 테스트 일정

각 테스트 단계별 기간을 명시하고, 예상 완료일과 보고일을 설정합니다.
짧은 프로젝트일수록 테스트 실행과 리포트 일정이 겹치지 않도록 조정해야 합니다.

7. 역할 및 책임

담당자별 역할을 명확히 구분해 커뮤니케이션 오류를 줄입니다.
예:

• QA 리더: 전체 테스트 관리 및 승인
• QA 엔지니어: 기능별 테스트 실행
• 개발 담당자: 오류 수정 및 재검증 지원

8. 테스트 데이터

테스트용 데이터는 실제 운영 데이터를 사용하지 말고, 가상 데이터(Mock Data)를 설계해야 합니다.

• 예: 테스트 계정, 샘플 주문번호, 임시 결제 카드 정보

9. 진입 기준 / 종료 조건

진입 기준은 “테스트 시작 가능 조건”, 종료 조건은 “테스트 완료 판단 기준”입니다.

• Entry Criteria: 기능 개발 100% 완료, 환경 정상 구동
• Exit Criteria: 필수 케이스 통과율 95% 이상, 중대 결함 0건

10. 리스크 및 대응 방안

예상 리스크를 미리 정의해 두면, 테스트 지연 시 빠르게 대응할 수 있습니다.
예:

• 리스크: API 지연으로 테스트 중단 가능
• 대응: Mock 서버 활용 / 일정 조정

11. 산출물 및 보고 방식

테스트 결과물은 형식과 제출 주기를 함께 명시합니다.

• 테스트 케이스 (Excel / Zephyr)
• 버그 리포트 (Jira)
• 테스트 결과 보고서 (PDF, 주간 단위)

12. 승인 절차

최종 문서는 QA 리더 → 개발팀 → PM 순으로 승인받는 것이 일반적입니다.
승인자는 문서 하단 서명란 또는 전자 결재 시스템을 통해 확인합니다.

13. 참고 문서

테스트 계획의 근거가 되는 문서(요구사항 명세서, 설계 문서, 회의록 등)를 링크로 포함합니다.

유용한 링크 모음

FAQ (자주 묻는 질문)

테스트 계획서 구성 항목은 꼭 표준대로 따라야 하나요?

아닙니다. 프로젝트 특성에 맞게 조정하면 됩니다. 다만 핵심 항목(목적, 범위, 환경, 일정, 리스크 등)은 생략하지 않는 것이 좋습니다.

리스크 관리 항목이 꼭 필요한가요?

네, 예기치 못한 상황에 대비하기 위한 최소한의 대비책입니다. 테스트 지연이나 품질 저하를 예방할 수 있습니다.

테스트 환경은 실제 운영 환경과 같아야 하나요?

가급적 동일해야 하지만, 리소스 한계가 있다면 주요 기능 테스트용 최소 구성으로 대체 가능합니다.

테스트 계획서는 누가 작성하나요?

보통 QA 리더 또는 품질보증 담당자가 초안을 작성하고, 개발팀과 PM이 검토 후 승인합니다.

계획서 작성 시 가장 많이 빠뜨리는 항목은 무엇인가요?

테스트 종료 기준과 리스크 항목이 자주 누락됩니다. 이 두 가지는 반드시 포함해야 합니다.

문서 분량은 어느 정도가 적당한가요?

일반 웹·앱 프로젝트의 경우 5~10페이지 내외가 적당합니다. 핵심 정보만 간결하게 정리하세요.

테스트 계획서의 구성은 복잡해 보이지만, 항목별로 목적을 이해하면 훨씬 수월하게 정리할 수 있습니다.
오늘 소개한 구성표를 기반으로 작성하면, 체계적이고 실무에 바로 적용 가능한 테스트 계획서를 완성할 수 있을 것입니다.
좋은 계획이 좋은 품질을 만듭니다.