동적 테스트 프로세스: 설계·구현부터 실행·인시던트 보고까지

개념

요리로 비유하면 네 단계가 이렇다 — 레시피를 정하고(설계), 재료와 도구를 준비하고(환경), 조리하고(실행), 맛이 예상과 다르면 적는다 (인시던트 보고).

표준이 이 층을 굳이 네 단계로 쪼갠 이유가 여기서 보인다. 재료를 조리 중에 사러 가면 요리가 망한다. 실무에서 가장 흔한 실패가 그것이다 — 테스트 환경과 데이터를 실행 직전에 급하게 준비해서 실행 시간을 거기 다 쓰는 것.

그리고 마지막 단계의 이름이 "결함 보고" 가 아니라 "인시던트 보고" 인 것도 의도적이다. 맛이 다른 이유가 레시피가 틀렸을 수도, 재료가 상했을 수도 있기 때문이다.

가장 실무에 가까운 계층

레슨 3(조직)과 레슨 4(관리)가 "원칙을 세우고 관리하는" 계층이었다면, 동적 테스트 프로세스는 실제로 손을 움직여 테스트 케이스를 만들고 실행하는, 이 강의 대부분의 모듈(3, 5 등)에서 이미 실습해온 활동 그 자체다. 표준은 이 활동을 네 단계로 정의한다.

테스트 설계·구현 (Test Design and Implementation)
  → 테스트 환경 구축 (Test Environment Set-Up and Maintenance)
    → 테스트 실행 (Test Execution)
      → 테스트 인시던트 보고 (Test Incident Reporting)

1단계 — 테스트 설계와 구현

모듈 3에서 배운 동등분할·경계값분석 같은 기법으로 테스트 조건 → 테스트 케이스 → 테스트 절차를 만드는 단계다. 표준은 이 산출물의 계층을 명확히 구분한다.

• 테스트 조건(Test Condition) — "무엇을 확인해야 하는가"(예: "할인율이 올바르게 적용되는지")
• 테스트 케이스(Test Case) — 조건을 검증하기 위한 구체적인 입력값과 기대 결과
• 테스트 절차(Test Procedure) — 여러 테스트 케이스를 어떤 순서로 실행할지 정리한 실행 스크립트

세 계층을 나누는 이유

"그냥 케이스만 쓰면 되지" 싶은데, 나누면 재사용과 추적이 쉬워진다. 실물로 보면 분명하다.

테스트 조건  TC-A  "쿠폰 할인이 주문 금액에 올바르게 반영된다"
                   (출처: 요구 REQ-014)
      │
      ├─ 케이스 1  10% 쿠폰 · 주문 10,000원 → 할인 1,000원
      ├─ 케이스 2  10% 쿠폰 · 수량 2로 변경 → 할인 2,000원
      ├─ 케이스 3  최소 주문 금액과 같을 때 → 적용됨
      └─ 케이스 4  최소 주문 금액 미달 → 거부 + 안내
                   │
테스트 절차  P-결제-01
             로그인 → 상품 담기 → [케이스 1~4 순서로 실행] → 로그아웃

이 구조가 주는 것이 셋이다.

세 번째가 실무에서 가장 유용하다. 조건 목록을 훑으며 "케이스가 하나뿐인 조건" 을 찾으면, 그것이 대개 경계값이나 예외를 안 본 조건이다(모듈 3).

절차를 따로 두는 이유도 분명하다. 로그인·장바구니 담기 같은 공통 준비 단계를 케이스마다 반복해 쓰면, 화면이 바뀔 때 케이스 수십 개를 전부 고쳐야 한다. 절차에 한 번 쓰면 한 곳만 고친다.

테스트 조건은 어디서 오나

조건을 빈 종이에서 만들지 않는다. 출처가 셋이다.

세 출처를 섞는 것이 중요하다. 요구사항만 따라가면 문서에 없는 것을 못 보고(모듈 2의 암묵적 요구), 리스크만 보면 요구 커버리지가 빈다. 모듈 5의 탐색적 테스팅이 세 번째를 담당한다.

그리고 각 조건에 출처를 적어 두면 나중에 요구가 바뀔 때 영향받는 조건을 찾을 수 있다. 추적표가 바로 이 정보다.

2단계 — 테스트 환경 구축

모듈 7(레슨 3)에서 배운 테스트 환경 관리가 바로 이 단계다 — 테스트를 실행하기 전에 필요한 환경(서버, 데이터, 외부 서비스 연결)을 준비하고 유지보수한다.

환경을 별도 단계로 둔 이유

표준이 환경을 독립 단계로 분리한 것은 실무 경험의 산물이다. 환경을 설계나 실행에 섞어 두면 반드시 늦어진다.

설계와 환경은 병행할 수 있다는 것이 핵심이다. 케이스를 쓰는 동안 환경이 만들어지면 실행일에 바로 시작된다. 모듈 7 레슨 8의 "스프린트 앞부분에 QA가 할 일" 에 이 작업이 들어간다.

환경 준비 완료 기준

"환경이 준비됐다" 를 감으로 판단하면 실행 중에 막힌다. 확인 목록을 두면 좋다.

• 접속되나 — URL·계정·권한(레슨 3의 환경 확인 루틴)
• 빌드가 테스트 대상 버전인가
• 데이터가 시딩되어 있나 — 계정 종류·보유물·경계 데이터
• 외부 연동이 샌드박스인가. 발송이 차단되어 있나
• 로그·모니터링을 볼 수 있나(증거 수집용)
• 다른 사람이 같이 쓰고 있나

두 번째와 네 번째가 가장 많이 빠진다. 빌드 버전을 확인하지 않고 돌리면 이미 고쳐진 결함을 다시 등록하고, 발송 차단을 확인하지 않으면 실제 사용자에게 테스트 메일이 간다.

3단계 — 테스트 실행

준비된 케이스를 실제로 실행하고 결과를 기록한다. 실제 결과와 기대 결과를 비교해 통과/실패를 판정한다 — 모듈 1(레슨 4)에서 배운 확인(Confirmation Testing)이 여기 포함된다.

실행 순서를 정하는 기준

케이스가 200건이면 어느 것부터 돌릴지가 결과를 바꾼다. 기준이 셋이다.

세 번째를 먼저 하는 것이 실무의 요령이다. 모듈 7 레슨 1의 스모크 스위트 24건을 30분 안에 돌려 보면, 그날 테스트가 가능한 상태인지 바로 알 수 있다. 하루를 다 쓴 뒤 "로그인이 안 됐다" 를 아는 것보다 낫다.

실행 중 기록할 것

통과·실패만 적으면 나중에 아무것도 재구성할 수 없다.

마지막 줄이 표준과 탐색의 접점이다. 케이스를 돌리다 보면 계획에 없던 것이 눈에 들어오는데, 그것을 버리지 않는다. 모듈 5 레슨 11의 세션 노트가 그 기록 방법이고, 거기서 나온 발견이 다음 회차의 테스트 조건이 된다.

4단계 — 테스트 인시던트 보고

테스트 실행 중 예상과 다른 결과(인시던트)가 발견되면 기록한다. 인시던트가 곧바로 "결함"으로 확정되는 것은 아니다 — 실제 원인이 코드 결함일 수도, 테스트 케이스 자체의 오류일 수도, 환경 문제일 수도 있다. 원인 분석 후 진짜 결함으로 판명되면, 모듈 6(레슨 1~2)에서 배운 결함 생명주기·결함 리포트 프로세스로 넘어간다.

인시던트와 결함의 차이

이 구분이 있는 이유는, 실무에서 테스트 실패의 원인이 항상 코드 결함은 아니기 때문이다 — 모듈 7(레슨 3)에서 배운 환경 문제, 또는 테스트 케이스 자체의 오류(기대 결과를 잘못 적었다거나)일 수도 있다. 표준은 이 판단 과정을 명시적인 단계로 분리해둔 것이다.

인시던트는 세 갈래로 나뉜다

원인 분석의 결과는 거의 항상 셋 중 하나이고, 처리 경로가 다르다.

두 번째와 세 번째를 결함으로 등록하면 두 가지가 망가진다.

• 개발자가 시간을 쓰고 "재현 불가" 로 돌아온다(모듈 6 레슨 1)
• 결함 밀도·탈출률이 거짓이 된다(모듈 6 레슨 5)

특히 두 번째가 조용히 쌓인다. 환경 문제 20건이 결함으로 등록되어 있으면 "이 영역은 결함이 많다" 는 잘못된 결론이 나오고, 그 결론 위에서 다음 테스트 범위가 잘못 정해진다.

그래서 인시던트를 등록하기 전 30초 확인이 값지다 — 빌드 버전, 환경, 계정·데이터 상태, 기대 결과가 맞는지. 모듈 7 레슨 3의 환경 확인 루틴이 여기서 쓰인다.

다만 "모르면 올린다"

반대 방향의 함정도 있다. 원인을 다 밝힌 뒤에만 올리려 하면 올리지 못하는 것이 쌓인다. 표준이 "인시던트" 라는 이름을 둔 이유가 바로 그것이다 — 원인을 모르는 상태로도 기록할 자리를 만든 것이다.

두 번째 줄이 중요하다. 모르는 것을 모른다고 적는 것은 품질 낮은 리포트가 아니라 정직한 리포트다(모듈 6 레슨 2). 숨기는 것이 가장 나쁘다.

네 단계는 한 방향이 아니다

그림은 왼쪽에서 오른쪽으로 흐르지만, 실제로는 되돌아간다.

설계 ──→ 환경 ──→ 실행 ──→ 인시던트
  ▲        ▲         │          │
  │        │         │          │
  │        └─────────┘          │   환경 문제로 판명 → 환경 수정 후 재실행
  │                             │
  └─────────────────────────────┘   케이스 오류로 판명 → 케이스 수정 후 재실행

이 되돌아감이 정상이다. 특히 인시던트 분석 결과가 "테스트 자산 결함" 이면 설계 단계로 돌아가고, "환경 결함" 이면 환경 단계로 돌아간다. 한 번에 직진하는 테스트는 아무것도 발견하지 못한 테스트에 가깝다.

그리고 돌아갈 때마다 무엇을 왜 고쳤는지 남긴다. 케이스를 고친 이력이 없으면, 나중에 "이 케이스가 원래 뭘 보려 했는지" 를 잃는다.

사례 — 실패 50건의 정체

야간 자동화에서 50건이 실패한 아침이었다. 그대로 결함으로 올렸다면 개발팀에 50건이 쌓였을 것이다. 30분을 들여 분류했다.

50건 중 실제 결함은 5건이었다. 그리고 분류 자체가 각각 다른 곳으로 갔다 — 31건은 시딩 스크립트 수정(한 번), 12건은 자동화 유지보수, 5건만 개발팀으로.

여기서 얻은 것이 둘이다. 첫째, 31건이 원인 하나였다. 개별로 보면 31개의 문제지만 원인으로 묶으면 하나이고, 모듈 6 레슨 4에서 본 "차이를 유형별로 묶는다" 와 같은 작업이다.

둘째, 이 분류를 매일 기록하자 패턴이 보였다. 한 달 뒤 집계에서 테스트 자산 결함이 전체의 40% 였고, 원인이 "화면 개편 때 자동화 담당에게 공유가 안 되는 것" 이었다. 그 사실이 개발 쪽 프로세스 변경 (화면 구조 변경 시 QA에 공유)으로 이어졌다.

인시던트를 분류하지 않았다면 그 팀의 결론은 "자동화가 불안정하다" 였을 것이다(모듈 7 레슨 2의 사례와 같은 구조다).

실무에서 왜 필요한가

동적 테스트 프로세스는 QA 엔지니어가 매일 하는 실무 그 자체를 표준화된 언어로 정리한 것이다. 이 단계 구분을 알면, "지금 우리가 어느 단계에 있는지"(케이스를 설계하는 중인지, 실행 중인지, 결과를 판단하는 중인지)를 명확히 인식하고, 각 단계에서 놓치기 쉬운 부분(예: 환경 구축을 테스트 설계와 분리해서 미리 준비하기)을 챙길 수 있다.

분류가 지표를 지킨다

이 레슨에서 실무에 가장 직접적으로 쓰이는 것은 인시던트 삼분법이다. 모듈 6 레슨 5의 지표가 전부 이 분류 위에 서 있다.

세 번째가 가장 값진 전환이다. 막연한 불만이 고칠 수 있는 숫자로 바뀐다.

환경을 앞당기는 것만으로 일정이 바뀐다

두 번째 실용 포인트는 환경을 독립 단계로 보는 것이다. 실행 기간이 2주인데 첫 사흘을 환경 준비에 쓰면 실질 실행 기간은 7일이다. 설계와 병행해 미리 준비하면 그 사흘이 그대로 돌아온다.

그리고 이것은 QA 혼자 할 수 없는 일이라 미리 요청해야 한다. 모듈 7 레슨 8의 "스프린트 앞부분" 에 환경 준비를 넣는 것이 그 방법이다.

채용시장에서의 위치

이 계층은 실무자 면접의 중심이다. 매일 하는 일이라 구체성이 바로 드러난다.

첫 번째가 가장 변별력이 크다. 인시던트와 결함을 구분하는 사람은 지표가 어떻게 망가지는지 아는 사람이고, 그 감각은 운영해 본 경험에서 온다.

두 번째도 좋다. "조건에 케이스가 하나뿐이면" 이라는 점검 방법은 설계를 스스로 검토해 본 사람의 말이다.

공고 표현으로는 "테스트 설계·실행", "테스트 케이스 작성", "결함 분석", "테스트 환경 구성" 이 이 레슨에 걸린다 — 사실상 QA 공고의 기본 요건 전부가 이 계층이다.

실습 과제

과제 1 — 네 단계에 활동 배정하기 (10분)

다음 네 활동이 동적 테스트 프로세스의 어느 단계에 해당하는지 배정한다.

1. "결제 실패 시 에러 메시지가 표시되는지" 확인할 테스트 케이스 작성
2. 테스트용 결제 게이트웨이 목(mock) 서버 준비
3. 작성한 케이스를 실제로 실행하고 통과/실패 기록
4. 실행 중 예상과 다른 화면이 나타나 원인 파악 전 우선 기록

과제 2 — 인시던트 vs 결함 판단하기 (10분)

"자동화 테스트가 실패했다"는 인시던트를 발견했을 때, 그것이 진짜 코드 결함인지 아니면 환경·테스트 케이스 문제인지 판단하기 위해 확인해야 할 것 3가지를 적는다.

과제 3 — 조건·케이스·절차로 쪼개기 (15분)

"회원 가입" 기능에 대해 테스트 조건 3개를 쓰고, 그중 하나에 케이스 4개를 붙이고, 그것을 실행할 절차 1개를 쓴다. 각 조건에 출처(요구·리스크·경험)를 표시한다.

테스트 조건
  C-1  이메일 형식이 올바른지 검증된다            (출처: 요구 REQ-021)
  C-2  비밀번호 정책이 적용된다                   (출처: 요구 REQ-022)
  C-3  가입 도중 이탈·재시도 시 데이터가 남지 않는다 (출처: 경험)
 
C-2 의 케이스
  1  8자 비밀번호 → 가입 성공
  2  7자 비밀번호 → 거부 + 안내 문구
  3  허용 최대 길이 → 가입 성공
  4  공백만 8자 → 거부
 
테스트 절차  P-가입-01
  1 로그아웃 상태로 가입 화면 진입
  2 [케이스 1~4 를 순서대로 실행]
  3 각 실행 후 입력값 초기화

자가 체크리스트

• 동적 테스트 프로세스의 네 단계를 순서대로 설명할 수 있다
• 테스트 조건·테스트 케이스·테스트 절차의 계층 구조를 설명할 수 있다
• 인시던트와 결함의 차이를 설명할 수 있다
• 테스트 실패의 원인이 항상 코드 결함은 아닌 이유를 예시로 설명할 수 있다
• 세 계층으로 나누면 얻는 것 셋(추적성·재사용·공백 발견)을 말할 수 있다
• 조건에 케이스가 하나뿐일 때 무엇을 의심해야 하는지 안다
• 공통 준비 단계를 절차에 두는 이유를 설명할 수 있다
• 테스트 조건의 세 출처를 들고, 섞어야 하는 이유를 말할 수 있다
• 환경을 독립 단계로 둔 이유와, 설계와 병행하는 이점을 설명할 수 있다
• 환경 준비 완료 기준에서 가장 많이 빠지는 둘을 안다
• 실행 순서를 정하는 세 기준과 스모크를 먼저 돌리는 이유를 안다
• 실행 중 기록할 다섯 가지를 말할 수 있다
• 인시던트 삼분법(제품·자산·환경)과 각각의 처리 경로를 설명할 수 있다
• 분류를 안 하면 지표가 어떻게 거짓이 되는지 설명할 수 있다
• 원인을 모를 때도 기록해야 하는 이유를 말할 수 있다
• 네 단계가 되돌아가는 것이 정상인 이유를 설명할 수 있다

흔한 실수

• 테스트 실행 중 발견한 인시던트를 원인 확인 없이 바로 결함으로 단정한다. 환경 문제나 테스트 케이스 오류일 수도 있다.
• 테스트 환경 구축을 테스트 설계와 같은 시점에 급하게 준비한다. 두 활동을 분리해서 미리 준비해야 실행 단계에서 지연이 없다.
• 테스트 조건·케이스·절차를 구분하지 않고 뭉뚱그려 하나의 문서로만 관리한다. 계층이 명확해야 나중에 특정 조건만 골라 재사용하거나 수정하기 쉽다.
• 환경·자산 문제를 결함으로 등록한다. 개발자가 시간을 쓰고 "재현 불가"로 돌아오며, 결함 밀도와 탈출률이 거짓이 된다.
• 반대로 원인을 다 밝힌 뒤에만 올린다. 올리지 못하는 것이 쌓인다. "원인 미확인"을 적어 인시던트로 기록한다.
• 여러 케이스가 동시에 실패했는데 개별로 본다. 30초면 확인되는 공통 원인을 놓치고 31개의 문제를 따로 처리하게 된다.
• 빌드 버전을 확인하지 않고 실행한다. 이미 고쳐진 결함을 다시 등록한다.
• 발송 차단을 확인하지 않는다. 실제 사용자에게 테스트 메일이 간다.
• 공통 준비 단계를 케이스마다 반복해 쓴다. 화면이 바뀌면 케이스 수십 개를 전부 고쳐야 한다.
• 테스트 조건을 요구사항에서만 뽑는다. 문서의 공백이 그대로 테스트의 공백이 된다. 리스크와 경험을 섞는다.
• 스모크 없이 바로 전체 실행에 들어간다. 하루를 쓴 뒤 "로그인이 안 됐다"를 알게 된다.
• 계획 밖에서 본 것을 버린다. 그 발견이 다음 회차의 테스트 조건이 된다. 세션 노트에 남긴다.
• 케이스를 고친 이력을 남기지 않는다. "원래 뭘 보려 했는지"를 잃는다.

참고 자료

• ISO/IEC/IEEE 29119-2 개요 — Dynamic Test Process — 동적 테스트 프로세스의 공식 정의
• ISTQB Glossary — Test Incident — 인시던트와 결함의 공식 구분
• ISO/IEC/IEEE 29119-3 — 인시던트 보고 템플릿 — 인시던트 보고서의 표준 항목

이 커리큘럼 안에서

• 모듈 8 레슨 4 — 관리 계층. 이 레슨의 바깥
• 모듈 8 레슨 6 — Part 3 템플릿. 케이스 명세·실행 기록·인시던트 보고 형식
• 모듈 2 — 요구사항. 테스트 조건의 첫 출처
• 모듈 3 — 설계 기법. 조건에서 케이스를 만드는 방법
• 모듈 4 — 리스크. 조건의 두 번째 출처이자 실행 순서의 근거
• 모듈 5 레슨 11~12 — 세션 노트·재현 불가. 계획 밖 발견의 기록 방법
• 모듈 6 레슨 1~2 — 결함 생명주기·리포트. 인시던트가 결함이 된 뒤
• 모듈 6 레슨 5 — 지표. 삼분법이 지키는 숫자들
• 모듈 7 레슨 1 — 케이스·런·Blocked. 이 계층의 도구 쪽 구현
• 모듈 7 레슨 2~3 — 데이터·환경. 2단계의 실제 내용
• 스테이지 4 — 자동화. 자산 결함이 가장 많이 생기는 영역

한 줄 정리 — 동적 계층의 핵심은 두 가지다. 조건 → 케이스 → 절차로 나누면 추적·재사용이 되고 케이스가 하나뿐인 조건에서 공백이 드러난다. 그리고 실패를 제품·테스트 자산·환경 셋으로 분류해야 지표가 거짓이 되지 않는다 — 다만 원인을 모를 때도 "미확인" 으로 기록한다. 숨기는 것이 가장 나쁘다.