Brain442. 테스트 시나리오 (Test Scenario)
핵심 인사이트 (3줄 요약)
- 본질: 테스트 시나리오(Test Scenario)는 소프트웨어의 특정 기능이나 테스트 가능한 영역을 한 문장으로 표현한 것으로, "무엇을 테스트할 것인가"에 대한 high-levelな 정의이다. 테스트 시나리오는複数の 테스트 케이스의 논리적 그룹으로서, 특정 테스트 목적을为中心로 관련 테스트 케이스들을 묶는 역할을 한다.
- 가치: 테스트 시나리오는 테스트 범위와 목적을 명확히 하여 테스트 기획의 효율성을 높이고, 이해관계자들이 테스트 진행 상황과 범위를 쉽게 파악할 수 있게 하며, 요구사항에서 테스트 가능 항목으로의 추적성을 확보하는 기반이 된다.
- 융합: 테스트 시나리오는 Agile의 사용자 스토리(User Story)와 연결하여 시나리오 기반 인수 테스트(Scenario-Based Acceptance Testing)로 발전하였으며, BDD(Behavior-Driven Development)의 Given-When-Then 형식과 결합하여 비기술적인 이해관계자도 이해할 수 있는 테스트 명세로 활용된다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 테스트 시나리오는 특정 소프트웨어 기능, 모듈, 또는 사용자 여정(Journey)을 테스트하기 위해 작성되는 high-levelなテスト 목표 설명이다. 이는 "사용자가 로그인할 수 있어야 한다", "결제 시스템이 올바른 금액을 계산해야 한다"와 같이 간결하게 표현된다. 테스트 시나리오는通常 하나 이상의 테스트 케이스를 포함하며, 각 시나리오는 특정 테스트 목적을服务한다.
-
필요성: 대규모 시스템에서는 수백甚至 수천 개의 테스트 케이스가 존재할 수 있다. 이러한 테스트 케이스들을 개별적으로 관리하면テスト策划과進捗管理가 매우 복잡해진다. 테스트 시나리오는 이러한 테스트 케이스들을 논리적 그룹으로 구성하여, 테스트 범위의 구조화를 가능하게 한다.
-
💡 비유: 테스트 시나리오는 **'음식점의 메뉴판'**과 같다. 메뉴판에는 "한정", "오늘의 추천", "베스트셀러" 등의 카테고리가 있고, 각 카테고리 아래에 개별 요리가 목록된다. 테스트 시나리오도 마찬가지로 "로그인 기능", "결제 기능" 등의 시나리오(카테고리) 아래에具体的な 테스트 케이스(요리)가 구성된다.
-
등장 배경 및 발전 과정:
- 1990년대: 요구사항 기반 테스트 기획에서 테스트 시나리오 개념 정립
- 2000년대: ISO/IEC 29119 (Software Testing) 표준에서 테스트 시나리오 정의
- 2010년대 이후: BDD, ATDD(Acceptance Test-Driven Development)와의 융합으로 Given-When-Then 기반 시나리오로 발전
-
📢 섹션 요약 비유: 테스트 시나리오는 **'건축 检查清单'**과 같다. 건축 检查清单에는 "구조 안전성", "전기 배선", "급수 시스템" 등의 检查 항목(시나리오)이 있고, 각 항목 아래에 구체적인 检查 내용(테스트 케이스)이 나열된다. 시나리오가 없다면数千 개의 检查 내용을 한눈에 파악하고 관리하는 것이 불가능하듯이, 테스트 시나리오는テスト 케이스의 체계적 관리에 필수적이다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
테스트 시나리오 vs 테스트 케이스 비교
[테스트 시나리오와 테스트 케이스의 관계]
┌─────────────────────────────────────────────────────────────────┐
│ 테스트 시나리오 (Test Scenario) │
│ "사용자가 은행 앱으로 송금할 수 있어야 한다" │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ TS-001: 유효한 금액으로 송금하기 │ │
│ │ → TC-001: 잔액이 충분할 때 정상 송금 │ │
│ │ → TC-002: 송금 후 잔액 정확히 차감 │ │
│ ├─────────────────────────────────────────────────────────┤ │
│ │ TS-002: 잘못된 금액으로 송금 시도하기 │ │
│ │ → TC-003: 음수 금액 입력 시 거부 │ │
│ │ → TC-004: 잔액 초과 금액 입력 시 거부 │ │
│ │ → TC-005: 0원 입력 시 거부 │ │
│ ├─────────────────────────────────────────────────────────┤ │
│ │ TS-003: 수취인 정보 검증하기 │ │
│ │ → TC-006: 존재하지 않는 계좌로 송금 시 거부 │ │
│ │ → TC-007: 자기 자신에게 송금 시 거부 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
[비교 요약]
┌─────────────────┬────────────────────────┬────────────────────────┐
│ 구분 │ 테스트 시나리오 │ 테스트 케이스 │
├─────────────────┼────────────────────────┼────────────────────────┤
│抽象화 수준 │ High-level ( WHAT) │ Low-level ( HOW) │
│ 문장 수 │ 1문장 (간결) │ 여러 단계 (상세) │
│ 포함 관계 │ 여러 TC를 그룹화 │ 개별 실행 단위 │
│ 작성 시점 │ 테스트策划 단계 │ 테스트 설계 단계 │
│ 변경 빈도 │ 상대적으로 안정적 │频繁하게 변경 가능 │
└─────────────────┴────────────────────────┴────────────────────────┘
[다이어그램 해석] 테스트 시나리오는 "무엇을 테스트하는가"에 집중하는 high-levelな抽象化이며, 복수의 테스트 케이스를 논리적으로 그룹화한다. 테스트 케이스는 "어떻게 테스트하는가"에 집중하며, 구체적인 입력값, 절차, 기대 결과를 포함한다.
테스트 시나리오 도출 기법
[테스트 시나리오 도출 방법]
1. 요구사항 분석 기반
- 기능 요구사항에서 동사(CRUD: 생성, 조회, 수정, 삭제) 추출
- 예: "사용자가 계좌를 등록할 수 있다" → "계좌 등록 시나리오"
2. 사용자 여정 (User Journey) 기반
- 핵심 사용자 여정을 시나리오로 변환
- 예: "신규 회원가입 → 물품 검색 → 장바구니 담기 → 결제 → 확인"
3. 시나리오 기반 인수 테스트 (SBAT)
- 사용자 스토리의 인수 기준(Acceptance Criteria)을 시나리오로 변환
- 예: "사용자가 5만원 이상 구매 시 무료 배송" → "무료 배송 조건 테스트"
4. 위험 분석 기반
- 高리스크 영역을 식별하여 시나리오로 구성
- 예: 결제 로직, 보안 관련 기능 중심 시나리오
5. 동등 분할/경계값 분석 기반
- equivalence class당 최소 하나의 시나리오 구성
- 예: "유효 금액 범위", "경계값", "무효 금액" 시나리오
[다이어그램 해설] 테스트 시나리오는 다양한 방법론을 통해 도출될 수 있다. 요구사항 분석, 사용자 여정, 인수 테스트, 위험 분석, 동등 분할 등의 기법을 조합하여 포괄적인 테스트 시나리오를 구성하는 것이 바람직하다.
Ⅲ. 구현 및 실무 응용 (Implementation & Practice)
테스트 시나리오 작성 예시: 전자상거래 플랫폼
[전자상거래 플랫폼 테스트 시나리오]
┌─────────────────────────────────────────────────────────────────┐
│ 테스트 시나리오 목록 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [TS-001] 회원 관리 기능 │
│ - TS-001-01: 신규 회원 가입 │
│ - TS-001-02: 회원 정보 수정 │
│ - TS-001-03: 회원 탈퇴 │
│ - TS-001-04: 비밀번호 재설정 │
│ │
│ [TS-002] 상품 검색 및 浏览 기능 │
│ - TS-002-01: 키워드 검색 │
│ - TS-002-02: 카테고리별 탐색 │
│ - TS-002-03: 필터링 및 정렬 │
│ - TS-002-04: 상품 상세 정보 조회 │
│ │
│ [TS-003] 장바구니 기능 │
│ - TS-003-01: 상품 장바구니 담기 │
│ - TS-003-02: 장바구니 수량 변경 │
│ - TS-003-03: 장바구니 상품 삭제 │
│ - TS-003-04: 장바구니 금액 계산 정확성 │
│ │
│ [TS-004] 주문 및 결제 기능 │
│ - TS-004-01: 정상 주문 완료 │
│ - TS-004-02: 쿠폰 적용 주문 │
│ - TS-004-03: 결제 수단 변경 │
│ - TS-004-04: 결제 실패 처리 │
│ │
│ [TS-005] 배송 관리 기능 │
│ - TS-005-01: 배송지 변경 │
│ - TS-005-02: 배송 추적 정보 확인 │
│ - TS-005-03: 배송 완료 처리 │
│ │
└─────────────────────────────────────────────────────────────────┘
[시나리오 상세 예시: TS-001-01]
┌─────────────────────────────────────────────────────────────────┐
│ 시나리오 ID: TS-001-01 │
│ 시나리오명: 신규 회원 가입 │
│ 관련 요구사항: FR-001 (회원 가입 기능) │
│ │
│ 테스트 케이스: │
│ TC-001: 모든 필수 정보 입력 시 정상 가입 │
│ TC-002: 이메일 중복 시 가입 거부 │
│ TC-003: 필수 정보 누락 시 가입 거부 │
│ TC-004: 잘못된 이메일 형식 시 가입 거부 │
│ TC-005: 비밀번호 정책 불일치 시 가입 거부 │
│ │
│ 우선순위: High │
│ 예상 노력: 2시간 │
│ │
└─────────────────────────────────────────────────────────────────┘
테스트 시나리오 관리 도구와의 연계
[테스트 시나리오 관리 워크플로우]
[요구사항]
│
▼
[시나리오 도출] ───────────────────────┐
│ │
▼ │
[시나리오 승인] │
│ │
▼ ▼
[TC 설계] ◄────────────────────────────┘
│
▼
[TC 실행]
│
▼
[결과 기록]
│
▼
[시나리오 단위進捗管理]
※ 주요 관리 항목:
- 시나리오별 TC 개수, 실행률, 합격률
- 블로킹(Blocked) TC 식별
- 커버리지 분석 (요구사항 ↔ 시나리오 ↔ TC)
Ⅳ. 품질 관리 및 테스트 (Quality & Testing)
테스트 시나리오 품질 기준
[좋은 테스트 시나리오의 조건]
1. 완전성 (Completeness)
- 해당 기능의 모든 주요 경로를 포함하는가?
- 정상 케이스 + 예외/에러 케이스가 적절히 표현되었는가?
2. 독립성 (Independence)
- 다른 시나리오와의 중복이 최소화되었는가?
- 시나리오 간 순서 의존성이 없는가?
3. 추적 가능성 (Traceability)
- 요구사항 ID와 연결되어 있는가?
- 테스트 결과가 요구사항까지 추적 가능한가?
4. 이해 가능성 (Understandability)
- 비기술적인 Stakeholder도 이해할 수 있는가?
- 명확하고 간결한 표현으로 되어 있는가?
5. 실행 가능성 (Feasibility)
- 실제로 테스트 가능한 시나리오인가?
- 기술적/환경적 제약으로 인해 실행 불가능한 것이 없는가?
- 📢 섹션 요약 비유: 테스트 시나리오는 **'소설의 챕터'**와 같다. 소설의 각 챕터는 특정 사건이나 갈등을 다루며, 그 안에 여러 장면(테스트 케이스)이 구성된다. 챕터 제목만 봐도 소설의 큰 줄거리를 알 수 있듯이, 시나리오 이름만으로도 테스트 범위를 파악할 수 있어야 한다. 또한 챕터가 너무 길거나 알 수 없으면 독자(테스터)가 혼란을 겪듯이, 시나리오도 적절한粒度로 구분되어야 한다.
Ⅴ. 최신 트렌드 및 결론 (Trends & Conclusion)
최신 동향
- BDD 시나리오와의 융합: Cucumber, SpecFlow 등의 BDD 도구에서 사용되는 Gherkin 언어의 Given-When-Then 시나리오形式은 테스트 시나리오의一种이다. 이는 비즈니스 언어로 테스트를 표현할 수 있어, 개발자 외의 Stakeholder도テスト策划에 참여할 수 있게 한다.
- AI 기반 시나리오 자동 생성: 요구사항 문서(PRD, 用户故事)를 AI가 분석하여 자동으로 테스트 시나리오를 제안하는 도구가 등장하고 있다. 이는手動 시나리오 도출의工作量을 줄이고, 일관성을 확보하는 데 기여한다.
- 테스트 시나리오의 디지털 트윈: 소프트웨어의 동작을 모델링한 디지털 트윈에서 자동으로 테스트 시나리오를 생성하고, 실제 환경에서의 테스트 결과와 연계하는研究方向が進行中이다.
한계점 및 보완
- 시나리오와 TC의 불일치: 시나리오가 변경되었는데 연결된 TC가 업데이트되지 않으면 추적성이 깨진다. 이를 해결하기 위해 시나리오-TC 매핑의定期적 감사이 필요하다.
- 과도한 시나리오 분할 또는 통합:粒度가 너무 작거나 크면 관리와進捗 파악이 어려워진다. 권장되는粒度는 한 시나리오당 3~7개의 TC를 포함하는 수준이다.
- 변경 관리: Agile 환경에서 시나리오가频繁하게 변경될 수 있으므로, 변경 이력과 히스토리를 관리하는체계화된 프로세스가 필요하다.
테스트 시나리오는テスト 케이스와 요구사항 사이에서重要な桥梁 역할을 하며, 테스트策划과進捗管理의 효율성을 높이는 핵심 도구이다. 잘 설계된 테스트 시나리오는 테스트 범위를 명확히 하고, 이해관계자との 의사소통을 원활하게 하며, 요구사항에서 실행까지의 추적성을確保한다. 앞으로 AI/ML 기반 자동화와 BDD 등의 방법론과의 융합을 통해, 테스트 시나리오의 작성과 관리 방식도 더욱 지능화되고 효율화될 것으로 전망된다.
- 📢 섹션 요약 비유: 테스트 시나리오는 **'영화의 시나리오'**와 같다. 영화 시나리오에는 "第1장: 아파트에서 시작", "第2장: 회사로 향하는 지하철" 등의 큰 줄거리(시나리오)가 있고, 각 장 안에 구체적인 분장, 연기 지시(테스트 케이스)가 구성된다. 영화ファンが場面の流れを理解できるように, 테스트 시나리오도ステークホルダーがテストの範囲と流れを理解할 수 있게 하는重要な 문서이다.
참고
- 모든 약어는 반드시 전체 명칭과 함께 표기:
API (Application Programming Interface) - 일어/중국어 절대 사용 금지 (한국어만 사용)
- 각 섹션 끝에 📢 요약 비유 반드시 추가
- ASCII 다이어그램의 세로선 │와 가로선 ─ 정렬 완벽하게
- 한 파일당 최소 800자 이상의 실질 내용