테스트 설계 명세로 범위와 커버리지를 관리하는 방법

테스트 케이스보다 앞선 설계 기준

테스트 설계 명세(Test Design Specification, TDS)는 상위 테스트 계획(Test Plan)을 실행 가능한 설계 수준으로 풀어낸 문서다. 무엇을 검증할지, 어느 범위까지 확인할지, 어떤 기준으로 테스트를 선택할지를 기록한다.

문서에는 테스트 조건(Test Conditions), 커버리지 기준(Coverage Criteria), 테스트 선정 규칙(Selection Rules), 우선순위와 함께 데이터·환경·도구 요구사항이 포함된다. ISO/IEC/IEEE 29119 계열 표준과 조직의 품질 정책은 이 문서를 구성할 때 기준점이 된다.

테스트 케이스 명세(Test Case Specification)가 TDS를 바탕으로 실제 검증 절차를 작성하는 단계라면, TDS는 “무엇을, 어느 정도까지, 어떤 기준으로” 검증할지를 정한다. 요구사항과 테스트 사이의 추적성, 설계 규칙의 일관성, 중복을 줄이는 효율성은 이 기준선(Baseline) 위에서 관리된다.

요구사항에서 명세와 추적성으로 이어지는 흐름

TDS는 요구사항, 리스크, 아키텍처, 규제·정책을 검토해 테스트 조건을 찾는 데서 시작한다. 커버리지 모델과 선정 규칙을 정한 뒤 데이터·환경·도구 요구사항을 구체화하며, 결과물은 TDS와 추적성 매트릭스(RTM), 데이터 세트 요구사항으로 남는다.

⤢✕

요구사항이 누락되었거나 모호하고 상충할 때는 체크리스트로 발견해 쿼리 또는 변경요청으로 관리한다. 커버리지 조건이 맞지 않으면 리스크를 다시 평가하고 스코프를 조정하며, 리뷰와 승인에서 반려된 명세도 설계 단계로 되돌아간다.

테스트 범위를 결정하는 설계 항목

테스트 조건은 요구사항, 리스크, 유스케이스, 상태전이 등에서 식별한다. 요구사항 100%, 경계값, 의사결정 70% 이상처럼 커버리지 기준을 수치로 선언하면 측정 가능한 상태를 유지할 수 있다.

선정 규칙과 우선순위는 리스크 기반 테스트(RBT), 변화 영향 범위, 사용 빈도, 장애 비용을 근거로 잡는다. 스모크, 회귀, 탐색, 성능 등 테스트 유형별로 무엇을 포함하고 제외하는지도 명시해야 한다.

데이터 설계에는 데이터 클래스, 합성·마스킹 전략, 민감정보 처리, 데이터 볼륨과 분포가 들어간다. 환경 측면에서는 버전, 토폴로지, 외부 연동 모의 구성을 적고, 테스트 관리 도구(TMS), Defect Tracker, CI와의 연결성도 정의한다.

추적성은 요구사항↔조건↔케이스↔결함을 양방향으로 연결하는 방식으로 관리한다. RTM을 유지하고 리뷰 기준, 승인 권한, 베이스라인, 영향도 분석 절차까지 정해두면 변경 시 재검토의 근거가 남는다.

시스템 성격에 따라 달라지는 명세의 초점

금융 규제 시스템에서는 규제 조항에서 통제 요건, 테스트 조건으로 이어지는 맵핑이 감사 대응의 기반이 된다. 데이터 마스킹과 샘플링 정책을 TDS에 포함하면 개인정보 리스크도 함께 다룰 수 있다.

마이크로서비스 통합에서는 계약 기반 테스트(Contract)와 카나리·블루그린 배포의 커버리지 기준을 정하고, 변경 영향도에 따른 회귀 테스트 선정 자동화와 연결한다. 성능과 용량 계획에서는 워크로드 모델, SLA/SLI 기준, 부하 패턴, 데이터 볼륨을 테스트 조건으로 선언하며 스케일 아웃과 캐시 정책 같은 환경 독립 변수 및 측정 지표를 명세한다.

레거시 현대화에서는 기능 동등성 기준과 중요 경계값·에지케이스를 재현할 데이터 세트를 정의한다. 점진적 치환 단계마다 회귀 커버리지 로드맵도 필요하다. 안전·임베디드 도메인에서는 위험도(ASIL/SIL)를 기준으로 커버리지 임계값을 설정하고, 증거 산출물 형식과 표준·감사 문서 템플릿 준수를 관리한다.

설계 명세를 운영하는 방식의 차이

접근 방식	성능(대규모 항목 처리)	확장성(프로젝트/팀)	일관성(표준/재사용)	안정성(변경/감사)	운영 편의(자동화/통합)
스프레드시트 중심	중간	낮음	낮음	낮음	중간
테스트 관리 도구(TMS)	높음	중간~높음	중간~높음	중간~높음	높음
모델 기반 테스트(MBT)	높음	높음	높음	중간	중간~높음

조직의 표준과 규제 요구, 도구 생태계에 따라 이 비교 결과는 달라질 수 있다.

YAML로 작성한 TDS 템플릿

Git 버전관리, TMS(Jira/Xray 등) 연동, 요구사항 ID 부여를 전제로 한 예시다.

version: "1.0"
id: "TDS-CHKOUT-API-v1"
scope:
  system_under_test: "Checkout API"
  objectives: ["결제 성공/실패 흐름 검증", "세금/할인 규칙 검증"]
  out_of_scope: ["제3자 정산 배치"]
references:
  - "SRS-CHK-001"
  - "ISO/IEC/IEEE 29119-3"
inputs:
  requirements: ["REQ-CHK-012", "REQ-CHK-020"]
  risks: ["RISK-PAY-001: 고액 결제 실패 비용"]
  architecture: ["ADR-API-001", "OpenAPI v3 spec"]
coverage_criteria:
  - "Requirements: 100%"
  - "Boundary values: amount, quantity"
  - "Decision coverage: >=70% (rule engine)"
selection_rules:
  include: ["리스크 High 이상", "변경 영향도 High", "사용 빈도 Top 20%"]
  exclude: ["Deprecated API", "운영 Feature toggle Off"]
prioritization:
  P0: ["안정성/결제 차단 결함 유발 조건"]
  P1: ["핵심 경로/고빈도"]
  P2: ["저빈도/대체 경로"]
test_conditions:
  - id: "TCND-001"
    requirement: "REQ-CHK-012"
    description: "정상 결제 승인(국내 카드, 유효 한도)"
    coverage: ["경로: Happy path", "경계: 금액=최소/최대"]
    rationale: "매출 임팩트 최대"
  - id: "TCND-002"
    requirement: "REQ-CHK-020"
    description: "할인·세금 동시 적용 규칙 충돌"
    coverage: ["의사결정: 쿠폰/프로모션/부가세", "경계: 0원/음수 방지"]
    rationale: "규칙 엔진 복잡도 High"
data_design:
  strategy: ["마스킹: 프로덕션 샘플", "합성: 경계/에지케이스"]
  datasets:
    - name: "base_positive"
      fields: {"amount": [1000, 999999], "card": "valid"}
environment:
  topology: "API GW → Checkout → PSP Stub"
  versions: {"app": "1.4.2", "db": "13.7"}
tools:
  tms: "Jira/Xray"
  ci: "GitHub Actions"
  perf: "k6"
traceability:
  matrix: {"REQ-CHK-012": ["TCND-001"], "REQ-CHK-020": ["TCND-002"]}
review_checklist:
  - "커버리지 기준 수치화 여부"
  - "데이터 민감정보 처리 방침 반영 여부"
  - "우선순위 기준 일관성"
change_control:
  baseline: "v1.0"
  impact_analysis: "요구/리스크 변경 시 조건·케이스 갱신"

경량화와 통제 수준 사이의 선택

ISO/IEC/IEEE 29119를 참조하되 조직 SOP와 용어 및 포맷의 정합성을 맞춘다. 표준 개정 여부는 최신 정보 확인이 필요하며, 규제 도메인에서는 증거 산출물과 서명·승인 절차를 강화한다.

MVP나 프로토타입 단계에는 경량 템플릿을 쓰고, 안정화 단계에는 더 엄격한 기준을 적용할 수 있다. 문서가 과도해지면 유지보수 비용이 늘어나므로, 측정 가능한 커버리지와 추적성에 집중할 필요가 있다.

데이터는 마스킹과 합성 중에서 선택하며 재현성과 프라이버시 사이에 트레이드오프가 존재한다. 데이터 볼륨과 분포가 성능 결과에 주는 영향도 사전에 검증해야 한다.

리스크 기반 우선순위 적용을 가정하면 결함 유출률은 20~~40% 감소할 수 있다. 조건과 커버리지 기준을 일원화하면 중복 테스트 케이스는 15~~30%削減되고, 템플릿과 도구 연계는 테스트 설계 리드타임을 10~25% 단축할 수 있다. 감사 대응성과 설명 가능성이 높아지고, 팀 간 설계 품질 편차와 온보딩 시간이 줄며, 변경 영향 범위를 더 빠르게 파악해 재작업을 줄이는 기반이 된다.