조직 테스트 프로세스: 테스트 정책과 테스트 전략

개념

운전을 생각하면 세 계층이 바로 잡힌다. 교통법규는 모든 운전자에게 적용되는 원칙이고, 회사의 차량 운행 지침은 그 법규 안에서 우리 회사가 택한 방식(안전 교육 주기, 점검 항목)이고, 오늘의 운행 계획은 이 차가 어디를 어떻게 가는지다.

세 층은 범위와 수명이 다르다. 법규는 거의 안 바뀌고 모두에게 적용되며, 오늘의 계획은 매일 새로 쓴다. 테스트도 똑같다.

이 레슨이 다루는 조직 계층은 QA 개인이 매일 쓰는 문서가 아니다. 그래서 "나와 상관없다" 고 느끼기 쉬운데, 실제로는 내 프로젝트 계획이 왜 이렇게 생겼는지를 설명하는 층이다.

세 계층의 테스트 프로세스

Part 2(레슨 2에서 배운 구조)는 테스트 프로세스를 조직 → 관리 → 동적이라는 세 계층으로 나눈다. 이 레슨은 가장 위 계층인 조직 테스트 프로세스를 다룬다. 나머지 두 계층(관리·동적)은 레슨 4, 5에서 이어서 다룬다.

조직 테스트 프로세스   — 회사 전체의 원칙 (이 레슨)
  └ 관리 테스트 프로세스 — 프로젝트별 계획·실행 관리 (레슨 4)
      └ 동적 테스트 프로세스 — 실제 테스트 설계·실행 (레슨 5)

테스트 정책(Test Policy)

조직 전체가 테스트를 대하는 최상위 원칙이다. "우리 회사는 왜 테스트를 하는가", "품질에 대해 어떤 기준을 갖는가" 같은, 특정 프로젝트가 아니라 회사 전체에 적용되는 선언이다.

예시: "모든 제품은 배포 전 자동화된 회귀 테스트를 통과해야 하며, 심각도 높음 결함이 잔존한 상태로는 릴리스하지 않는다."

정책에 보통 들어가는 항목은 정해져 있다. 길지 않다 — 한두 장이면 충분하다.

좋은 정책과 나쁜 정책

정책이 죽은 문서가 되는 이유는 거의 하나다 — 판정할 수 없게 썼기 때문이다.

왼쪽은 반박할 수 없고 동시에 아무것도 정하지 않는다. 오른쪽은 지키지 못했을 때 그것이 드러나므로, 지키려는 행동을 만든다.

판정 가능성을 가늠하는 방법이 하나 있다 — "이 문장을 어겼는지 어떻게 아나" 를 물어 본다. 답이 안 나오면 선언이고 정책이 아니다.

정책이 실제로 쓰이는 순간

평소에는 캐비닛에 있다. 아래 네 순간에 꺼내진다.

두 번째가 QA에게 가장 값지다. 모듈 6 레슨 3에서 본 "릴리즈를 QA가 막지 않는다" 와 이어진다 — 정책이 있으면 QA는 판단을 대신하지 않고 기준을 가리키기만 하면 된다. 그리고 그 기준은 이미 조직이 합의한 것이다.

조직 테스트 전략(Organizational Test Strategy)

테스트 정책을 실현하기 위한, 조직 차원의 공통 접근 방식이다. 모듈 4(레슨 1)에서 배운 프로젝트별 테스트 전략과 헷갈리기 쉬운데, 차이는 이렇다.

조직 테스트 전략이 "우리 회사는 항상 이렇게 접근한다"는 공통 틀을 주면, 각 프로젝트는 그 틀 안에서 프로젝트별 세부 전략(모듈 4에서 배운 것)을 만든다.

조직 테스트 전략에 들어가는 항목은 정책보다 구체적이다.

일곱 번째 줄이 미묘하지만 중요하다. 조직이 종료 조건의 값을 정하는 것이 아니라 형식을 정한다. "모든 프로젝트는 종료 조건을 숫자로 정의한다" 는 조직 전략이고, "오류율 2% 미만" 은 프로젝트 계획이다.

세 층을 한 표로

헷갈리기 쉬우니 축을 나란히 둔다.

"수명" 줄이 가장 실용적인 구분이다. 자꾸 고쳐야 하는 내용이 정책에 들어가 있으면 그 정책은 금방 거짓이 되고(모듈 7 레슨 7의 수명 분류와 같은 문제), 반대로 거의 안 바뀌는 원칙이 매 프로젝트 계획에 복사되어 있으면 버전이 갈린다.

조직 계층이 있어야 하는 이유

프로젝트마다 테스트 전략을 완전히 새로 만들면, 매번 바퀴를 다시 발명하는 셈이다. 조직 수준의 정책·전략이 있으면, 새 프로젝트는 그걸 기반으로 빠르게 시작할 수 있고, 여러 프로젝트에 걸쳐 일관된 품질 기준을 유지할 수 있다.

없을 때 나타나는 증상은 구체적이다.

세 번째가 QA가 가장 자주 체감하는 것이고, 이 한 가지만으로도 정책을 만들 이유가 된다. 모듈 7 레슨 6의 TMMi 레벨 3이 요구하는 "조직 표준 절차" 가 정확히 이 층이다.

누가 이 계층을 담당하는가

보통 QA 리드, 테스트 관리자, 또는 품질 담당 임원이 조직 테스트 정책·전략을 수립하고 유지보수한다. 개별 QA 엔지니어가 매일 이 문서를 쓰는 건 아니지만, 자신이 만드는 프로젝트별 테스트 계획이 이 상위 원칙과 어긋나지 않는지 확인하는 감각은 모두에게 필요하다.

작은 조직의 최소판 — 한 장으로 시작한다

"우리는 QA가 두 명인데 조직 정책이 필요한가" 라는 질문이 자연스럽다. 답은 필요하지만 분량이 다르다는 것이다. 한 장이면 충분하고, 그 한 장이 주는 효과는 분량과 비례하지 않는다.

■ QA 원칙 (v1 · 2026-10-08 · 소유: QA 리드)
 
1. 무엇을 지키나
   - S1(서비스 불가) 결함이 남은 상태로 릴리즈하지 않는다
   - 결제·인증·개인정보 영역은 매 릴리즈 확인한다
 
2. 어떻게 범위를 정하나
   - 리스크 기반으로 정하고 근거를 계획에 한 줄 남긴다
   - 못 본 영역은 릴리즈 보고에 적는다
 
3. 무엇을 반드시 남기나
   - 릴리즈별: 테스트 범위 한 장, 결과 요약, 미확인 영역
   - 결함은 전부 도구에 등록한다(메신저로 끝내지 않는다)
 
4. 릴리즈 판단
   - QA는 사실과 영향을 제공하고, 판단은 팀이 한다
   - 예외는 사유를 기록한다
 
5. 점검
   - 분기마다 이 문서를 읽고 지켜지는지 확인한다

다섯 줄의 제목만 봐도 이 모듈과 모듈 4·6·7의 내용이다. 새로 만드는 것이 아니라 이미 하고 있는 것을 적는 것이다.

그리고 1번의 두 번째 줄처럼 영역 이름을 박아 두는 것이 작은 조직에서 특히 효과가 크다. 바쁠 때 가장 먼저 생략되는 영역을 문서가 막아 준다.

만드는 순서 — 역순으로 쓴다

빈 종이에 "우리의 테스트 정책" 을 쓰려 하면 막힌다. 순서를 뒤집는다.

1번부터 시작하는 것이 핵심이다. 이상적인 정책을 쓰면 아무도 못 지키고, 못 지키는 정책은 없는 것보다 나쁘다(어기는 것이 일상이 되면 다른 항목도 가볍게 다뤄진다).

4번의 "하나만" 도 의도적이다. 현실과 다른 항목이 여러 개 들어가면 정책 전체의 신뢰가 떨어진다. 모듈 7 레슨 6의 "분기마다 하나" 와 같은 속도다.

정책과 어긋나는 프로젝트가 생길 때

실무에서 반드시 온다. "이번엔 일정이 급해서 S1 하나 남기고 나갑니다" 같은 상황이다. 정책이 있는 조직의 처리 방식이 정해져 있다.

이것이 정책을 지키는 방법이다. 예외를 금지하면 사람들이 예외를 숨기고, 숨겨진 예외는 기록이 없어 반복된다. 예외를 기록 가능하게 만드는 쪽이 실제로 더 잘 지켜진다.

그리고 예외가 같은 항목에서 반복되면 그것은 정책을 고칠 신호다 — 현실과 맞지 않는 항목이기 때문이다.

정책을 고치는 계기

정책은 수년을 가지만 영구적이지 않다. 고칠 계기가 정해져 있다.

• 규제·계약 요구가 바뀌었다(레슨 1의 규제 지도)
• 사업 영역이 늘었다 — 결제·의료·해외 진출
• 같은 예외가 반복된다 — 현실과 안 맞는 항목
• 사고가 났고 그 시점에 아무도 그것을 볼 수 없었다(모듈 10)
• 조직 규모가 바뀌었다(모듈 7 레슨 9)

네 번째가 가장 값진 개정 계기다. 사고 회고에서 "누가 놓쳤나" 대신 "어떤 기준이 없었나" 를 물으면 그 답이 정책 한 줄이 된다. 모듈 5 레슨 14의 치트시트 보강과 같은 구조이고, 차이는 적용 범위가 조직 전체라는 점이다.

사례 — 릴리즈 싸움이 사라진 한 문장

제품 3개를 가진 조직인데, 릴리즈마다 같은 대화가 반복됐다. 미해결 S1이 있을 때 내보낼지 말지를 매번 처음부터 논의했고, 결론은 그날의 분위기와 발언한 사람에 따라 달랐다.

QA 리드가 정책에 두 문장을 넣었다.

1-1. S1(서비스 불가·데이터 손상) 결함이 남은 상태로 릴리즈하지 않는다.

1-2. 1-1의 예외는 제품 책임자의 승인과 해소 기한 기록을 조건으로 허용한다.

1-2가 없으면 1-1이 지켜지지 않았을 것이다. 예외를 허용하지 않으면 급한 날에 정책을 무시하거나 결함 등급을 깎게 되고(모듈 6 레슨 1의 "심각도를 깎는" 문제), 둘 다 정책을 죽이는 길이다.

6개월 뒤 돌아보니 예외는 3건이었고, 그중 2건이 같은 영역이었다. 그 사실이 다음 분기 개선 과제가 됐다 — 기록이 없었다면 보이지 않았을 패턴이다.

실무에서 왜 필요한가

프로젝트마다 QA 접근 방식이 제각각인 조직은, 프로젝트를 옮겨 다니는 QA 엔지니어가 매번 새로 적응해야 하고, 경영진 입장에서도 "우리 회사의 품질 수준이 어느 정도인지" 종합적으로 파악하기 어렵다. 조직 테스트 프로세스가 명확한 조직은 신규 입사자 온보딩도 빠르고, 여러 프로젝트의 품질을 일관된 기준으로 비교할 수 있다. 이건 모듈 7(레슨 6)에서 배운 TMMi 레벨 3(Defined) — 조직 전체에 표준화된 프로세스가 있는 상태 — 와 정확히 맞닿아 있다.

QA 개인에게 돌아오는 것

이 계층을 "리드의 일" 로만 보면 손해다. 개별 QA에게도 세 가지가 돌아온다.

두 번째가 가장 실용적이다. "결제는 매 릴리즈 확인" 이 정책에 있으면, 일정이 급할 때 그 영역을 빼라는 요구에 개인이 맞서지 않아도 된다. 문서가 대신 막아 준다.

정책이 QA를 보호한다

조금 다른 각도의 이유가 하나 더 있다. 사고가 났을 때 "QA가 왜 못 잡았나" 라는 질문이 온다(모듈 6 레슨 3). 정책과 계획에 범위와 미확인 영역이 적혀 있으면 그 대화가 사람의 문제에서 기준의 문제로 옮겨진다.

"정책에 따라 리스크 기반으로 범위를 정했고, 저사양 기기는 미확인으로 보고에 적혀 있습니다. 그 영역을 범위에 넣으려면 기기 확보가 필요합니다."

이것이 변명이 아니라 다음 결정을 가능하게 하는 보고다. 기준이 없으면 같은 상황이 개인의 부주의로 처리된다.

채용시장에서의 위치

조직 계층은 QA 리드·테스트 관리자 공고의 핵심 요건이고, 실무자 면접에서는 "정책과 전략의 차이" 정도로 가볍게 나온다.

세 번째가 가장 변별력이 크다. 규칙을 지키게 만드는 방법을 아는 사람과 선언하는 사람의 차이가 거기서 드러난다. 예외를 설계에 포함 하는 사고는 실제로 운영해 본 사람의 것이다.

두 번째도 좋다. "지금 하는 것을 적는다" 는 답은 문서가 현실을 앞서면 죽는다는 것을 아는 사람의 답이다(모듈 7 레슨 7).

공고 표현으로는 "QA 정책 수립", "품질 기준 정의", "테스트 전략 수립", "전사 품질 체계" 가 이 레슨에 걸린다. 그리고 규제 산업에서는 조직 수준 문서가 제출·심사 대상이므로 비중이 더 크다(레슨 1).

실습 과제

과제 1 — 정책과 전략 구분하기 (10분)

다음 세 문장이 테스트 정책·조직 테스트 전략·프로젝트 테스트 전략 중 어디에 해당하는지 분류한다.

1. "모든 제품은 출시 전 접근성(Accessibility) 기준을 만족해야 한다"
2. "모든 프로젝트는 릴리스 2주 전부터 코드 프리즈 후 회귀 테스트 기간을 갖는다"
3. "이번 프로젝트는 신규 결제 연동이 핵심 리스크이므로, 결제 플로우에 테스트 리소스의 60%를 배정한다"

과제 2 — 우리 조직에 적용해보기 (10분)

가상의 회사("주문 배달 스타트업")를 하나 상상해, 그 회사에 어울릴 만한 테스트 정책 한 문장과 조직 테스트 전략 한 문장을 직접 작성한다.

과제 3 — 최소 정책 한 장 쓰기 (15분)

본문의 "작은 조직 최소판" 틀을 그대로 써서, 자신이 아는 팀(또는 가상의 팀)의 QA 원칙 한 장을 작성한다. 조건이 둘이다 — 지금 실제로 하고 있는 것만 적고, 현실과 다른 항목은 하나만 넣는다.

자가 체크리스트

• 조직·관리·동적 테스트 프로세스 세 계층의 관계를 설명할 수 있다
• 테스트 정책과 조직 테스트 전략의 차이를 설명할 수 있다
• 조직 테스트 전략과 프로젝트 테스트 전략(모듈 4)의 차이를 예시로 설명할 수 있다
• 조직 계층의 프로세스가 왜 필요한지 설명할 수 있다
• 정책에 들어가는 여섯 항목을 들 수 있다
• 판정 가능한 정책과 선언을 구분하고, 가늠하는 질문을 안다
• 정책이 꺼내지는 네 순간을 말할 수 있다
• 조직 전략이 값이 아니라 형식을 정한다는 것을 예로 설명할 수 있다
• 세 층의 수명 차이와 그것을 지켜야 하는 이유를 설명할 수 있다
• 조직 계층이 없을 때의 증상 여섯 가지를 들 수 있다
• 작은 조직의 한 장 최소판에 들어갈 다섯 항목을 말할 수 있다
• 정책을 역순으로(지금 하는 것부터) 만드는 이유를 설명할 수 있다
• 예외를 기록 가능하게 만드는 것이 왜 더 잘 지켜지는지 설명할 수 있다
• 정책을 고칠 다섯 계기를 들 수 있다
• 정책이 사고 이후 대화를 기준의 문제로 옮기는 방식을 설명할 수 있다

흔한 실수

• 조직 테스트 전략과 프로젝트 테스트 전략을 같은 것으로 혼동한다. 범위와 목적이 다르다 — 하나는 회사 전체, 하나는 프로젝트 하나에 국한된다.
• 테스트 정책을 형식적인 문서로만 취급하고 실제 프로젝트 전략이 정책과 어긋나도 신경 쓰지 않는다. 상위 원칙과의 정합성을 확인하는 습관이 필요하다.
• 이 계층이 대기업에만 필요하다고 생각한다. 작은 조직도 최소한의 공통 원칙이 있으면 여러 프로젝트를 일관되게 운영하는 데 도움이 된다.
• 판정할 수 없는 문장을 정책으로 쓴다. "최고의 품질을 추구한다"는 반박할 수 없고 동시에 아무것도 정하지 않는다.
• 이상적인 정책을 먼저 쓴다. 못 지키는 정책은 없는 것보다 나쁘다 — 어기는 것이 일상이 되면 다른 항목도 가볍게 다뤄진다.
• 현실과 다른 항목을 여러 개 넣는다. 정책 전체의 신뢰가 떨어진다. 한 번에 하나만 더한다.
• 예외를 금지한다. 사람들이 예외를 숨기고, 숨겨진 예외는 기록이 없어 반복된다. 기록 가능하게 만드는 쪽이 더 잘 지켜진다.
• 조직 층에 숫자를 박는다. "오류율 2% 미만"은 프로젝트 계획의 값이다. 조직은 "종료 조건을 숫자로 정의한다"는 형식만 정한다.
• 자주 바뀌는 내용을 정책에 넣는다. 금방 거짓이 된다. 수명에 맞는 층에 둔다(모듈 7 레슨 7).
• 거의 안 바뀌는 원칙을 매 프로젝트 계획에 복사한다. 버전이 갈려 어느 것이 맞는지 모르게 된다.
• 점검 주기와 소유자를 안 적는다. 1년 뒤 현실과 어긋나 있고 아무도 고치지 않는다.
• 같은 예외가 반복되는데 정책을 그대로 둔다. 현실과 안 맞는 항목 이라는 신호를 놓치는 것이다.

참고 자료

• ISO/IEC/IEEE 29119-2 개요 — Test Processes — 조직 테스트 프로세스의 공식 정의
• Rex Black, Managing the Testing Process — 조직 수준 테스트 정책·전략 수립을 다룬 실무서
• ISTQB Advanced — Test Management — 테스트 정책·전략 수립이 시험 범위에 포함된다
• TMMi Foundation — 레벨 3(Defined)이 요구하는 조직 표준 절차

이 커리큘럼 안에서

• 모듈 8 레슨 2 — Part 2의 세 계층 구조. 이 레슨은 가장 바깥
• 모듈 8 레슨 4 — 관리 테스트 프로세스(프로젝트 계층)
• 모듈 8 레슨 5 — 동적 테스트 프로세스(실행 계층)
• 모듈 8 레슨 6 — Part 3 템플릿. 정책·전략 문서의 형식
• 모듈 4 레슨 1~2 — 프로젝트 테스트 계획·리스크. 이 층의 안쪽
• 모듈 4 레슨 5 — Go/No-Go. 정책이 기준을 주는 자리
• 모듈 6 레슨 1 — 심각도. 정책의 "S1" 정의가 여기서 온다
• 모듈 6 레슨 3 — 비난 없는 소통. 기준이 사람을 보호하는 방식
• 모듈 7 레슨 6 — TMMi 레벨 3. 이 층이 요구되는 성숙도 단계
• 모듈 7 레슨 7 — 문서 수명·소유자·점검일. 정책 관리 방식
• 모듈 7 레슨 9 — 조직과 사람. 정책이 개인 의존을 줄이는 방식

한 줄 정리 — 조직 계층은 "왜·무엇을 지키나"(정책) 와 "어떻게 접근하나"(전략) 를 정해 프로젝트가 매번 처음부터 만들지 않게 한다. 정책은 판정 가능하게 쓰고, 지금 하고 있는 것부터 적고, 예외를 기록 가능하게 만든다. 분량은 작은 조직이면 한 장으로 충분하고, 그 한 장이 바쁠 때의 생략을 막아 준다.