개념
세 계층의 테스트 프로세스
Part 2(레슨 2에서 배운 구조)는 테스트 프로세스를 조직 → 관리 → 동적이라는 세 계층으로 나눈다. 이 레슨은 가장 위 계층인 조직 테스트 프로세스를 다룬다. 나머지 두 계층(관리·동적)은 레슨 4, 5에서 이어서 다룬다.
조직 테스트 프로세스 — 회사 전체의 원칙 (이 레슨)
└ 관리 테스트 프로세스 — 프로젝트별 계획·실행 관리 (레슨 4)
└ 동적 테스트 프로세스 — 실제 테스트 설계·실행 (레슨 5)테스트 정책(Test Policy)
조직 전체가 테스트를 대하는 최상위 원칙이다. "우리 회사는 왜 테스트를 하는가", "품질에 대해 어떤 기준을 갖는가" 같은, 특정 프로젝트가 아니라 회사 전체에 적용되는 선언이다.
예시: "모든 제품은 배포 전 자동화된 회귀 테스트를 통과해야 하며, 심각도 높음 결함이 잔존한 상태로는 릴리스하지 않는다."
조직 테스트 전략(Organizational Test Strategy)
테스트 정책을 실현하기 위한, 조직 차원의 공통 접근 방식이다. 모듈 4(레슨 1)에서 배운 프로젝트별 테스트 전략과 헷갈리기 쉬운데, 차이는 이렇다.
| 조직 테스트 전략 | 프로젝트 테스트 전략 | |
|---|---|---|
| 범위 | 회사의 모든 프로젝트에 공통 적용 | 특정 프로젝트 하나에만 적용 |
| 예시 내용 | "모든 프로젝트는 위험기반 테스트(모듈 4 레슨 2)를 기본으로 한다" | "이번 프로젝트는 결제 모듈에 리스크가 집중되어 있으니 그 부분을 집중 테스트한다" |
조직 테스트 전략이 "우리 회사는 항상 이렇게 접근한다"는 공통 틀을 주면, 각 프로젝트는 그 틀 안에서 프로젝트별 세부 전략(모듈 4에서 배운 것)을 만든다.
조직 계층이 있어야 하는 이유
프로젝트마다 테스트 전략을 완전히 새로 만들면, 매번 바퀴를 다시 발명하는 셈이다. 조직 수준의 정책·전략이 있으면, 새 프로젝트는 그걸 기반으로 빠르게 시작할 수 있고, 여러 프로젝트에 걸쳐 일관된 품질 기준을 유지할 수 있다.
누가 이 계층을 담당하는가
보통 QA 리드, 테스트 관리자, 또는 품질 담당 임원이 조직 테스트 정책·전략을 수립하고 유지보수한다. 개별 QA 엔지니어가 매일 이 문서를 쓰는 건 아니지만, 자신이 만드는 프로젝트별 테스트 계획이 이 상위 원칙과 어긋나지 않는지 확인하는 감각은 모두에게 필요하다.
실무에서 왜 필요한가
프로젝트마다 QA 접근 방식이 제각각인 조직은, 프로젝트를 옮겨 다니는 QA 엔지니어가 매번 새로 적응해야 하고, 경영진 입장에서도 "우리 회사의 품질 수준이 어느 정도인지" 종합적으로 파악하기 어렵다. 조직 테스트 프로세스가 명확한 조직은 신규 입사자 온보딩도 빠르고, 여러 프로젝트의 품질을 일관된 기준으로 비교할 수 있다. 이건 모듈 7(레슨 6)에서 배운 TMMi 레벨 3(Defined) — 조직 전체에 표준화된 프로세스가 있는 상태 — 와 정확히 맞닿아 있다.
실습 과제
과제 1 — 정책과 전략 구분하기 (10분)
다음 세 문장이 테스트 정책·조직 테스트 전략·프로젝트 테스트 전략 중 어디에 해당하는지 분류한다.
- "모든 제품은 출시 전 접근성(Accessibility) 기준을 만족해야 한다"
- "모든 프로젝트는 릴리스 2주 전부터 코드 프리즈 후 회귀 테스트 기간을 갖는다"
- "이번 프로젝트는 신규 결제 연동이 핵심 리스크이므로, 결제 플로우에 테스트 리소스의 60%를 배정한다"
과제 2 — 우리 조직에 적용해보기 (10분)
가상의 회사("주문 배달 스타트업")를 하나 상상해, 그 회사에 어울릴 만한 테스트 정책 한 문장과 조직 테스트 전략 한 문장을 직접 작성한다.
자가 체크리스트
- 조직·관리·동적 테스트 프로세스 세 계층의 관계를 설명할 수 있다
- 테스트 정책과 조직 테스트 전략의 차이를 설명할 수 있다
- 조직 테스트 전략과 프로젝트 테스트 전략(모듈 4)의 차이를 예시로 설명할 수 있다
- 조직 계층의 프로세스가 왜 필요한지 설명할 수 있다
흔한 실수
- 조직 테스트 전략과 프로젝트 테스트 전략을 같은 것으로 혼동한다. 범위와 목적이 다르다 — 하나는 회사 전체, 하나는 프로젝트 하나에 국한된다.
- 테스트 정책을 형식적인 문서로만 취급하고 실제 프로젝트 전략이 정책과 어긋나도 신경 쓰지 않는다. 상위 원칙과의 정합성을 확인하는 습관이 필요하다.
- 이 계층이 대기업에만 필요하다고 생각한다. 작은 조직도 최소한의 공통 원칙이 있으면 여러 프로젝트를 일관되게 운영하는 데 도움이 된다.
참고 자료
- ISO/IEC/IEEE 29119-2 개요 — Test Processes — 조직 테스트 프로세스의 공식 정의
- Rex Black, Managing the Testing Process — 조직 수준 테스트 정책·전략 수립을 다룬 실무서