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

개념

가장 실무에 가까운 계층

레슨 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) — 여러 테스트 케이스를 어떤 순서로 실행할지 정리한 실행 스크립트

2단계 — 테스트 환경 구축

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

3단계 — 테스트 실행

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

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

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

인시던트와 결함의 차이

용어	의미
인시던트(Incident)	테스트 실행 중 발견된, 원인이 아직 불명확한 예상 밖의 사건
결함(Defect)	원인 분석 결과 실제 코드/설계 문제로 확인된 것

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

실무에서 왜 필요한가

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

실습 과제

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

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

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

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

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

자가 체크리스트

동적 테스트 프로세스의 네 단계를 순서대로 설명할 수 있다
테스트 조건·테스트 케이스·테스트 절차의 계층 구조를 설명할 수 있다
인시던트와 결함의 차이를 설명할 수 있다
테스트 실패의 원인이 항상 코드 결함은 아닌 이유를 예시로 설명할 수 있다

흔한 실수

테스트 실행 중 발견한 인시던트를 원인 확인 없이 바로 결함으로 단정한다. 환경 문제나 테스트 케이스 오류일 수도 있다.
테스트 환경 구축을 테스트 설계와 같은 시점에 급하게 준비한다. 두 활동을 분리해서 미리 준비해야 실행 단계에서 지연이 없다.
테스트 조건·케이스·절차를 구분하지 않고 뭉뚱그려 하나의 문서로만 관리한다. 계층이 명확해야 나중에 특정 조건만 골라 재사용하거나 수정하기 쉽다.

참고 자료

ISO/IEC/IEEE 29119-2 개요 — Dynamic Test Process — 동적 테스트 프로세스의 공식 정의
ISTQB Glossary — Test Incident — 인시던트와 결함의 공식 구분