요구사항 추적 매트릭스(RTM): 구조와 QA에서의 활용
요구사항 추적 매트릭스(RTM)는 소프트웨어 라이프사이클의 모든 단계에서 요구사항, 테스트 케이스, 결함 간의 관계를 문서화하는 표입니다. 이는 무엇이 테스트되었는지, 무엇이 아직 커버되지 않았는지, 그리고 특정 테스트가 수행되는 이유에 대한 핵심 질문에 답을 제공합니다.
RTM 없이는 테스팅은 투명성을 잃습니다. RTM을 활용하면 테스팅은 명확한 커버리지 지표를 가진 측정 가능한 프로세스가 됩니다.
매트릭스 사용 목표
RTM은 다음과 같은 작업을 해결합니다:
- 테스트에 의한 요구사항 커버리지 완전성 평가.
- 테스트 문서의 공백 식별.
- 요구사항 변경이 기존 테스트에 미치는 영향 분석.
- 요구사항에서 결함까지의 경로 추적.
- 정량적 지표를 포함한 이해관계자 보고서 생성.
이러한 기능들은 광범위한 요구사항을 가진 중대형 프로젝트에서 RTM을 필수적으로 만듭니다.
RTM에서의 추적 유형
관계 구축에는 다양한 접근법이 존재합니다:
| 유형 | 연결 방향 | 적용 분야 |
|------|-------------------|-------------|
| 순방향 | 요구사항 → 테스트 케이스 | 요구사항에 대한 테스트 존재 확인 |
| 역방향 | 테스트 케이스 → 요구사항 | 테스트 필요성 정당화 |
| 양방향 | 요구사항 ⇄ 테스트 케이스 | 양방향 완전 제어 |
| 수직 | 요구사항 → 설계 → 코드 → 테스트 | 단계 간 종단 간 추적성 |
| 수평 | 테스트 → 버그 → 수정 → 재테스트 | 테스팅 내부 추적성 |
유형 선택은 프로젝트 복잡성과 개발 단계에 따라 달라집니다.
RTM 테이블의 열 구조
표준 매트릭스는 다음 필드를 포함합니다:
- 요구사항 ID — 고유 식별자 (REQ-AUTH-01).
- 요구사항 설명 — 간략한 설명 (이메일 인증).
- 테스트 케이스 ID — 관련 테스트 케이스 목록 (TC-LOGIN-01, TC-LOGIN-02).
- 테스트 상태 — 실행 상태 (통과/실패/차단/미실행).
- 결함 ID — 결함 식별자 (BUG-101).
- 결함 상태 — 버그 상태 (열림/수정됨/닫힘).
- 커버리지 상태 — 커버리지 상태 (커버됨/커버되지 않음/부분적).
- 커버리지 % — 커버리지 백분율 (100%/0%/50%).
RTM 테이블 예시
기본 테이블 (요구사항 및 테스트 케이스)
| REQ ID | 요구사항 | 우선순위 | 테스트 케이스 ID | 테스트 상태 | 결함 ID | % 커버리지 |
|--------|-------------|----------|--------------|-------------|-----------|------------|
| REQ-01 | 인증 | 높음 | TC-LOGIN-01, TC-LOGIN-02, TC-LOGIN-03 | 통과, 통과, 실패 | BUG-101 | 100% |
| REQ-02 | 비밀번호 복구 | 중간 | TC-REC-01, TC-REC-02 | 통과, 미실행 | — | 50% |
| REQ-04 | 가격 필터링 | 낮음 | — | — | — | 0% |
개발 링크가 포함된 확장 테이블
| REQ ID | 요구사항 | 테스트 케이스 ID | 결과 | 결함 ID | 개발 작업 | 컴포넌트 |
|--------|-------------|--------------|--------|-----------|----------|-----------|
| REQ-01 | 로그인 | TC-AUTH-01 | ✅ 통과 | — | TASK-101 | 인증 모듈 |
| REQ-01 | 로그인 | TC-AUTH-03 | ❌ 실패 | BUG-001 | TASK-101 | 인증 모듈 |
이러한 테이블들은 문제 영역을 빠르게 파악할 수 있게 합니다.
텍스트 기반 추적성 스키마
클래식 순방향 링크
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 요구사항 │ │ 테스트 케이스│ │ 결함 │
│ REQ-01 ──────┼─────▶│ TC-01 ───────┼─────▶│ BUG-101 │
└──────────────┘ └──────────────┘ └──────────────┘종단 간 수직 추적성
┌─────────────────────┐
│ 비즈니스 요구사항 │
└──────────┬──────────┘
▼
┌─────────────────────┐ ┌─────────────┐
│ 기능적 │───▶│ 테스트 │
│ 요구사항 │ │ 케이스 │
└──────────┬──────────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────┐ ┌─────────────────────┐
│기술적 │ │ 테스트 실행 │
│작업 │ └──────────┬──────────┘
└────┬────┘ │
│ ▼
└────────────────────┬───────┘
│
┌─────────────────────┐
│ 결함 │
└─────────────────────┘커버리지 통계 분석
일반적인 RTM 보고서는 다음을 포함합니다:
| 지표 | 값 | 공식 |
|--------|-------|---------|
| 총 요구사항 | 50 | — |
| 테스트 포함 | 45 | — |
| 테스트 미포함 | 5 | — |
| % 커버리지 | 90% | (45/50)×100% |
| 요구사항당 테스트 (평균) | 3.6 | 180/50 |
일반적인 오류: 구식 매트릭스, 형식적 링크, 결함 링크 부재, 중복 테스트.
QA 엔지니어를 위한 체크리스트
- 각 요구사항은 최소 하나의 테스트 케이스를 가집니다.
- 링크 없는 "고아" 테스트 케이스가 없습니다.
- 관련 테스트는 요구사항 변경 시 업데이트됩니다.
- 각 결함은 요구사항에 연결됩니다.
- 매트릭스는 각 스프린트/릴리스 후 업데이트됩니다.
- RTM을 통한 실패 원인 분석이 가능합니다.
RTM 자동화 도구
| 도구 | 유형 | 기능 |
|------|------|----------|
| Jira + Xray/Zephyr | 플러그인 | 애자일 추적성 |
| TestRail | 테스트 관리 | 네이티브 RTM |
| Qase | 테스트 관리 | 간단한 링크 |
| Excel/Google Sheets | 수동 | 소규모 프로젝트용 |
| Polarion/Azure DevOps | ALM | 엔터프라이즈 수준 |
RTM을 피해야 할 때
매트릭스는 다음에 적합하지 않습니다:
- 20개 미만 요구사항 프로젝트.
- 3명 미만 팀.
- 짧은 스프린트 (1-2주).
- 빈번한 변경이 있는 애드혹 테스팅 또는 MVP.
단점: 높은 업데이트 노력, 형식주의 위험, 스타트업에 대한 오버헤드.
규칙: RTM은 20개 이상 요구사항과 3명 이상 팀에서 가치를 발휘합니다.
핵심 요약
- RTM은 대형 프로젝트에서 테스트에 의한 90% 이상 요구사항 커버리지를 보장합니다.
- 양방향 추적성은 회귀 테스트 중 위험을 최소화합니다.
- 매트릭스 관련성은 가치의 핵심입니다. 모든 변경 후 업데이트하세요.
- 엔터프라이즈 수준 자동화에는 ALM 도구를 사용하세요.
- 지표 분석: 커버리지 공백과 요구사항당 테스트 케이스.
— Editorial Team
아직 댓글이 없습니다.