테스트 계획서

테스트 계획서는 특정 릴리스, 프로젝트, 기능에 대해 테스트를 어떻게 수행할지 설명합니다. 무엇이 범위에 포함되고 제외되는지, 어떤 유형의 테스트를 적용하는지, 누가 무엇을 하는지, 어디서 실행하는지, 언제 진행하는지, 그리고 팀이 테스트가 끝났음을 어떻게 판단하는지를 담습니다. 실행을 시작하기 전에 문서로 남기는 QA, 개발, 제품 팀 사이의 테스트 합의서입니다. 고전적인 템플릿은 IEEE 829 표준(현재는 ISO/IEC/IEEE 29119-3으로 대체됨)입니다.

쓸모 있는 테스트 계획서에 들어갈 내용

• 범위: 범위에 포함되는 기능과, 그만큼 중요한 명시적으로 범위에서 제외되는 기능.
• 접근 방식: 테스트 레벨과 유형(단위, API, UI, 성능, 보안, 접근성), 자동화할 것과 수동으로 할 것.
• 환경과 데이터: 사용할 환경, 테스트 데이터를 생성하거나 마스킹하는 방법, 서드파티 샌드박스.
• 시작 기준(entry criteria): 테스트를 시작하기 전에 충족되어야 할 조건. 예: “스테이징에 빌드가 배포되고 스모크 테스트가 통과됨”.
• 종료 기준(exit criteria): “완료”의 의미. 예: “치명적·주요 결함이 열려 있지 않고, 모든 P1 시나리오가 통과했으며, 회귀 테스트 스위트가 통과됨”.
• 리스크와 대응 방안: 예: “결제 샌드박스가 불안정하므로 기능 테스트에서는 스텁으로 대체하고, 실제 샌드박스를 대상으로 매일 한 번 엔드투엔드 점검을 실행한다”.
• 역할, 일정, 산출물: 누가 무엇을 테스트하는지, 주요 일정, 어떤 보고서를 작성하는지.

테스트 계획서와 테스트 전략의 차이

테스트 전략은 제품이나 조직 차원의 상위 수준이자 오래 유지되는 접근 방식으로, 테스트 원칙, 레벨, 도구, 표준을 정합니다. 테스트 계획서는 그 전략을 하나의 릴리스나 프로젝트에 적용해 구체적인 범위, 일정, 담당자를 정합니다. 많은 애자일 팀은 가벼운 전략 페이지 하나와 릴리스 또는 에픽마다 짧은 계획서를 유지합니다.

흔한 실수

• 아무도 읽지 않는 40페이지짜리 문서를 작성합니다. 애자일 팀에서는 최신 상태로 유지되는 한 페이지짜리 계획서가 두 번째 스프린트에 이미 낡아 버리는 방대한 문서보다 낫습니다.
• 모호한 종료 기준. “테스트 완료”는 측정할 수 없습니다. 조건을 명시합니다.
• 범위 제외 섹션이 없습니다. 명시하지 않은 제외 항목은 릴리스 후 논쟁거리가 됩니다.