관리 테스트 프로세스: 계획, 모니터링·통제, 완료

개념

운전으로 비유하면 세 단계가 이렇다 — 목적지와 경로를 정하고(계획), 가는 동안 내비게이션을 보며 막히면 경로를 바꾸고(모니터링·통제), 도착한 뒤 얼마 걸렸고 어디가 막혔는지 남긴다(완료).

그런데 실무에서는 첫 번째만 하는 팀이 많다. 경로를 정하고 출발한 뒤에는 도착할 때까지 내비를 안 보고, 도착하면 바로 다음 일로 간다.

그래서 이 레슨의 무게는 2단계와 3단계에 있다. 1단계는 모듈 4에서 이미 배웠고, 표준이 세 단계를 굳이 분리해 명시한 이유가 뒤의 둘이 자주 사라지기 때문이다.

관리 계층은 프로젝트 단위로 움직인다

레슨 3에서 배운 조직 테스트 프로세스가 회사 전체의 원칙이었다면, 관리 테스트 프로세스는 그 원칙을 특정 프로젝트에서 실제로 실행하기 위한 관리 활동이다. 표준은 이걸 세 단계로 나눈다.

테스트 계획 (Test Planning)
  → 테스트 모니터링·통제 (Test Monitoring and Control)
    → 테스트 완료 (Test Completion)

1단계 — 테스트 계획(Test Planning)

모듈 4(레슨 1, 4)에서 이미 배운 내용이 바로 이 단계다 — 테스트 범위·리스크·일정·종료 기준을 정하고 테스트 계획서(Test Plan)를 작성한다. 표준은 여기서 조직 테스트 전략(레슨 3)을 이 프로젝트에 어떻게 구체화할지까지 계획에 포함하도록 요구한다.

이 요구가 실무에서 뜻하는 바는 분명하다. 계획서에 "조직 전략의 어느 항목을 이번에 어떻게 적용하는가" 가 적혀야 한다.

세 번째 줄처럼 "따르지 못하는 경우" 도 계획에 적는다. 조직 전략과 어긋나는 선택에 사유를 붙이면 그것이 레슨 3의 예외 기록이 된다. 조용히 안 하면 정책 위반이고, 적으면 판단이다.

계획은 버전이 붙는 문서다

"계획은 계속 갱신된다" 는 말이 추상적으로 들리는데, 실제로 하는 일은 단순하다 — 고친 날짜와 무엇을 왜 바꿨는지를 남기는 것이다.

이 네 줄이 있으면 프로젝트가 끝난 뒤 "왜 이렇게 됐나" 를 설명할 수 있다. 그리고 감사에서 묻는 "일관성"(레슨 1)이 바로 이 지점이다 — 계획과 실제가 다르면 지적이지만, 다르게 된 이력이 적혀 있으면 관리된 변경이다.

반대로 계획서를 조용히 덮어쓰면 처음 계획이 사라진다. 그러면 "원래 뭘 하려 했는지" 를 아무도 모르고, 모듈 7 레슨 7에서 본 "회의록을 고치면 안 되는" 이유와 같은 문제가 생긴다.

2단계 — 테스트 모니터링과 통제(Monitoring and Control)

계획을 세운 뒤 실행하는 동안, 계획과 실제 진행 상황의 차이를 계속 확인하고 필요하면 조정하는 단계다.

• 모니터링: 지금까지 실행한 테스트 케이스 수, 발견된 결함 수, 남은 일정 대비 진행률(모듈 6 레슨 5의 커버리지 지표와 연결)을 계속 추적한다
• 통제: 모니터링 결과 계획과 크게 어긋나면(예: 예상보다 결함이 훨씬 많이 나온다) 일정을 조정하거나, 우선순위를 재배정하거나, 추가 리소스를 요청하는 등 조치를 취한다

계획은 한 번 세우고 끝이 아니라, 이 모니터링·통제 루프를 통해 계속 살아있는 문서로 갱신된다.

무엇을 얼마나 자주 보나

"계속 추적한다" 를 그대로 두면 아무것도 안 한다. 주기를 정해 둔다.

매일 보는 것을 둘로 줄인 것이 의도적이다. 매일 열 가지를 보려 하면 삼일 만에 그만둔다. 재검증 대기와 차단은 둘 다 방치되면 릴리즈 직전에 터지는 항목이라 매일 볼 가치가 있다.

어긋남의 신호와 조치

모니터링의 핵심은 숫자를 보는 것이 아니라 "이 숫자면 무엇을 하나" 가 정해져 있는 것이다. 미리 짝지어 두면 그 순간에 고민하지 않는다.

마지막 두 줄이 자주 오해된다. 결함이 안 나오는 것을 좋은 신호로만 읽으면 미탐을 놓치고, Blocked를 "우리 탓이 아니니 괜찮다" 로 두면 그 건이 릴리즈를 막는 폭탄이 된다.

조치에는 네 개의 레버가 있다

통제 단계에서 쓸 수 있는 수단은 결국 네 가지다. 그리고 공짜는 없다.

QA가 가장 많이 쓰고 가장 정당한 레버가 범위다(모듈 4의 리스크 기반). 그리고 네 번째를 쓸 때는 반드시 기록한다 — 레슨 3의 예외 처리가 여기서 적용된다.

중요한 것은 QA가 레버를 당기는 사람이 아니라는 점이다. QA는 어떤 레버가 어떤 대가를 갖는지 보여 주고, 선택은 책임자가 한다(모듈 6 레슨 3).

"현재 실행률이 60%이고 일정은 3일 남았습니다. 선택지는 셋입니다 — 저위험 영역 2개를 제외(범위), 이틀 연장(시간), 또는 S2 2건을 허용 (기준 완화). 각각의 미확인 영역은 이렇습니다."

3단계 — 테스트 완료(Test Completion)

테스트 활동이 끝나면(릴리스 시점 또는 프로젝트 종료 시점), 결과를 정리하고 배운 점을 남긴다.

• 테스트 완료 보고서 작성(레슨 6에서 실제 형식을 다룬다)
• 테스트 산출물(테스트 케이스, 테스트 데이터, 자동화 스크립트)을 다음 프로젝트나 유지보수 팀이 재사용할 수 있도록 정리·인계
• 회고(Retrospective) — 무엇이 잘 됐고 무엇을 다음에 개선할지 기록

이 마지막 단계를 생략하는 팀이 실무에서 매우 많다 — 릴리스가 끝나면 바로 다음 작업으로 넘어가느라, 배운 점을 기록하고 공유하는 과정이 통째로 사라지는 경우다.

완료 단계에서 실제로 할 것

막연히 "정리한다" 로 두면 안 한다. 목록으로 고정해 둔다.

네 번째 줄이 가장 저평가된다. 계획 시간과 실제 시간을 나란히 남기면 다음 추정의 근거가 되고, 그것이 없으면 추정은 영원히 감에 머문다.

다섯 번째와 여섯 번째는 미루면 영구히 안 한다. 특히 테스트 데이터를 정리하지 않으면 다음 프로젝트의 환경이 오염된 상태로 시작된다.

왜 완료 단계가 사라지나

의지 문제가 아니다. 구조적인 이유가 있다.

• 릴리즈 직후가 가장 바쁘다 — 운영 모니터링과 긴급 대응이 겹친다
• 완료 작업은 아무도 독촉하지 않는다 — 다음 기능은 독촉된다
• 효과가 다음 프로젝트에 나타난다 — 지금은 보상이 없다

그래서 의지로 막지 않고 장치로 막는다.

네 번째가 실질적이다. 완료 보고를 "제대로 쓰려면 반나절" 로 여기면 영원히 안 쓴다. 30분짜리 한 장으로 정의하면 매번 쓰인다.

모니터링·통제·완료는 한 번으로 끝나지 않는다

애자일 환경(모듈 7 레슨 4)에서는 이 세 단계가 스프린트마다 짧은 주기로 반복된다 — 워터폴처럼 프로젝트 전체에 한 번만 적용되는 게 아니라, 매 스프린트가 작은 계획-모니터링-완료 사이클을 도는 셈이다.

실무에서는 세 주기가 겹쳐서 돈다.

스프린트  ├─계획─실행─완료─┤├─계획─실행─완료─┤├─계획─실행─완료─┤
릴리즈    ├──────── 계획 ────── 모니터링 ────── 완료 ────────┤
프로젝트  ├────────────── 계획 ─────── 모니터링 ─────── 완료 ──┤

이 그림이 알려 주는 것이 둘이다. 첫째, 같은 활동을 세 번 하는 것이 아니다 — 주기마다 보는 단위가 다르다. 스프린트 완료는 스토리 단위 결과이고, 릴리즈 완료는 전체 범위와 미확인 영역이고, 프로젝트 완료는 산출물 인계와 배운 점이다.

둘째, 겹치면 하나로 합칠 수 있다. 2주 스프린트에 매번 거창한 완료 보고를 쓰면 부담이므로, 스프린트는 회고 한 줄로, 릴리즈는 한 장, 프로젝트는 정식 보고서로 분량을 다르게 둔다.

애자일에서 이 세 단계가 매핑되는 자리는 모듈 7 레슨 8에서 본 이벤트들이다.

모니터링이 데일리에 대응한다는 점이 중요하다. 애자일 팀에서 "모니터링 문서를 따로 만들라" 는 요구는 과하고, 보드와 데일리가 그 역할을 이미 하고 있다(레슨 1의 테일러링).

사례 — 모니터링이 없어서 3일 전에 알게 된 일

릴리즈 2주 전에 계획을 세웠고, 범위는 케이스 240건이었다. 그 뒤 아무도 진행률을 보지 않았다.

D-3에 알게 된 것이 문제의 전부다. 같은 정보를 D-10에 알았다면 선택지가 많았다 — 환경 복구 우선순위를 올리거나, 범위를 미리 조정하거나, 인력을 재배치할 시간이 있었다. D-3에는 범위 축소와 연장 둘뿐이었다.

바꾼 것은 세 가지였고, 전부 가벼웠다.

1. 매일 아침 5분 — 재검증 대기와 Blocked 건수만 공유
2. 주 1회 한 줄 보고 — "실행 X/240, 미해결 고위험 Y건, 차단 Z건"
3. 신호와 조치를 미리 짝지음 — 실행률이 일정 대비 70% 미만이면 그 주에 범위 재논의

다음 릴리즈에서 같은 일이 생겼다. 환경 장애로 이틀이 날아갔는데, 이번에는 D-9에 보고됐다. 결과는 저위험 영역 3개를 제외하고 일정을 지킨 것이었다 — 긴급 회의도 없었고 연장도 없었다.

모니터링의 가치는 문제를 막는 것이 아니라 선택지를 남기는 것이다. 문제는 어차피 생기고, 일찍 알면 싼 선택이 남아 있다.

실무에서 왜 필요한가

"계획은 세웠는데 실행 중 아무도 진행 상황을 추적하지 않아서, 릴리스 직전에야 테스트가 한참 밀렸다는 걸 알게 됐다"는 실패는 모니터링·통제 단계가 빠졌을 때 생긴다. "테스트는 끝났는데 뭘 했는지 아무 기록도 안 남았다"는 완료 단계가 빠졌을 때 생긴다. 표준이 이 세 단계를 명시적으로 구분하는 이유는, 실무에서 특히 자주 빠지는 두 번째·세 번째 단계를 놓치지 않게 하기 위해서다.

일찍 알면 선택지가 싸다

이 레슨의 실용적 요지 한 줄이다. 같은 문제라도 아는 시점에 따라 쓸 수 있는 수단이 다르다.

그래서 모니터링은 일을 늘리는 활동이 아니라 선택지를 사는 활동이다. 하루 5분이 그 값이다.

완료 기록이 다음 추정을 만든다

모듈 5 레슨 13에서 "계획 대비 실제를 남겨야 추정이 경험 데이터가 된다" 고 했다. 그것을 실제로 남기는 자리가 완료 단계다.

네다섯 번만 쌓이면 우리 팀의 숫자가 나온다 — 회귀에 실제로 며칠 걸리는지, 결함 하나당 재검증에 얼마나 드는지. 그 숫자가 있으면 다음 계획에서 "감으로 잡았다" 는 말을 안 하게 된다(모듈 7 레슨 9의 증원 요청 사례도 이런 숫자 위에서 성립했다).

채용시장에서의 위치

관리 프로세스는 리드·테스트 관리자 공고의 중심이고, 실무자에게도 "진행 상황을 어떻게 관리했나" 로 물어진다.

두 번째가 가장 변별력이 크다. "야근한다" 는 답은 레버를 모르는 사람의 답이고, 네 레버와 대가를 말하는 사람은 관리를 해 본 사람 으로 읽힌다. 그리고 "선택은 책임자가 한다" 까지 붙으면 QA의 자리를 아는 사람이 된다(모듈 6 레슨 3).

다섯 번째도 좋은 답이다. 표준을 형식이 아니라 기능으로 읽는 태도가 드러난다(모듈 7 레슨 6과 같은 관점).

공고 표현으로는 "테스트 진행 관리", "테스트 리드", "QA 일정·범위 관리", "테스트 완료 보고" 가 이 레슨에 걸린다.

실습 과제

과제 1 — 모니터링 지표 설계하기 (10분)

진행 중인 프로젝트의 테스트 상황을 매주 추적하려 한다. 어떤 지표 (모듈 6 레슨 5 참고) 3가지를 매주 확인할지 정하고, 그 지표가 계획과 크게 어긋났을 때 취할 수 있는 조치를 하나씩 적는다.

과제 2 — 완료 단계 체크리스트 만들기 (10분)

한 릴리스의 테스트가 끝났을 때, "완료" 단계에서 반드시 해야 할 일 목록을 4가지 이상 작성한다.

과제 3 — 통제 선택지 제시하기 (15분)

릴리즈 3일 전이고 상황은 아래와 같다. 네 레버를 각각 적용한 선택지와 그 대가를 정리해, 책임자에게 전달할 문장을 만든다.

• 계획 240건 중 실행 150건(63%)
• 미해결 S1 1건(결제 금액 오류), S2 3건
• Blocked 30건 — 로그인 결함 1건이 원인
• QA 2명, 남은 3일

자가 체크리스트

• 관리 테스트 프로세스의 세 단계(계획·모니터링과 통제·완료)를 순서대로 설명할 수 있다
• 테스트 계획이 한 번 세우고 끝나는 게 아니라 계속 갱신되는 이유를 설명할 수 있다
• 테스트 완료 단계에서 실무가 자주 놓치는 부분을 설명할 수 있다
• 애자일 환경에서 이 세 단계가 어떻게 반복되는지 설명할 수 있다
• 계획서에 조직 전략을 어떻게 구체화했는지 적는 이유를 설명할 수 있다
• 조직 전략을 못 따를 때 사유를 적으면 판단이 된다는 것을 안다
• 계획서에 버전과 변경 사유를 남기는 것이 감사의 "일관성" 과 어떻게 이어지는지 설명할 수 있다
• 매일 볼 것 둘(재검증 대기·Blocked)과 그 이유를 말할 수 있다
• 신호와 조치를 미리 짝지어 두는 이유를 설명할 수 있다
• 통제의 네 레버와 각각의 대가를 말할 수 있다
• QA가 레버를 당기는 사람이 아니라는 것을 설명할 수 있다
• 완료 단계 체크리스트 여덟 항목 중 가장 값진 둘을 고를 수 있다
• 완료 단계가 사라지는 구조적 이유와 막는 장치를 말할 수 있다
• 스프린트·릴리즈·프로젝트 세 주기의 분량을 다르게 두는 이유를 안다
• 일찍 알면 선택지가 싸다는 것을 레버 표로 설명할 수 있다

흔한 실수

• 계획만 세우고 실행 중 모니터링을 하지 않는다. 계획과 현실의 차이를 릴리스 직전에야 발견하게 된다.
• 테스트 완료 단계를 생략하고 바로 다음 작업으로 넘어간다. 배운 점과 산출물이 다음 프로젝트에 전달되지 않아, 같은 실수가 반복된다.
• 모니터링에서 계획과의 차이를 발견해도 아무 조치를 취하지 않는다. 모니터링과 통제는 한 쌍이다 — 확인만 하고 조정을 안 하면 의미가 없다.
• 매일 열 가지를 보려 한다. 삼일 만에 그만둔다. 재검증 대기와 Blocked 둘로 줄인다.
• 임계값 없이 "많이 어긋나면"으로 둔다. 판단이 매번 달라진다. "실행률 70% 미만" 처럼 숫자로 정해 두면 논의가 자동으로 열린다.
• 숫자만 보고 레버를 당긴다. Blocked 30건의 원인이 결함 1건이면 공짜로 풀 수 있는 것을 포기하는 것이다. 원인과 함께 읽는다.
• QA가 레버를 직접 당긴다. 대가를 보여 주는 것이 QA의 일이고, 선택은 책임자가 한다.
• 품질 기준을 완화하면서 기록을 안 남긴다. 레슨 3의 예외 처리가 여기서 적용된다.
• 계획서를 조용히 덮어쓴다. 처음 계획이 사라져 "원래 뭘 하려 했는지"를 아무도 모른다. 버전과 사유를 남긴다.
• 결함이 안 나오는 것을 좋은 신호로만 읽는다. 깊이가 부족한 것일 수 있다(모듈 5 레슨 13의 수확 체감 판단).
• 완료 보고를 완벽하게 쓰려 한다. 반나절짜리로 여기면 영원히 안 쓴다. 30분 한 장으로 정의한다.
• 계획 대비 실제 시간을 안 남긴다. 추정이 영원히 감에 머문다.
• 테스트 데이터·환경 정리를 미룬다. 다음 프로젝트가 오염된 환경에서 시작된다.

참고 자료

• ISO/IEC/IEEE 29119-2 개요 — Test Management Process — 관리 테스트 프로세스의 공식 정의
• Rex Black, Managing the Testing Process — 테스트 모니터링·통제 실무 기법을 다룬 장
• ISTQB Advanced — Test Management — 모니터링·통제와 완료 활동이 시험 범위에 포함된다

이 커리큘럼 안에서

• 모듈 8 레슨 3 — 조직 계층. 이 레슨이 구체화하는 상위 원칙
• 모듈 8 레슨 5 — 동적 테스트 프로세스. 이 레슨의 안쪽 계층
• 모듈 8 레슨 6 — Part 3 템플릿. 계획서·상태 보고·완료 보고의 형식
• 모듈 4 레슨 1~2 — 테스트 계획과 리스크. 1단계의 내용
• 모듈 4 레슨 4~5 — 종료 조건·Go/No-Go. 임계값과 판단의 자리
• 모듈 5 레슨 13 — 추정과 종료 판단. 계획 대비 실제를 남기는 이유
• 모듈 6 레슨 3 — 사실과 영향을 주고 판단은 맡기는 태도
• 모듈 6 레슨 5 — 지표. 모니터링에 쓰는 숫자의 출처
• 모듈 7 레슨 1 — Blocked·Skipped. 매일 보는 항목의 정의
• 모듈 7 레슨 7~8 — 완료 보고를 DoD와 템플릿으로 강제하는 방법
• 모듈 7 레슨 9 — 조직. 완료 기록이 증원·자원 요청의 근거가 된다

한 줄 정리 — 표준이 세 단계를 분리한 이유는 2단계와 3단계가 자주 사라지기 때문이다. 모니터링은 일을 늘리는 활동이 아니라 선택지를 사는 활동이고(일찍 알면 싼 레버가 남아 있다), 통제의 레버는 범위·시간· 인력·기준 넷뿐이며 QA는 대가를 보여 주고 선택은 책임자가 한다. 그리고 완료 보고는 30분 한 장으로 정의해야 실제로 쓰인다.