테스트 계획서와 테스트 전략의 구성 요소

개념

스테이지 1에서 배운 것은 "어떻게 테스트를 설계하는가"였다. 모듈 3 마지막 레슨에서 하나의 기능에 여러 기법을 조합해 20개짜리 테스트 케이스 목록을 만들어봤다. 그런데 실무에서는 그 앞에 반드시 붙는 질문이 있다 — 누가, 언제까지, 어디까지, 무엇을 근거로 끝났다고 말할 것인가. 이 질문에 대한 답을 글로 적어둔 것이 테스트 계획서다.

전략(Strategy)과 계획(Plan)의 차이

두 단어가 비슷해 보이지만 가리키는 범위가 다르다.

전략은 "우리 조직은 테스트를 어떻게 대하는가"라는 큰 방향이고, 계획은 그 방향을 이번 상황(이번 릴리즈, 이번 기능)에 구체적으로 적용한 것 이다. 계획은 전략을 벗어나지 않으면서도, 이번 릴리즈만의 특수 사정(신규 모듈, 촉박한 일정 등)을 반영해 조정된다.

구분이 헷갈릴 때 쓰는 간단한 판별법이 있다. 그 문장 앞에 "이번 릴리즈에서는"을 붙여보는 것 이다. 자연스럽게 붙으면 계획이고, 어색하면 전략이다. "이번 릴리즈에서는 회귀 테스트를 가능한 자동화한다"는 어색하다 — 그건 매번 그렇게 하기로 한 방침, 즉 전략이다. "이번 릴리즈에서는 결제 회귀를 수동으로 한 번 더 돈다"는 자연스럽다 — 이번만의 결정, 즉 계획이다.

테스트 계획서의 핵심 구성 요소

무겁고 형식적인 문서일 필요는 없다 — 위키 페이지 한 장으로도 충분할 때가 많다. 다만 아래 요소는 빠지지 않아야 한다.

이 표의 항목 하나하나가 이후 레슨들의 주제이기도 하다 — 이 레슨은 전체 지도를 펼치는 역할이고, 나머지 레슨들이 "리스크와 대응", "진입·종료 기준" 같은 개별 항목을 깊게 채운다.

각 칸을 실제로 어떻게 채우는가

항목 이름을 외우는 것은 어렵지 않다. 어려운 건 그 칸에 무슨 문장을 쓰느냐 다. 같은 항목이라도 쓰는 방식에 따라 아무 쓸모 없는 칸이 되기도 하고, 릴리즈 내내 누군가 다시 열어보는 칸이 되기도 한다. "장바구니에 수량 일괄 변경 기능 추가"라는 가상의 릴리즈로 양쪽을 나란히 놓아보자.

오른쪽 칸들이 왼쪽보다 길어서 좋은 게 아니다. 셋 중 하나라도 갖췄기 때문에 좋다.

• 검증 가능한가. "3월 중 완료"는 3월 31일에도 참이다. "3/16 결과 공유"는 3월 17일에 거짓이 된다. 참·거짓을 가릴 수 있어야 계획이다.
• 결정이 담겼는가. "기능 테스트와 회귀 테스트를 수행한다"에는 아무 결정이 없다 — 어느 프로젝트에 복사해 넣어도 맞는 말이다. 반대로 "회귀는 cart· checkout 태그만"에는 "나머지는 안 돈다"는 결정이 들어 있다.
• 제약이 드러나는가. "QA 2명"은 사실이지만, "그중 1명이 3일간 반쯤 빠진다"가 진짜 계획에 영향을 주는 정보다. 살아 있는 칸은 자원의 이상적인 숫자가 아니라 실제로 쓸 수 있는 양 을 적는다.

칸을 다 채운 뒤에 스스로 물어볼 질문은 하나다. "이 문장을 지우면 누가 곤란해지는가?" 아무도 곤란해지지 않는 문장은 지워도 되는 문장이고, 그런 문장이 절반 넘게 쌓인 순간 그 문서는 아무도 안 읽는 문서가 된다.

특히 접근법 칸이 가장 자주 죽는다. "기능·회귀·성능 테스트를 수행한다"처럼 테스트 유형 이름만 나열하는 형태로 채워지기 때문이다. 접근법 칸의 목적은 유형을 나열하는 게 아니라 한정된 시간을 어디에 얼마나 쓸지 배분하는 것 이다. 모듈 3에서 배운 기법 이름이 여기서 그대로 쓰인다 — "금액 계산은 결정 테이블, 신규 UI는 탐색적"이라고 적으면 읽는 사람이 왜 그렇게 나눴는지까지 이해한다.

범위는 "무엇을 안 할지"도 포함한다

계획서에서 가장 자주 빠지는 부분이 "이번엔 테스트하지 않는 것"을 명시하는 일 이다. "다국어 번역 품질은 이번 릴리즈에서 테스트 범위에서 제외한다"처럼 명시적으로 적어두면, 나중에 "그거 왜 안 봤어요?"라는 질문에 "계획서에 범위 밖으로 합의했습니다"라고 답할 수 있다. 암묵적으로 빠진 것과 명시적으로 뺀 것은 책임 소재가 완전히 다르다.

여기서 한 걸음 더 나가면 좋다. 제외한 이유까지 한 줄로 적는 것 이다.

이유가 붙으면 두 가지가 달라진다. 첫째, 전제가 깨졌을 때 다시 열어볼 수 있다. "트래픽 패턴 변화가 없다"는 전제가 릴리즈 도중 무너지면 그 줄을 다시 읽고 판단을 뒤집을 수 있다. 둘째, 제외가 QA 혼자의 결정이 아니게 된다. "개발팀 판단에 근거"라고 적힌 순간 그 판단은 공유된 결정이 된다. 모듈 2의 요구사항 리뷰에서 배운 "결정권은 넘기고 근거는 남긴다"가 계획서에서도 똑같이 작동한다.

조직 규모에 따라 달라지는 모습

전략과 계획이라는 두 층은 어느 조직에나 있다. 다만 문서로 존재하느냐, 사람 머릿속에 있느냐 가 규모에 따라 달라진다. 같은 원리가 어떻게 다른 형태로 나타나는지 보자.

스타트업에서 "전략 문서가 없다"는 게 전략이 없다는 뜻은 아니다. "우리는 신규 기능은 무조건 손으로 한 번 훑고 내보낸다" 같은 방침은 존재한다. 다만 적혀 있지 않아서, 그 방침을 아는 사람이 퇴사하면 함께 사라진다. 신입 QA가 스타트업에서 가장 크게 기여할 수 있는 지점이 여기다 — 이미 다들 그렇게 하고 있는 방침을 위키 한 페이지로 적어놓는 것 만으로 조직에 전략 층이 생긴다.

중견 조직의 함정은 반대다. 위키에 전략 문서가 있긴 한데 2년 전에 쓰였고, 그사이 자동화 도구도 바뀌고 배포 주기도 바뀌었다. 이때 계획서가 낡은 전략을 형식적으로 인용하면 계획서까지 같이 신뢰를 잃는다. 전략 문서에는 마지막 검토 날짜와 다음 검토 예정일 을 박아두는 것이 실무적으로 효과가 크다.

규제 산업(의료기기·금융·자동차)에서는 계획서 자체가 규제 대응 산출물이다. "우리가 이런 계획으로 이만큼 테스트했다"는 것을 외부 감사에 증명해야 하므로 형식과 승인 절차가 필수다. 이 맥락은 모듈 8에서 표준과 함께 자세히 다룬다. 중요한 건 형식이 무거운 이유가 관료주의가 아니라 증명 책임 때문 이라는 점이다. 증명할 필요가 없는 조직이 그 형식만 흉내 내면 비용만 남는다.

아무도 안 읽는 계획서 vs 실제로 쓰이는 계획서

100페이지짜리 테스트 계획서를 만들어놓고 아무도 열어보지 않는 광경은 흔하다. 분량이 문제가 아니라 분량이 생긴 이유 가 문제다. 죽은 문서에는 공통점이 있다.

반대로 한 장짜리 계획이 더 많이 읽히는 이유는 단순하다. 읽는 데 2분이 걸리고, 고치는 데 5분이 걸리기 때문 이다. 고치기 쉬우면 실제로 고쳐지고, 고쳐진 문서는 현실과 일치하고, 현실과 일치하는 문서는 사람들이 다시 열어본다. 이 순환이 문서를 살린다.

그래서 계획서의 분량은 읽을 사람의 수와 그들이 내려야 할 결정의 수 로 정해진다. 다음 질문으로 점검해보자.

1. 이 문서를 열어볼 사람이 누구인지 한 명이라도 이름을 댈 수 있는가?
2. 그 사람이 이 문서에서 찾으려는 정보가 첫 화면 안에 있는가?
3. 범위가 바뀌었을 때 5분 안에 고칠 수 있는가?
4. 다른 릴리즈 계획서와 비교했을 때 다른 문장 이 절반을 넘는가?
5. 이 문서를 없애면 실제로 곤란해지는 대화가 있는가?

5번에서 막힌다면 그 문서는 이미 죽었다고 봐도 된다.

문서의 목적은 합의를 만드는 것이지 분량을 채우는 게 아니다. 계획서가 좋은 문서인지 판정하는 최종 기준은 딱 하나다 — 그 문서를 근거로 누군가와 대화가 성립했는가. PM이 "이 기능 범위에 있나요?"라고 물었을 때 링크 하나로 답이 끝났다면 그 계획서는 제 역할을 한 것이다.

애자일에서 계획은 어떻게 축약되는가

2주 스프린트에서 매번 정식 테스트 계획서를 쓰는 팀은 거의 없다. 그렇다고 계획이 사라진 것은 아니고, 여러 곳으로 흩어져 자리를 잡는다.

즉 애자일에서 계획서가 얇아지는 것은 항목을 버려서가 아니라 이미 다른 곳에 있는 것을 중복해 적지 않기 때문 이다. 여기서 흔한 오해가 생긴다. "애자일이니까 계획은 필요 없다"는 말은 대개 완료 정의도 리스크 논의도 없는 팀 의 자기변호로 쓰인다. 애자일 선언문도 계획을 버리라고 하지 않았다 — 계획을 따르는 것보다 변화에 대응하는 것에 더 가치를 둔다고 했을 뿐, 계획 자체는 왼쪽 항목으로 남아 있다.

그래서 아무리 축약해도 사라지면 안 되는 최소 세 항목 이 있다.

스프린트 단위 계획은 이 정도면 충분하다.

스프린트 24 — 장바구니 수량 일괄 변경
대상: CART-812, CART-815, CART-820
범위 밖: 쿠폰 재계산(미변경), 다국어 문구
접근: 신규 UI 탐색적 90분 x2, 금액 계산 자동화, 회귀는 cart/checkout 태그
리스크: 재고 동시성(수정 3일 예상) -> 첫날 우선 실행
종료: 심각도 높음 0건, 계획 케이스 95% 실행, DoD 충족

여섯 줄이다. 읽는 데 30초, 고치는 데 1분이면 된다. 그리고 이 여섯 줄은 앞서 본 7개 구성 요소를 하나도 빠뜨리지 않았다 — 테스트 대상·범위·접근법·리스크·종료 조건이 모두 있고, 일정은 스프린트 기간이며, 산출물은 팀의 기본 규칙을 따른다. 계획서를 줄이는 올바른 방법은 항목을 빼는 게 아니라 각 항목을 한 줄로 줄이는 것 이다.

표준(ISO/IEC/IEEE 29119)과의 대응

모듈 8에서 국제 표준 ISO/IEC/IEEE 29119를 자세히 다루는데, 미리 연결해두면 표준이 낯설지 않다. 표준이 요구하는 문서 구조는 이 레슨에서 배운 것과 거의 그대로 대응한다.

표준이 하는 일은 새로운 개념을 추가하는 것이 아니라, 이미 필요한 항목에 공통된 이름과 순서를 붙여주는 것 이다. 그래서 표준을 먼저 외우고 실무로 내려오면 어렵고, 이 레슨처럼 "왜 이 칸이 필요한가"를 먼저 이해한 뒤 표준을 보면 "아, 이게 그거였구나"가 된다. 모듈 8은 그 순서를 전제로 쓰여 있다.

실무에서 왜 필요한가

계획서가 없으면 테스트는 그때그때 즉흥적으로 이뤄지고, 이해관계자는 "이게 테스트됐는지 안 됐는지" 알 방법이 없다. PM이 "이 기능 테스트 범위에 포함되나요?"라고 물었을 때 계획서를 보면 바로 답할 수 있어야 한다. 계획서는 QA 혼자 보는 문서가 아니라 개발·기획과 기대치를 맞추는 커뮤니케이션 도구 이기도 하다.

첫째, 협상의 근거가 된다. 일정이 밀렸을 때 "시간이 부족합니다"는 논의를 만들지 못한다. 계획서가 있으면 "회귀 전체를 돌면 이틀, cart 태그만 돌면 반나절입니다. 후자를 택하면 결제 연동 회귀가 빠집니다"라고 무엇을 잃는지 명시한 선택지 를 내놓을 수 있다. 모듈 3 마지막 레슨에서 연습한 "덮은 것 / 안 덮은 것 / 추가 비용" 화법이 릴리즈 단위로 확장된 형태다.

둘째, 책임 경계를 만든다. 사고가 났을 때 가장 먼저 나오는 질문은 "QA는 뭐 했나요"다. 이때 필요한 건 변명이 아니라 그 항목이 어디에 있었는지 다. 범위 안이었다면 왜 못 잡았는지를 회고하면 되고, 범위 밖이었다면 왜 제외했는지 근거를 보여주면 된다. 둘 다 아니면 — 계획서에 아예 언급이 없다면 — 그게 진짜 문제다.

셋째, 나중에 온 사람이 이어받을 수 있다. 담당자가 바뀌었을 때 계획서가 없으면 새 담당자는 "지난 릴리즈에 뭘 어떻게 봤는지"를 알 방법이 없어서 전부 처음부터 한다. 계획서 몇 장이 인수인계 며칠을 줄인다.

넷째, 이후 모든 레슨이 이 문서 위에 올라간다. 레슨 2의 리스크 기반 우선순위는 계획서의 "리스크" 칸을 채우는 방법이고, 레슨 3의 커버리지 계획은 "접근법" 칸을, 레슨 4의 종료 조건은 "진입·종료 기준" 칸을, 레슨 5의 Go/No-Go는 그 종료 조건을 실제 판단으로 바꾸는 절차다. 이 레슨을 지도라고 부른 이유가 이것이다.

실습 과제

과제 1 — 전략인가 계획인가 (8분)

다음 문장이 전략에 가까운지 계획에 가까운지 분류한다. 본문의 판별법("이번 릴리즈에서는"을 붙여보기)을 적용한다.

1. "우리 팀은 신규 기능마다 탐색적 테스팅 세션을 최소 1회 진행한다."
2. "이번 스프린트의 로그인 개편은 회귀 테스트를 결제 모듈까지 확장해서 본다."
3. "회귀 테스트는 가능한 자동화하고, 수동은 신규 기능에 집중한다."
4. "결제 관련 변경은 반드시 두 명 이상이 교차 확인한다."
5. "3.4 릴리즈는 QA 인원이 한 명 빠지므로 성능 테스트를 다음 릴리즈로 미룬다."
6. "심각도 '높음' 결함이 남아 있으면 릴리즈하지 않는다."

과제 2 — 죽은 칸 살리기 (12분)

어느 팀의 테스트 계획서에서 가져온 칸들이다. 각 칸을 본문의 세 기준(검증 가능한가 / 결정이 담겼는가 / 제약이 드러나는가)으로 진단하고, 살아 있는 문장으로 고쳐 쓴다. 정보가 없는 부분은 가정을 세워 채워도 된다.

1. 범위: "이번 릴리즈에 포함된 기능 전체"
2. 접근법: "기능 테스트, 회귀 테스트, 성능 테스트를 수행한다"
3. 일정: "개발 완료 후 충분한 기간 동안 테스트한다"
4. 리스크: "예상치 못한 이슈가 발생할 수 있다"

과제 3 — 미니 계획서 작성하기 (15분)

"장바구니에 수량 일괄 변경 기능 추가"라는 가상의 릴리즈에 대해, 본문 표의 7개 구성 요소 각각을 한 줄씩 채워 미니 테스트 계획서를 작성한다. 정보가 부족한 항목은 가정을 세워 적어도 된다. 다 쓴 뒤 각 줄에 대해 "이 문장을 지우면 누가 곤란해지는가" 를 물어보고, 아무도 곤란해지지 않는 줄은 지운다.

과제 4 — 규모를 바꿔 다시 쓰기 (12분)

과제 3에서 만든 미니 계획서를 두 형태로 다시 쓴다.

1. 스프린트 한 장 버전 — 본문의 여섯 줄 형식으로 압축한다. 최소 세 항목 (범위·종료 조건·리스크)이 살아 있는지 확인한다.
2. 규제 산업 버전 — 외부 감사자가 읽는다고 가정하고, 어떤 항목이 추가로 필요할지 세 가지만 적어본다.

자가 체크리스트

• 테스트 전략과 테스트 계획의 범위·수명 차이를 설명할 수 있다
• "이번 릴리즈에서는"을 붙여보는 판별법으로 전략과 계획을 구분할 수 있다
• 테스트 계획서의 7가지 핵심 구성 요소를 나열할 수 있다
• 계획서의 한 칸이 죽었는지 살았는지를 세 기준(검증 가능·결정 포함·제약 노출)으로 진단할 수 있다
• 접근법 칸에 테스트 유형 나열이 아니라 시간 배분을 쓸 수 있다
• "무엇을 테스트하지 않을지"를 이유와 함께 명시하는 것이 왜 중요한지 설명할 수 있다
• 조직 규모(스타트업·중견·규제 산업)에 따라 전략과 계획이 어떤 형태로 나타나는지 비교할 수 있다
• 긴 계획서가 죽는 다섯 가지 이유를 들 수 있다
• 애자일에서 계획서 항목들이 어디로 흩어지는지, 그럼에도 남아야 할 최소 세 항목이 무엇인지 말할 수 있다
• 스프린트 단위의 여섯 줄짜리 계획을 작성할 수 있다
• ISO/IEC/IEEE 29119의 정책·전략·계획 계층이 이 레슨의 개념과 어떻게 대응하는지 설명할 수 있다
• 주어진 릴리즈에 대해 미니 테스트 계획서를 작성할 수 있다

흔한 실수

• 계획서를 한 번 쓰고 릴리즈 내내 갱신하지 않는다. 범위가 바뀌면(기능 추가·축소) 계획서도 함께 갱신해야 신뢰할 수 있는 문서로 남는다. 갱신이 부담스러운 분량이라면 분량 자체가 잘못된 것이다.
• "범위 제외"를 문서화하지 않고 그냥 생략한다. 나중에 "왜 안 봤냐"는 질문에 답할 근거가 없어진다. 제외 이유까지 한 줄로 적으면 전제가 깨졌을 때 다시 열어볼 수 있다.
• 계획서를 QA만 보는 내부 문서로 취급한다. 개발·기획과 공유해 기대치를 맞추는 게 계획서의 핵심 가치 중 하나다.
• 어느 프로젝트에나 복사해 넣어도 맞는 문장으로 칸을 채운다. "기능 테스트와 회귀 테스트를 수행한다"에는 아무 결정이 없다. 결정이 없는 문장은 지워도 되는 문장이다.
• 일정 칸에 "충분한 기간", "가능한 빨리" 같은 검증 불가능한 표현을 쓴다. 날짜가 없으면 일정이 밀렸을 때 협상할 근거도 함께 사라진다.
• 리스크 칸에 위험만 적고 대응을 안 적는다. "예상치 못한 이슈가 있을 수 있다"는 모든 프로젝트에 참이라 정보량이 0이다. 그 리스크 때문에 계획을 어떻게 바꿨는지가 같이 있어야 한다.
• 분량으로 성실함을 증명하려 한다. 100페이지는 읽히지 않고 갱신되지 않는다. 문서의 목적은 합의를 만드는 것이지 분량을 채우는 게 아니다.
• 템플릿의 모든 칸을 의무적으로 채운다. 항목은 형식이 아니라 빠뜨리지 않기 위한 점검 목록이다. 해당 없으면 "해당 없음 — 이유"라고 쓰는 편이 억지로 채운 문장보다 낫다.
• "애자일이니까 계획은 필요 없다"고 말한다. 애자일에서 계획서가 얇아지는 건 항목이 백로그·완료 정의·티켓으로 옮겨갔기 때문이지 사라졌기 때문이 아니다. 범위·종료 조건·리스크가 어디에도 없다면 그건 애자일이 아니라 무계획이다.
• 다른 조직의 형식을 그대로 가져온다. 규제 산업의 승인 절차는 증명 책임에서 나온 것이라, 그 책임이 없는 조직이 형식만 흉내 내면 비용만 남는다.

참고 자료

• ISTQB Foundation Level Syllabus — Test Planning — 테스트 계획의 표준 구성 요소
• ISO/IEC/IEEE 29119-3 — 테스트 계획 문서의 공식 표준 (모듈 8에서 상세히)
• Agile Manifesto — "계획을 따르기보다 변화에 대응하기"의 원문. 계획을 버리라고 하지 않았다는 점을 직접 확인해볼 것
• Rex Black, Managing the Testing Process — 계획서 항목별로 무엇을 어떻게 쓰는지 실무 예시가 풍부하다
• Lisa Crispin & Janet Gregory, Agile Testing — 애자일 팀에서 계획이 어떤 형태로 남는지, 완료 정의와의 관계