테스트 관련 강좌

[실무 가이드] 금융부터 자율주행까지, 도메인별 완벽한 소프트웨어 테스트 시나리오 및 케이스 작성법

프리스케이터 2025. 12. 11. 06:20

소프트웨어 품질 보증(QA)의 핵심은 '무엇을(Scenario)' '어떻게(Case)' 테스트할지 정의하는 것입니다.

 

하지만 웹 서비스와 자동차에 들어가는 임베디드 소프트웨어의 테스트 방식이 같을 수는 없습니다.

 

이번 포스팅에서는 Web/App, IoT/AI, 금융, 자동차, 공공 등 다양한 산업 도메인별 특성을 반영한 테스트 시나리오(TS)와 테스트 케이스(TC) 작성 전략을 정리해 드립니다.

 

 

 

 

 

1. 기본 개념 잡기

  • 테스트 시나리오 (Test Scenario): "무엇을 검증할 것인가?"에 대한 기능적 흐름입니다. (예: 로그인 기능 확인)

  • 테스트 케이스 (Test Case): 시나리오를 검증하기 위한 구체적인 단계, 입력값, 예상 결과입니다. (예: 아이디 칸에 특수문자 입력 시 오류 메시지 출력 확인)

 

테스트케이스 엑셀파일

 

 

2. 도메인별 작성 전략

사용자 관점이나 명세서 기반의 블랙박스 기능 테스트(Black-box Functional Testing)에 집중하여, 각 도메인별로 더 깊이 있고 구체적인 시나리오(TS)와 케이스(TC) 작성 전략을 정리해 드립니다.

 

블랙박스 테스트는 내부 코드를 보지 않고 "입력값(Input)에 대해 올바른 출력값(Output)이 나오는가?"를 확인하는 것이 핵심입니다.

2.1. Web/App, 전자상거래 (E-Commerce)

핵심 전략: 복잡한 비즈니스 로직(할인, 환불, 상태 변경)과 데이터의 정합성을 확인해야 합니다.

 

 UI상에서 보이는 데이터가 DB의 실제 상태와 일치하는지 검증합니다.

  • 주요 기능 검증 포인트:
    • 장바구니/주문: 옵션 변경, 수량 제한, 품절 상품 처리.
    • 프로모션: 쿠폰 적용 조건(최소 금액, 카테고리 제한), 중복 할인 불가 로직.
    • 주문 상태: 입금 대기 결제 완료 배송 중 배송 완료 구매 확정/반품 흐름.
  • 상세 예시
    • Scenario: 쿠폰 적용 후 주문 취소 시 복원 로직 검증
    • Test Case:
      1. 전제 조건: 30,000원 이상 구매 시 10% 할인 쿠폰 보유, 잔액 50,000원.
      2. 단계 1: 35,000원짜리 상품을 장바구니에 담고 10% 쿠폰을 적용한다.
        • 예상 결과: 결제 예정 금액이 31,500원으로 표기되어야 함.
      3. 단계 2: 결제를 완료한 후, '마이페이지 > 주문 내역'에서 상태가 '결제 완료'인지 확인한다.
      4. 단계 3: 즉시 '주문 취소'를 요청한다.
        • 예상 결과: 주문 상태가 '취소 완료'로 변경되고, 사용했던 쿠폰이 '사용 가능' 상태로 즉시 복구되어야 함. 환불 금액은 정확히 31,500원이어야 함.

 

좀더 자세히 알아볼까요?

 

 

쿠팡(Coupang) 웹사이트의 핵심 비즈니스 로직인 검색, 장바구니/주문, 결제, 멤버십(와우), 마이페이지 영역을 중심으로, 실무에서 즉시 활용 가능한 수준의 블랙박스 테스트 시나리오(TS)와 테스트 케이스(TC)

2.1 테스트 개요

  • 대상: 쿠팡 PC/Mobile Web (https://www.coupang.com/)
  • 테스트 유형: 블랙박스 기능 테스트 (Functional Testing)
  • 작성 관점: 사용자 경험 흐름(User Flow) 및 비즈니스 로직(Business Logic) 검증
  • 주요 검증 영역:
    1. 상품 검색 및 필터링 (로켓배송 구분)
    2. 장바구니 및 주문서 작성 (주소지에 따른 배송 가능 여부)
    3. 결제 및 쿠폰 로직 (가격 정합성)
    4. 멤버십 혜택 적용 (배송비 무료 로직)

2.1.1. 검색 및 상품 리스트 (Search & PLP)

검증 목표: 검색어에 따른 정확한 결과 노출과 쿠팡의 핵심인 '로켓배송' 필터 동작 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
S01-01 일반 키워드 검색 및 결과 정렬 비로그인 상태 1. 메인 검색창에 키워드 입력
2. 검색 버튼 클릭
3. 정렬 조건을 '낮은가격순'으로 변경		 키워드: "생수 2L" 1. 관련 상품 리스트가 출력되어야 함.
2. 광고 상품을 제외한 리스트가 가격 오름차순으로 정렬되어야 함.
S01-02 로켓배송 필터 적용 검증 로그인 상태 (일반 회원) 1. 키워드 검색 후 좌측/상단 '로켓배송' 필터 체크
2. 리스트 내 상품 뱃지 확인		 키워드: "물티슈" 1. 검색 결과가 새로고침 됨.
2. 결과 리스트에 '로켓배송' 뱃지가 붙은 상품만 노출되어야 함.
S01-03 검색 결과 없음(No Data) 처리 - 1. 무의미한 특수문자나 오타 입력
2. 검색 버튼 클릭		 키워드: "!@#$쿠팡없음" 1. "검색 결과가 없습니다" 안내 문구 노출.
2. 추천 상품이나 인기 검색어가 대체 노출되어야 함(빈 화면 불가).
S01-04 품절 상품 제외 필터링 - 1. 검색 결과 필터에서 '품절상품 제외' 체크 - 1. 리스트에서 '일시품절' 상태인 상품이 모두 사라져야 함.

2.1.2. 상품 상세 및 장바구니 (PDP & Cart)

검증 목표: 옵션 선택에 따른 재고 체크와 장바구니 담기 시 가격 합산 로직 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
S02-01 필수 옵션 미선택 시 장바구니 진입 차단 옵션이 있는 상품 페이지 진입 1. 옵션(사이즈/색상)을 선택하지 않음
2. '장바구니 담기' 버튼 클릭		 - 1. "상품 옵션을 선택해주세요" 알림(Toast/Alert) 노출.
2. 장바구니에 담기지 않아야 함.
S02-02 최대 구매 수량 초과 입력 (경계값 테스트) 1인당 10개 구매 제한 상품 1. 수량을 11개로 입력
2. '바로구매' 버튼 클릭		 수량: 11 1. "최대 구매 수량은 10개입니다" 메시지 노출 및 수량이 10개로 자동 조정되거나 진행 차단.
S02-03 로켓프레시 배송 불가 지역 체크 로그인 (배송지가 제주도인 계정) 1. '로켓프레시(신선식품)' 상품 상세 진입
2. 배송지 선택을 '제주도' 주소로 설정		 상품: 우유, 채소 등 1. "배송 불가 지역입니다" 문구가 버튼 근처에 노출.
2. 구매하기/장바구니 담기 버튼이 비활성화(Dimmed) 되어야 함.
S02-04 장바구니 가격 합산 검증 장바구니에 A상품(1만원), B상품(2만원) 있음 1. A상품의 체크박스 해제
2. 전체 결제 예정 금액 확인		 - 1. 총 상품 금액이 3만원 -> 2만원으로 즉시 변경되어야 함.
2. 배송비 조건(무료배송 기준)이 재계산되어야 함.

2.1.3. 주문서 및 결제 (Order & Payment)

검증 목표: 배송비 정책(와우 vs 일반) 적용과 결제 금액의 무결성 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
S03-01 일반 회원 배송비 부과 로직 (19,800원 기준) 일반 회원 (와우 미가입) 1. 로켓배송 상품 10,000원어치 장바구니 담기
2. 주문서 진입 후 '총 결제 금액' 확인		 상품가: 10,000원 1. 배송비(예: 3,000원)가 부과되어 총 13,000원이어야 함.
2. "9,800원 더 담으면 무료배송" 유도 문구 노출 확인.
S03-02 와우 멤버십 무료 배송 로직 와우 회원 로그인 1. 로켓배송 상품 5,000원어치 담기
2. 주문서 진입		 상품가: 5,000원 1. 배송비가 '0원(무료)'으로 표기되어야 함.
2. 총 결제 금액은 5,000원이어야 함.
S03-03 쿠팡캐시 전액 사용 결제 쿠팡캐시 50,000원 보유 1. 30,000원 상품 주문서 진입
2. '캐시 모두 사용' 버튼 클릭
3. 최종 결제 수단 확인		 - 1. 결제해야 할 금액이 '0원'이 됨.
2. PG사(카드사) 호출 없이 내부 로직으로 즉시 '결제 완료' 처리되어야 함.
S03-04 결제 수단 변경 및 품절 방어 재고가 1개 남은 상품 1. 주문서 진입 후 결제 수단 선택 중
2. (다른 브라우저에서 동일 상품 결제 완료 시킴)
3. '결제하기' 버튼 클릭		 - 1. 결제가 진행되지 않고 "선택하신 상품이 품절되었습니다" 알림 노출.
2. 장바구니 또는 이전 화면으로 리다이렉트.
S03-05 현금영수증 신청 정보 유지 무통장 입금(가상계좌) 선택 1. 현금영수증 신청 -> '소득공제용' 선택
2. 휴대폰 번호 입력 후 결제 완료
3. 마이페이지 주문 내역 확인		 - 1. 주문 상세 내역에 현금영수증 신청 여부가 '신청됨'으로 저장되어야 함.

2.1.4. 마이페이지 및 취소/반품 (My Page & CS)

검증 목표: 주문 상태 변경에 따른 비즈니스 프로세스(즉시 취소 vs 승인 필요) 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
S04-01 결제 완료 후 즉시 취소 (상품 준비 중 이전) '결제 완료' 상태인 주문 건 보유 1. 마이페이지 > 주문목록 진입
2. '주문 취소' 버튼 클릭
3. 취소 사유 선택 후 확인		 사유: 단순 변심 1. 별도의 관리자 승인 절차 없이 즉시 '취소 완료' 상태로 변경.
2. 카드 결제 건인 경우 즉시 카드 취소 문자 수신 확인.
S04-02 배송지 변경 기능 제한 (상태 의존) '배송 중' 상태인 주문 건 보유 1. 마이페이지 > 배송 조회
2. '배송지 변경' 버튼 찾기 또는 클릭		 변경 주소: 부산 1. 이미 배송이 시작되었으므로 배송지 변경 버튼이 없거나, 클릭 시 "배송 중에는 변경할 수 없습니다" 알림 노출.
S04-03 교환/반품 신청 시 회수지 주소 검증 배송 완료된 상품 1. '교환/반품 신청' 클릭
2. 상품 수거지(회수지) 주소를 새로 입력
3. 유효하지 않은 주소 입력		 - 1. 회수지 주소가 정확해야 신청 가능.
2. 와우 회원의 경우 '무료 반품' 문구가 노출되는지 확인(일반 회원은 반품비 차감).

2.1.5 실무  활용 팁

  1. 쿠팡의 핵심은 '속도'와 '멤버십'입니다: TC 작성 시 항상 일반 회원 vs 와우 회원을 구분하여 예상 결과(배송비, 반품비)를 다르게 작성해야 합니다.
  2. 데이터 무결성: S03-04와 같은 동시성 이슈(재고 1개일 때 경쟁)는 이커머스 QA에서 가장 중요한 엣지 케이스입니다.
  3. 환경: 모바일 웹(Mobile Web)과 데스크톱 웹의 UI가 다르므로, Browser/OS 컬럼을 추가하여 환경별로 테스트 결과를 기록하는 것이 좋습니다.

 

Coupang_TestCases.xlsx
0.01MB

 

 

2.2. 금융 (Finance )

핵심 전략: 경계값 분석(Boundary Value Analysis)과 유효성 검사(Validation)가 가장 중요합니다. 돈과 관련된 수치는 1원의 오차도 허용하지 않으며, 입력 필드의 제약 조건이 매우 까다롭습니다.

  • 주요 기능 검증 포인트:
    • 입력 데이터: 계좌번호 형식, 금액 입력 불가 문자(한글, 특수문자), 최대 이체 한도.
    • 계산 로직: 예금/대출 이자 계산, 환율 우대 적용 후 최종 금액.
    • 워크플로우: 승인/거절 절차, 잔액 부족 시 처리.
    • 상세 예시 
    • Scenario: 타행 이체 시 잔액 및 수수료 포함 출금 검증
    • Test Case:
      1. 전제 조건: 계좌 잔액 10,000원, 타행 이체 수수료 500원.
      2. 단계 1 (경계값 - 실패): 이체 금액에 10,000원을 입력하고 이체를 시도한다.
        • 예상 결과: "수수료(500원)를 포함한 잔액이 부족합니다" 메시지 출력 및 이체 불가.
      3. 단계 2 (경계값 - 성공): 이체 금액에 9,500원을 입력하고 이체를 시도한다.
        • 예상 결과: 정상 이체 처리. 출금 후 잔액은 정확히 0원이어야 함.
      4. 단계 3 (입력값 제한): 금액 칸에 '-100' 또는 문자를 입력한다.
        • 예상 결과: 입력 자체가 안 되거나, "유효한 금액을 입력해주세요" 경고 노출.

 

좀더 자세히 알아볼까요?

 

 

KB국민은행(KB Star Banking Web)의 핵심 기능인 로그인/인증, 조회, 이체, 상품 가입을 중심으로 한 실무용 블랙박스 테스트 시나리오(TS)와 테스트 케이스(TC)

 

금융권 테스트의 핵심은 "돈과 관련된 데이터의 정합성(1원의 오차도 허용 안 함)"과 "강력한 보안 정책(세션, 인증수단)" 준수입니다.

2.2.1 테스트 개요

  • 대상: KB국민은행 개인뱅킹 웹사이트 (PC/Mobile Web)
  • 주요 검증 영역:
    1. 로그인 및 보안: 다양한 인증 수단(KB국민인증서, 공동인증서 등) 및 세션 관리.
    2. 계좌 조회: 잔액 및 거래내역의 정확한 표기 (마스킹 처리 포함).
    3. 이체 서비스: 잔액 부족, 한도 초과, 수수료 계산, 착오 송금 방지.
    4. 뱅킹 관리: 보안매체(OTP/보안카드) 오류 시 프로세스.

2.2.2. 로그인 및 인증 (Authentication & Security)

검증 목표: 금융권 특유의 복잡한 인증 수단 간의 호환성과 보안 정책(오류 횟수 제한, 타임아웃) 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
KB-01-01 KB국민인증서(앱 연동) 로그인 스마트폰에 KB스타뱅킹 앱 설치 및 인증서 발급 상태 1. PC 웹에서 'KB국민인증서 로그인' 선택
2. 이름/주민번호 입력 후 요청
3. 스마트폰 앱에서 인증 완료		 - 1. PC 화면이 자동으로 로그인 완료 상태로 전환되어야 함.
2. '나의 자산' 요약 화면이 노출되어야 함.
KB-01-02 비밀번호 오류 횟수 누적 제한 (계정 잠금) 공동인증서 보유 1. 공동인증서 로그인 시도
2. 비밀번호를 연속 5회 틀리게 입력		 비밀번호: 오입력 5회 1. 5회째 오류 시 "비밀번호 오류 횟수 초과로 거래가 제한됩니다" 알림 노출.
2. 이후 올바른 비번을 입력해도 로그인이 불가해야 함 (영업점 방문/본인인증 필요).
KB-01-03 자동 로그아웃 (세션 타임아웃) 검증 로그인 후 메인화면 진입 1. 로그인 연장 버튼을 누르지 않고 10분간 대기
2. 10분 경과 후 아무 메뉴나 클릭		 - 1. "로그인 시간이 만료되었습니다" 알림 노출.
2. 로그인 페이지로 리다이렉트되어야 함 (보안 보안 정책).
KB-01-04 타행 인증서 등록 프로세스 타기관(신한/우리 등)에서 발급받은 인증서 보유 1. 인증센터 > 타행 인증서 등록 메뉴 진입
2. 타행 인증서 선택 및 개인정보 확인		 - 1. 정상적으로 등록 처리가 완료되어야 함.
2. 등록 직후 해당 인증서로 로그인이 가능해야 함.

2.2.3 계좌 조회 (Account Inquiry)

검증 목표: 날짜 필터링 기능과 민감 정보(계좌번호 등)의 마스킹 처리 여부 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
KB-02-01 과거 거래내역 조회 (기간 설정 로직) 거래 내역이 존재하는 입출금 계좌 1. 조회 기간을 '직접 입력' 선택
2. 시작일을 종료일보다 미래로 설정
3. '조회' 버튼 클릭		 시작: 2024-12-01
종료: 2024-01-01		 1. "조회 시작일이 종료일보다 클 수 없습니다" 또는 날짜가 자동 보정되어야 함.
2. 데이터베이스 호출이 발생하지 않아야 함.
KB-02-02 계좌번호 마스킹 해제 검증 로그인 상태 1. 전계좌조회 화면 진입
2. 계좌번호가 '123456--****'로 보이는지 확인
3. '마스킹 해제' 또는 '계좌번호 복사' 시도		 - 1. 기본 상태는 별표(*) 처리되어야 함.
2. 해제 시 추가 인증(비밀번호 등)을 요구하거나 전체 번호가 노출되어야 함.
KB-02-03 휴면 계좌 조회 및 복원 안내 장기간 미사용으로 정지된 계좌 보유 1. 휴면 계좌 조회 메뉴 진입 - 1. 거래 중지 계좌 목록에 해당 계좌가 떠야 함
2. '계좌 해지' 또는 '거래 재개' 프로세스로 유도하는 버튼이 있어야 함.

2.2.4. 이체 (Transfer) - 핵심 기능

검증 목표: 잔액, 수수료, 이체 한도(1일/1회) 등 돈이 오가는 로직의 무결성 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
KB-03-01 잔액 부족 시 이체 차단 잔액: 10,000원
수수료: 500원		 1. 타행 이체 선택
2. 이체 금액에 10,000원 입력
3. '이체 실행' 버튼 클릭		 이체금: 10,000원 1. "출금 가능 잔액(수수료 포함)이 부족합니다" 알림 노출.
2. 이체 프로세스가 중단되어야 함. (잔액 < 이체금+수수료)
KB-03-02 보안매체(OTP) 오류 검증 이체 정보 입력 완료 상태 1. OTP 입력 팝업 호출
2. 틀린 OTP 번호 6자리 입력		 - 1. "OTP 번호가 일치하지 않습니다 (오류횟수 1/5)" 메시지 출력.
2. 이체가 실행되지 않아야 함.
KB-03-03 1회 이체 한도 초과 검증 보안등급별 1회 한도: 1,000만 원 설정됨 1. 이체 금액에 1,000만 1원 입력
2. 다음 단계 진행		 이체금: 10,000,001원 1. "1회 이체 한도를 초과하였습니다" 알림 노출.
2. 한도 증액 안내 메뉴로 유도하거나 금액 수정 요구.
KB-03-04 착오 송금 방지 (계좌 실명 조회) - 1. 수취인 은행 선택
2. 유효하지 않은(없는) 계좌번호 입력
3. '계좌 확인' 버튼 클릭		 - 1. "해당 계좌번호가 존재하지 않습니다" 또는 "오류 코드 [XXXX]" 노출.
2. 수취인 이름이 표시되지 않아야 함.
KB-03-05 예약 이체 설정 및 실행 - 1. '예약 이체' 선택
2. 이체 일시를 '내일 오전 10시'로 설정
3. 이체 신청 완료		 - 1. 잔액은 즉시 차감되지 않음(은행 정책에 따라 다름, 보통 당일에 빠짐).
2. 예약 내역 조회 리스트에 '대기' 상태로 등록되어야 함.

2.2.5. 금융 상품 및 계산기 (Products & Calculator)

검증 목표: 예적금 금리 계산과 환전 시 환율 우대 로직이 정확한지 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
KB-04-01 적금 가입 시 우대금리 조건 체크 급여 이체 실적이 없는 계좌 1. '직장인 우대 적금' 상품 페이지 진입
2. '예상 금리 조회' 버튼 클릭		 - 1. 기본 금리만 적용된 이자율이 표시되어야 함.
2. "급여 이체 실적 시 +0.3% 추가 제공" 안내 문구 확인.
KB-04-02 대출 이자 계산기 검증 - 1. 금융 계산기 > 대출 계산기 진입
2. 대출금 1억, 연이율 5%, 기간 12개월 입력
3. 상환 방식을 '원리금 균등'으로 선택		 - 1. 매월 갚아야 할 금액이 1원 단위까지 정확히 계산되어야 함.
2. 총 이자 금액이 단순 계산(단리/복리)과 일치해야 함.
KB-04-03 외화 환전 시 우대율 적용 주요 통화(USD, JPY) 90% 우대 이벤트 중 1. 외화 환전 메뉴 진입
2. USD 100달러 환전 신청
3. 적용 환율 확인		 - 1. 고시 환율 대비 90% 우대가 적용된 환율(Spread 차감)이 표기되어야 함.
2. 원화 환산 금액이 정확해야 함.

2.2.6. 금융권 QA 실무 팁

  1. 로그인 유지 시간(Session Timeout): 은행 사이트는 보안상 10분 정도 움직임이 없으면 로그아웃됩니다. 테스트 시 이 기능을 끄거나(개발계), 시나리오에 포함하여 검증해야 합니다.
  2. 공휴일/영업시간 외 테스트: "밤 11시 30분 ~ 00시 30분(점검 시간)"이나 "주말"에 타행 이체나 펀드 가입을 시도하여, '거래 불가 시간 안내'가 제대로 뜨는지 확인하는 것은 필수 TC입니다.
  3. 마스킹(Masking): 이름(김민), 계좌(123-), 주민번호(800101-1***) 등 개인정보가 화면에 그대로 노출되면 중대 결함(Critical Issue)입니다.

 

KB_Banking_TestCases.xlsx
0.01MB

 

 

 

2.3. IoT, AI (Smart Device)

핵심 전략: 사용자의 명확하지 않은 입력(Vague Input) 처리와 하드웨어의 물리적 상태 동기화를 확인해야 합니다.

 

앱(SW)과 기기(HW) 간의 상태 불일치를 찾아내는 것이 핵심입니다.

  • 주요 기능 검증 포인트:
    • 상태 동기화: 앱에서 스위치를 켰을 때 실제 기기가 켜지는지, 기기를 손으로 껐을 때 앱에 반영되는지.
    • AI 발화 의도 파악: 동의어 처리(켜줘, 켜라, 턴온), 복합 명령 처리.
    • 스케줄링: 예약된 시간에 정확히 동작하는지.
  • 상세 예시
    • Scenario: 스마트 전구의 밝기 조절 및 앱 동기화 검증
    • Test Case:
      1. 전제 조건: 전구가 앱과 페어링되어 있고 '켜짐' 상태.
      2. 단계 1 (앱 제어): 앱에서 밝기를 100%에서 50%로 조절한다.
        • 예상 결과: 실제 전구 밝기가 즉시 어두워져야 하며, 앱 UI 수치도 50%로 유지됨.
      3. 단계 2 (음성 제어): AI 스피커에 "전구 밝기 최대로 해줘"라고 명령한다.
        • 예상 결과: 실제 전구가 가장 밝게 변하고, 앱 화면을 새로고침 했을 때 밝기 수치가 100%로 변경되어야 함.
      4. 단계 3 (예외 상황): 전구의 물리적 전원 스위치를 끈 상태에서 앱으로 밝기 조절을 시도한다.
        • 예상 결과: "기기가 오프라인입니다" 또는 "응답 없음" 처리가 되어야 하며, 무한 로딩에 걸리면 안 됨.

좀더 자세히 알아볼까요?

 

 

카카오프렌즈 LED 라이언 홈 스마트 IoT 램프의 제품 스펙(Wi-Fi/BT 듀얼 연결, 색온도/RGB 제어, 전원 방식 등)을 기반으로 작성한 실무용 블랙박스 테스트 시나리오(TS)와 테스트 케이스(TC)

 

IoT 제품 테스트의 핵심은 "앱 명령과 실제 기기 동작 간의 지연 시간(Latency)" 및 "네트워크 연결 끊김 시 재연결 안정성"입니다.

2.3.1 테스트 개요

  • 대상 기기: 카카오프렌즈 LED 라이언 홈 스마트 IoT 램프
  • 테스트 환경:
    • H/W: 램프 본체, 전용 USB 케이블, 5V 어댑터
    • S/W: 전용 모바일 앱 (카카오홈 또는 제조사 앱), 2.4GHz 와이파이 환경
  • 주요 검증 영역:
    1. 전원 및 물리적 동작: USB/AC 전원 인가 및 물리 버튼 반응.
    2. 연결성 (Connectivity): Wi-Fi/블루투스 페어링 및 네트워크 전환.
    3. 조명 제어 (Lighting): 밝기, 색온도(K), RGB 색상 변경 및 동기화.
    4. 스마트 기능: 타이머 작동 및 앱 상태 반영.
    5. 예외 처리: 네트워크 단절 및 정전 보상(Last State Memory).

2.3.2. 전원 및 하드웨어 (Power & Hardware)

검증 목표: 다양한 전원 입력 방식(USB, AC)에서의 동작 안정성과 물리 버튼 기능 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
IoT-01-01 전원 공급 방식별 정상 부팅 확인 기기 전원 Off 1. PC USB 포트에 연결하여 전원 ON
2. (전원 해제 후) 220V AC 어댑터에 연결하여 전원 ON		 - 1. 두 환경 모두에서 라이언 램프에 불이 들어와야 함.
2. 전원 부족으로 인한 깜빡임(Flickering)이 없어야 함.
IoT-01-02 물리 버튼(또는 터치) 동작 검증 앱 미연동 상태 1. 기기 하단/후면의 물리 버튼을 1회 클릭 (On/Off)
2. 버튼을 길게 누름 (페어링 모드 진입)		 - 1. 즉시 조명이 켜지거나 꺼져야 함.
2. 길게 누를 시 상태 표시 LED가 깜빡이며 페어링 모드로 진입해야 함.
IoT-01-03 발열 및 장시간 사용 안정성 밝기 100%, 7000K 설정 1. 최대 밝기로 4시간 연속 점등
2. 램프 표면(실리콘/플라스틱) 온도 확인		 - 1. 조명이 꺼지거나 앱 연결이 끊기지 않아야 함.
2. 손으로 만졌을 때 화상을 입을 정도로 뜨거워지지 않아야 함.

2.3.3. 연결성 및 페어링 (Connectivity & Pairing)

검증 목표: IoT 기기의 최대 난관인 '초기 연결'과 'Wi-Fi 대역폭(2.4GHz vs 5GHz)' 이슈 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
IoT-02-01 Wi-Fi 5GHz 대역 연결 시도 (예외 처리) 스마트폰이 5GHz 와이파이에 연결됨 1. 앱에서 기기 추가 시도
2. 5GHz 와이파이 정보 입력 및 연결 시도		 SSID: Home_5G 1. 연결 실패 메시지가 뜨거나, "2.4GHz 네트워크만 지원합니다"라는 안내 문구가 노출되어야 함.
IoT-02-02 블루투스(BLE) 연동 및 제어 와이파이 공유기 전원 Off 1. 스마트폰 블루투스 ON
2. 와이파이 없는 환경에서 앱으로 조명 제어 시도		 - 1. Wi-Fi가 없더라도 블루투스를 통해 근거리 제어(On/Off)가 가능해야 함 (제품 스펙상 BT 지원 시).
IoT-02-03 Wi-Fi 재연결 안정성 기기 정상 연결 상태 1. 공유기 전원을 껐다가 30초 후 다시 켠다.<
2. 앱에서 기기 상태 확인		 - 1. 공유기 부팅 완료 후 1분 이내에 램프가 자동으로 '온라인' 상태로 복구되어야 함.

2.3.4. 조명 제어 및 동기화 (Lighting Control)

검증 목표: 스펙상의 색온도(3,500~7,000K)와 RGB 색상이 앱 명령대로 정확히, 빠르게 반영되는지 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
IoT-03-01 색온도(Color Temp) 범위 변경 백색광 모드 1. 색온도 바를 최저(3,500K)로 설정
2. 색온도 바를 최대(7,000K)로 설정		 - 1. 3,500K: 따뜻한 노란빛(Warm White)으로 변경.
2. 7,000K: 차가운 하얀빛(Cool White)으로 변경.
3. 전환 시 끊김 없이 부드럽게(Fading) 변경되어야 함.
IoT-03-02 RGB 색상 변경 및 정확도 컬러 모드 1. 색상 휠에서 '빨간색(Red)' 선택
2. '파란색(Blue)' 선택		 - 1. 라이언 램프 색상이 앱에서 선택한 색과 육안상 유사하게 변경되어야 함.
IoT-03-03 밝기(Dimming) 미세 조절 현재 밝기 50% 1. 밝기를 1%로 설정
2. 밝기를 100%로 설정		 - 1. 1%: 꺼진 것은 아니지만 아주 희미하게 켜져 있어야 함.
2. 100%: 눈부심이 느껴질 정도로 최대 광량이 나와야 함.
IoT-03-04 앱-기기 상태 동기화 (Latency) 기기 켜짐 상태 1. 앱에서 '끄기(Off)' 버튼 터치
2. 실제 램프가 꺼지는 시간 측정		 - 1. 버튼 터치 후 1초 이내(로컬 네트워크 기준)에 실제 램프가 꺼져야 함.

2.3.5. 스마트 기능 및 타이머 (Automation)

검증 목표: 사용자가 설정한 시간에 정확히 동작하는지와 앱 UI의 상태 반영 여부.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
IoT-04-01 타이머(Timer) 종료 기능 램프 켜짐 상태 1. 앱에서 타이머 '1분 후 끄기' 설정
2. 1분 대기		 설정: 1min 1. 정확히 1분 뒤 램프가 꺼져야 함.
2. 앱 화면의 상태도 'Off'로 갱신되어야 함.
IoT-04-02 예약 설정(Schedule) 중복 테스트 - 1. 오전 9시에 켜짐 예약
2. 오전 9시에 꺼짐 예약 (동시간 충돌)		 - 1. 앱에서 "중복된 시간입니다"라며 설정을 막거나, 나중에 설정한 값이 우선 적용되어야 함(논리 오류 방지).

2.3.6. 예외 및 복구 (Exception & Recovery)

검증 목표: 정전이나 비정상 종료 후 기기가 멍청해지지 않고 이전 상태를 기억하는지(Last State Memory) 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
IoT-05-01 비정상 전원 차단 후 상태 복구 (메모리 기능) 설정: 밝기 50%, 색상 빨강(Red) 1. 램프가 켜진 상태에서 USB 케이블 강제 발거 (전원 차단)
2. 10초 후 다시 전원 연결		 - 1. 전원이 들어오면 초기화(백색)되지 않고, 직전 상태(빨강, 50%) 그대로 켜져야 함. (사용자 편의성 핵심)
IoT-05-02 펌웨어 업데이트 중 전원 차단 펌웨어 업데이트 알림 팝업 1. 업데이트 시작
2. 진행률 30%일 때 전원 코드 뽑음
3. 재연결		 - 1. 기기가 벽돌(Brick)이 되지 않아야 함.
2. 재부팅 시 업데이트 실패 알림이 뜨거나, 이전 버전으로 정상 부팅되어야 함.

2.3.7 스마트 조명 QA 실무 팁

  1. 반응 속도(Latency): 앱에서 버튼을 눌렀는데 2~3초 뒤에 불이 켜지면 사용자 경험(UX)상 불합격입니다. 0.5초~1초 이내 반응하는지 체크하세요.
  2. 색감 차이: 앱 화면의 '빨간색'과 실제 실리콘 램프를 투과해 나오는 '빨간색'의 괴리감이 큰지 확인해야 합니다 (감성 품질).
  3. 공유기 호환성: 저가형 IoT 기기는 통신사 기본 공유기나 특정 메시 와이파이에서 연결이 잘 안 되는 경우가 많습니다. 다양한 공유기 환경 테스트가 필요합니다.

 

 

IoT_Lamp_TestCases.xlsx
0.01MB

 

 

2.4. 자동차, 임베디드 (Automotive & Embedded)

핵심 전략: 상태 전이(State Transition) 테스트가 핵심입니다.

 

차량이나 기기의 현재 상태(주행 중, 정차 중, 후진 중)에 따라 특정 기능이 활성화되거나 차단되어야 합니다.

  • 주요 기능 검증 포인트:
    • HMI(Human Machine Interface): 디스플레이 조작이 실제 차량 기능(공조, 시트 등)과 연결되는지.
    • 인터락(Interlock): 주행 중 DMB 시청 불가, 기어가 P일 때만 트렁크 오픈 가능 등 안전 관련 기능 차단.
    • 물리 버튼: 롱 프레스(Long press) vs 숏 프레스(Short press) 구분 동작.
  • 상세 예시
    • Scenario: 후진 기어(R단) 진입 시 인포테인먼트 동작 검증 (Audio Ducking)
    • Test Case:
      1. 전제 조건: 시동 ON, 라디오 볼륨 레벨 10으로 재생 중.
      2. 단계 1: 기어 노브를 P(파킹)에서 R(후진)로 변경한다.
        • 예상 결과: 후방 카메라 화면이 최상단에 출력되고, 라디오 볼륨이 자동으로 레벨 3 이하로 줄어들거나 음소거되어야 함 (주차 보조 경고음을 듣기 위해).
      3. 단계 2: 후진 상태에서 라디오 볼륨을 강제로 키워본다.
        • 예상 결과: 볼륨 조절이 불가능하거나, 조절되더라도 경고음보다는 작게 유지되어야 함(사양에 따름).
      4. 단계 3: 기어를 다시 P 또는 D로 변경한다.
        • 예상 결과: 후방 카메라가 꺼지고, 라디오 볼륨이 원래 레벨(10)로 서서히 복귀해야 함.

좀더 자세히 알아볼까요?

 

 

BMW의 인포테인먼트 시스템(iDrive)은 HMI(Human Machine Interface)의 완성도가 매우 높기로 유명합니다. 터치스크린뿐만 아니라 iDrive 컨트롤러(조그 다이얼), 제스처 컨트롤, 음성 인식 등 다양한 입력 방식이 혼재되어 있어 이에 대한 교차 검증이 핵심입니다.

또한, 자동차 도메인의 특성상 '주행 중 규제(Driver Distraction Guidelines)'에 따른 기능 제한 테스트가 반드시 포함되어야 합니다.

2.4.1 테스트 개요

  • 대상: BMW iDrive (OS 7/8/8.5/9) 인포테인먼트 시스템
  • 주요 입력 장치: 센터 디스플레이(Touch), iDrive 컨트롤러(Knob/Button), 스티어링 휠 버튼, 음성 명령
  • 주요 검증 영역:
    1. Navigation: 목적지 설정, 경로 재탐색, HUD(Head-Up Display) 연동.
    2. Media/Connectivity: 블루투스, 카플레이(CarPlay)/안드로이드 오토, 라디오.
    3. Vehicle Settings: 주행 모드 변경, 차량 상태(TPMS 등) 확인, 공조 제어.
    4. Safety/Interlock: 주행 중 영상 재생 차단, 복잡한 입력 제한.

2.4.2. 내비게이션 & HUD (Navigation)

검증 목표: 경로 안내의 정확성 및 헤드업 디스플레이(HUD)와의 정보 동기화 지연 시간 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
BMW-01-01 목적지 설정 및 경로 탐색 (음성 vs 터치) GPS 수신 양호 1. 터치 키보드로 목적지 검색 후 '안내 시작' 터치
2. (안내 종료 후) 음성 명령으로 동일 목적지 설정		 목적지: "강남역" 1. 두 방식 모두 동일한 경로와 도착 예정 시간(ETA)을 산출해야 함.
2. 안내 시작 시 즉시 HUD에 화살표(Turn-by-turn)가 표기되어야 함.
BMW-01-02 경로 이탈 시 재탐색 (Rerouting) 주행 중, 경로 안내 중 상태 1. 안내된 경로가 아닌 다른 길로 고의 진입 (시뮬레이션) - 1. 경로 이탈 감지 후 3초 이내에 새로운 경로를 재탐색해야 함.
2. "경로를 이탈하여 재탐색합니다" 음성 안내가 나와야 함.
BMW-01-03 오디오 더킹 (Audio Ducking) 검증 음악 볼륨 15로 재생 중 1. 내비게이션 길 안내 음성(Turn-by-turn) 출력 시점 도달 - 1. 안내 음성이 나오는 동안 배경 음악 볼륨이 자동으로 줄어들어야 함 (설정값에 따름).
2. 안내 종료 후 원래 볼륨으로 부드럽게 복귀해야 함.
BMW-01-04 POI(주변 시설) 전화 걸기 연동 휴대폰 블루투스 연결됨 1. 지도상에서 식당 POI 선택
2. 상세 정보의 '전화 걸기' 아이콘 선택		 - 1. 내비게이션 화면 위로 전화 팝업이 뜨며 통화가 연결되어야 함.
2. 통화 종료 시 다시 지도 화면으로 복귀해야 함.

2.4.3. 미디어 & 연결성 (Media & Connectivity)

검증 목표: BMW 특유의 무선 카플레이(Wireless CarPlay) 안정성과 소스 전환 시 딜레이 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
BMW-02-01 무선 애플 카플레이 최초 연결 및 재진입 아이폰 블루투스/Wi-Fi ON 1. 기기 목록 > 새 기기 연결 > CarPlay 선택
2. 연결 완료 후 차량 시동 OFF 및 문 잠금
3. 5분 후 재탑승 및 시동 ON		 - 1. 최초 연결 시 아이폰 화면이 센터 디스플레이에 꽉 차게(Full Screen) 출력.
2. 재탑승 시 별도 조작 없이 15초 이내에 카플레이가 자동 연결되어야 함.
BMW-02-02 미디어 소스 전환 (라디오 ↔ 블루투스) 라디오 청취 중 1. '미디어' 버튼 클릭 또는 iDrive 휠 조작
2. 소스를 '블루투스 오디오'로 변경		 - 1. 라디오 소리가 즉시 끊기고, 휴대폰의 음악이 재생되어야 함.
2. 앨범 아트와 곡 제목이 디스플레이에 동기화되어야 함.
BMW-02-03 제스처 컨트롤(Gesture Control) 동작 제스처 기능 활성화 상태 1. 화면 앞에서 검지를 시계 방향으로 원을 그림 (볼륨 업)
2. 손바닥을 펴서 옆으로 밈 (곡 넘김)		 - 1. 제스처 인식 시 화면에 인식 아이콘이 떠야 함.
2. 실제 볼륨이 증가하거나 다음 곡으로 넘어가야 함 (오작동/미인식 체크).

2.4.4. 차량 제어 및 상태 (Vehicle Settings)

검증 목표: 드라이브 모드 변경에 따른 UI 테마 변화와 물리적 차량 제어의 HMI 반영 여부.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
BMW-03-01 드라이브 모드 변경에 따른 UI 테마 전환 시동 ON (COMFORT 모드) 1. 기어 노브 옆 'SPORT' 버튼 클릭
2. 기어 노브 옆 'ECO PRO' 버튼 클릭		 - 1. SPORT: 계기판(Cluster)과 센터 디스플레이 테마가 붉은색/역동적 UI로 변경.
2. ECO PRO: 파란색 테마로 변경 및 연비 주행 정보 표시.
BMW-03-02 앰비언트 라이트(Ambient Light) 색상 변경 야간 환경 또는 어두운 곳 1. 차량 설정 > 실내 조명 > 색상 변경
2. '파란색'에서 '주황색'으로 변경		 - 1. 대시보드 및 도어 트림의 실제 LED 색상이 즉시 변경되어야 함.
2. 도어 열림 시 해당 도어의 앰비언트 라이트가 빨간색(경고)으로 점멸하는지 확인 (안전 기능).
BMW-03-03 타이어 공기압 모니터링 (TPMS) 초기화 정차 상태 (P단) 1. 차량 상태 > 타이어 공기압 메뉴 진입
2. '초기화 실행' 선택
3. 주행 시작		 - 1. "초기화 중... 주행이 필요합니다" 메시지 노출.
2. 일정 거리 주행 후 진행률이 100%가 되며 "타이어 상태 정상"으로 갱신되어야 함.

2.4.5. 안전 및 인터락 (Safety & Interlock)

검증 목표: 주행 중(Driving)일 때 운전자의 주의를 분산시키는 기능이 정상적으로 차단되는지 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
BMW-04-01 주행 중 비디오 재생 차단 (DMB/USB) 정차 중 비디오 재생 확인됨 1. 기어를 D(Drive)로 변경
2. 브레이크에서 발을 떼고 속도 5km/h 이상 주행		 - 1. 속도가 규정치(보통 5~15km/h)를 넘는 순간 영상이 꺼져야 함.
2. "주행 중에는 시청할 수 없습니다" 문구 출력 (오디오는 계속 나와야 함).
BMW-04-02 주행 중 사용자 매뉴얼 열람 제한 - 1. 주행 중(D단, 30km/h) 상태 유지
2. 차량 설정 내 '사용자 설명서' 진입 시도		 - 1. 메뉴 진입이 비활성화(Dimmed)되거나 "안전을 위해 정차 시 이용 가능합니다" 팝업 노출.
BMW-04-03 후방 카메라(R단) 우선권 로직 시스템 부팅 중 (로딩 상태) 1. 시동 걸자마자(부팅 완료 전) 기어를 R(후진)로 변경 - 1. 시스템 로딩이 덜 되었더라도, 후방 카메라 화면이 최우선으로 강제 출력되어야 함.
2. 주차 가이드 라인(PAS)이 정상적으로 핸들 조향을 따라 움직여야 함.

2.4.6. iDrive 컨트롤러 특화 (Rotary Knob)

검증 목표: 터치스크린이 고장 났을 때 물리 컨트롤러만으로 모든 조작이 가능한지(접근성) 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
BMW-05-01 초성 검색 및 문자 입력 (조그 다이얼) 내비게이션 검색 화면 1. iDrive 휠을 돌려 자음 'ㄱ', 'ㄴ' 선택
2. 휠의 윗면을 손가락으로 터치하여 글자 쓰기 (Touchpad 기능)		 입력: "강남" 1. 휠 회전 시 포커스가 정확히 이동해야 함.
2. 휠 상단 터치패드에 손으로 글씨를 쓰면 문자가 인식되어 입력되어야 함.
BMW-05-02 퀵 버튼(바로가기) 동작 확인 복잡한 서브 메뉴 진입 상태 1. iDrive 컨트롤러 주변의 'MAP' 버튼 클릭
2. 'MEDIA' 버튼 클릭		 - 1. 현재 화면이 어디든 상관없이 즉시 지도 화면으로 이동해야 함.
2. 즉시 미디어 재생 화면으로 이동해야 함 (Depth 무시).

2.4.7. 자동차 인포테인먼트 QA 실무 팁

  1. Cold Boot vs Warm Boot:
    • Cold Boot: 차를 6시간 이상 주차했다가 처음 시동 걸 때 부팅 시간 측정 (블랙스크린 없는지).
    • Warm Boot: 시동 끄고 문 잠그고 편의점 다녀온 수준(5분) 뒤 재시동 시, 듣던 음악이 이어서 나오는지.
  2. 간헐적 이슈 재현: 자동차 버그는 "가끔 블투 연결 안 됨" 같은 간헐적 이슈가 많습니다. 이를 잡기 위해 Monkey Test (무작위 버튼 마구 누르기)나 장시간(24시간) 켜두기 테스트를 진행합니다.
  3. 글로벌 현지화: 한국형 내비(T맵 기반 등)와 순정 내비 간의 데이터 정합성, 그리고 한글 폰트가 깨지지 않고 UI 영역(Button)을 벗어나지 않는지(Truncation) 확인해야 합니다.

 

 

BMW_iDrive_TestCases.xlsx
0.01MB

 

 

2.5. 통신 (Public & Telecom)

핵심 전략: 복잡한 비즈니스 규칙(Business Rule)과 폼(Form) 검증이 핵심입니다. 다양한 사용자 유형(내국인/외국인, 미성년자/성인)에 따라 입력 양식과 처리 로직이 달라지는 것을 확인합니다.

  • 주요 기능 검증 포인트:
    • 자격 검증: 기초수급자, 다자녀 가구 등 조건에 따른 요금 감면 로직.
    • 일할 계산: 월 중간에 요금제를 변경할 경우 사용량과 요금이 날짜별로 정확히 쪼개져서 계산되는지.
    • 서류 첨부: 필수 증빙 서류 누락 시 진행 불가 처리.
  • 상세 예시
    • Scenario: 모바일 요금제 월 중 변경 시 데이터 제공량 및 과금 확인
    • Test Case:
      1. 전제 조건: 현재 A요금제(월 30,000원/데이터 3GB) 사용 중. 오늘은 15일(월의 딱 중간).
      2. 단계 1: B요금제(월 60,000원/데이터 10GB)로 변경 신청을 시도한다.
        • 예상 결과: 변경 전 안내 팝업에 "A요금제 일할 계산: 15,000원, B요금제 일할 계산: 30,000원, 합계 청구 예정액: 45,000원"이 정확히 표기되어야 함.
      3. 단계 2 (기사용량 체크): 만약 A요금제에서 이미 데이터 2GB(약 66%)를 썼다면?
        • 예상 결과: 일할 제공량(1.5GB)보다 많이 썼으므로, 초과 사용 요금이 발생함을 경고하거나 변경을 차단해야 함(정책에 따름).
      4. 단계 3: 변경 완료 후 '내 정보' 조회.
        • 예상 결과: 요금제명이 B로 바뀌어 있고, 남은 데이터는 B요금제의 절반(5GB)만 제공되어야 함.

 

좀더 자세히 알아볼까요?

 

 

SK텔레콤의 공식 온라인 지점인 T World (티월드) 웹사이트의 핵심 기능인 조회(실시간 요금/데이터), 변경(요금제/부가서비스), 납부, 로그인을 중심으로 한 실무용 블랙박스 테스트 시나리오(TS)와 테스트 케이스(TC)

 

통신사 도메인 테스트의 핵심은 "복잡한 과금 로직(일할 계산, 위약금)"과 "대규모 트래픽 처리", 그리고 "개인정보 보호"입니다.

2.5.1. 테스트 개요

  • 대상: T World PC/Mobile Web (https://www.tworld.co.kr/)
  • 테스트 유형: 블랙박스 기능 테스트 (Functional Testing)
  • 주요 검증 영역:
    1. MY(마이페이지): 실시간 잔여량, 청구 요금 조회 정확성.
    2. 상품 서비스: 요금제 변경 시 위약금 및 날짜 계산 로직.
    3. 납부: 요금 즉시 납부 및 결제 수단 변경.
    4. 로그인: T아이디 통합 로그인 및 세션 관리.

2.5.2. 로그인 및 인증 (T ID Authentication)

검증 목표: SKT 서비스의 통합 계정인 'T아이디'의 로그인 안정성과 비정상 접근 차단 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
TW-01-01 T아이디 로그인 및 서비스 연결 T아이디 보유, 회선 연동 상태 1. 메인화면 우측 상단 '로그인' 클릭
2. ID/PW 입력 후 로그인 시도		 - 1. 로그인 성공 후 메인화면에 "OOO님" 문구 노출.
2. 사용 중인 회선 정보(번호, 요금제)가 즉시 로딩되어야 함.
TW-01-02 비정상 로그인 시도 (잠금 처리) - 1. 비밀번호를 5회 연속 틀리게 입력 잘못된 PW 1. 5회 오류 시 "비밀번호 입력 횟수 초과" 알림 노출.
2. 본인 인증(휴대폰 인증 등)을 거치지 않으면 로그인이 차단되어야 함.
TW-01-03 다회선 고객 회선 전환 검증 1개의 ID에 2개 이상 회선(폰+인터넷 등) 보유 1. 로그인 후 'MY' 메뉴 진입
2. 상단 회선 번호 리스트 클릭 후 다른 회선 선택		 - 1. 선택한 회선(예: 인터넷 회선)의 정보로 화면이 새로고침 되어야 함.
2. 잔여량 및 요금 정보가 해당 회선 데이터로 변경되어야 함.

2.5.3. MY (실시간 잔여량 및 요금 조회)

검증 목표: 데이터/음성 잔여량 표기의 정확성과 요금 명세서의 세부 내역 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
TW-02-01 실시간 잔여 데이터 조회 정확성 데이터 무제한 요금제 사용 중 1. 메인화면 또는 MY 화면 진입
2. 데이터 잔여량 게이지 확인		 - 1. "무제한" 또는 "기본제공량 소진 후 속도제어" 문구가 명확히 표기.
2. 쉐어링/테더링 데이터 한도는 별도로 표기되어야 함.
TW-02-02 최근 3개월 요금 그래프 확인 최근 3개월간 납부 이력 존재 1. MY > 나의 요금 > 납부 내역 조회 진입
2. 그래프 UI 및 월별 금액 확인		 - 1. 지난달, 지지난달 요금이 그래프 높낮이로 시각화되어야 함.
2. 상세 내역 클릭 시 청구서 PDF 또는 상세 페이지가 열려야 함.
TW-02-03 소액결제 이용 내역 및 한도 조회 소액결제 차단 설정된 상태 1. MY > 소액결제 메뉴 진입
2. 이용 한도 확인 및 변경 시도		 - 1. 현재 한도가 '0원' 또는 '차단'으로 표시되어야 함.
2. 한도 상향 시도 시 본인 인증(SMS/PASS) 절차가 수행되어야 함.

2.5.4. 상품 서비스 (요금제/부가서비스 변경)

검증 목표: 통신사 테스트의 꽃인 '일할 계산(Pro-rated Calculation)'과 '위약금(Penalty)' 로직 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
TW-03-01 요금제 상향 변경 및 일할 계산 안내 현재 5만원 요금제 사용 중
(약정 기간 남음)		 1. 8만원대 요금제 선택 후 '변경하기' 클릭
2. 변경 안내 팝업 확인		 - 1. "변경 전 요금제는 사용 일수만큼 계산되어 청구됩니다" 문구 노출.
2. 다음 달 예상 청구 금액이 안내되어야 함.
3. 변경 완료 시 즉시 MY 페이지에 새 요금제명이 반영되어야 함.
TW-03-02 공시지원금 약정 위반 시 위약금 노출 공시지원금 받고 개통 후 6개월 미만 1. 요금제 하향(낮은 요금제) 변경 시도
2. 경고 팝업 확인		 - 1. "요금제 변경 시 위약금(반환금) OOO원이 발생할 수 있습니다"라는 강력한 경고(Alert)가 떠야 함.
2. '그래도 변경'을 누르기 전까지 변경되지 않아야 함.
TW-03-03 유료 부가서비스 가입 및 과금 유료(Wavve, Flo 등) 미가입 상태 1. 부가서비스 메뉴 > 유료 상품 가입 클릭
2. 가입 완료 후 이용 가능 여부 확인		 - 1. 가입 즉시 "가입 완료" 문자 메시지 수신.
2. 해당 앱(Wavve 등) 로그인 시 이용권이 활성화되어야 함.
TW-03-04 해지 방어 로직 (부가서비스 해지) - 1. 사용 중인 부가서비스 해지 버튼 클릭 - 1. "지금 해지하면 혜택이 사라집니다" 팝업 노출 (유지 유도).
2. 최종 해지 시 '당일 재가입 불가' 등의 제약 조건 안내 확인.

2.5.5. 요금 납부 (Billing & Payment)

검증 목표: 카드/계좌 납부 프로세스의 정상 동작과 이중 출금 방지.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
TW-04-01 즉시 납부 (신용카드) 이번 달 미납 요금 존재 1. MY > 요금 납부 > 즉시 납부 선택
2. 본인 명의 신용카드 정보 입력
3. 결제 시도		 카드정보 1. 결제 성공 메시지 노출.
2. 미납 금액이 즉시 '0원'으로 갱신되어야 함.
TW-04-02 타인 명의 카드로 납부 시도 - 1. 즉시 납부 시 '타인 카드' 선택
2. 카드 정보 입력 및 결제 시도		 - 1. 명의자가 다를 경우, '카드주 본인 인증(ARS/비밀번호)' 절차가 추가로 요구되어야 함.
2. 인증 실패 시 결제 차단.
TW-04-03 납부 방법 변경 (자동이체) 현재 지로(청구서) 납부 중 1. 납부 방법 변경 > '은행 계좌이체' 선택
2. 계좌번호 입력 후 변경 신청		 - 1. 금융결제원 검증을 통해 유효한 계좌인지 확인.
2. "다음 달부터 적용됩니다"라는 적용 시점 안내 메시지 노출.

2.5.6. 고객지원 및 기타 (Support & Utilities)

검증 목표: 위치 기반 서비스 및 로밍 데이터 로딩 속도 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
TW-05-01 가까운 지점/대리점 찾기 (LBS) 위치 정보 권한 허용 1. 고객지원 > 지점/대리점 찾기 진입
2. '내 위치 중심' 검색 클릭		 - 1. 현재 위치 기반으로 가장 가까운 T월드 매장이 지도에 표시되어야 함.
2. 업무 시간(영업 중/종료) 정보가 정확해야 함.
TW-05-02 로밍 요금제 조회 (국가별) - 1. 로밍 > 국가별 요금제 찾기
2. '일본' 또는 '베트남' 입력		 - 1. 해당 국가에서 사용 가능한 바로(baro) 요금제 리스트가 노출.
2. 통화/데이터 조건이 명확히 표시되어야 함.

2.5.7. 통신사 QA 실무 팁 (SKT T World 특화)

  1. 빌링 시스템 연동 지연(Latency): 요금을 막 납부했더라도, 메인 화면의 '납부할 금액'이 0원으로 바뀌는 데 최대 5~10분이 걸릴 수 있습니다. 이는 버그가 아니라 레거시 시스템의 동기화 시간일 수 있으니 정책을 확인해야 합니다.
  2. 월말/월초 테스트 주의: 매월 1일은 데이터 리셋, 매월 말일은 요금제 변경 제한 등의 특수 로직이 있습니다. 날짜를 변경해가며 테스트하거나, 말일 변경 불가 팝업을 확인하는 TC가 중요합니다.
  3. 가족 결합(Family Plan): T월드는 '온가족할인', '데이터 선물하기' 등 가족 간 연결 로직이 복잡합니다. 가족 구성원 중 한 명이 탈퇴하거나 요금제를 바꿀 때, 나머지 구성원의 할인율이 깨지는지 확인하는 것이 고급 QA 영역입니다.

 

 

TWorld_TestCases.xlsx
0.01MB

 

 

 

 

2.6 전자 (Consumer Electronics - 가전)

핵심 전략: 상태 전이(State Transition)와 인터락(Interlock, 안전장치) 테스트입니다. 사용자가 물리 버튼이나 터치 패널을 조작할 때, 기기가 현재 상태(동작 중, 멈춤, 에러)에 따라 올바르게 반응하는지 봅니다.

  • 주요 기능 검증 포인트:
    • 안전 기능: 문이 열리면 동작 정지, 과열 시 전원 차단.
    • 모드 충돌: '냉방' 중에 '난방' 버튼을 누르면 어떻게 처리되는가?
    • 메모리 기능: 전원을 껐다 켰을 때 이전 설정을 기억하는가?
  • 작성 예시
    • Scenario: 드럼 세탁기의 동작 중 도어 오픈(Door Open) 및 일시정지 로직 검증
    • Test Case:
      1. 전제 조건: 세탁기 전원 ON, 세탁물 투입 완료.
      2. 단계 1 (정상 동작): '표준 세탁' 코스를 선택하고 '시작' 버튼을 누른다.
        • 예상 결과: 도어 락(Lock)이 걸리는 딸깍 소리가 나며 급수가 시작되어야 함. 화면에 남은 시간이 표시됨.
      3. 단계 2 (강제 개방 시도): 동작 중에 세탁기 문을 강제로 열어본다(물리적 힘).
        • 예상 결과: 문이 열리지 않아야 함 (도어 락 기능 정상 작동).
      4. 단계 3 (일시 정지): '일시 정지' 버튼을 누르고 5초 대기한다.
        • 예상 결과: 세탁조 회전이 멈추고, 수위가 안전한 높이라면 도어 락이 해제되어야 함. (수위가 높거나 내부 온도가 높다면 락 유지).
      5. 단계 4 (재시작): 문을 다시 닫고 '시작' 버튼을 누른다.
        • 예상 결과: 세탁 과정이 처음부터가 아니라, 멈췄던 시점(예: 헹굼 단계)부터 이어져서 진행되어야 함.

좀더 자세히 알아볼까요?

 

 

LG전자 트롬 F12WVA (12kg 드럼세탁기)의 제품 스펙(AI DD, 4방향 터보샷, 6모션 등)을 기반으로 작성한 실무용 블랙박스 테스트 시나리오(TS)와 테스트 케이스(TC)

 

세탁기 테스트의 핵심은 "세탁 성능(기본기)", "안전 장치(도어락/어린이 보호)", 그리고 "센싱 로직(무게/재질 감지)의 정확성 검증입니다.

2.6.1. 테스트 개요

  • 대상 모델: LG TROM F12WVA
  • 테스트 환경: 수도/배수 연결 완료, 수평 유지 상태, LG ThinQ 앱 설치
  • 주요 검증 영역:
    1. 세탁 코스 및 센싱: AI 맞춤 세탁(무게/의류 감지) 및 코스별 동작 확인.
    2. H/W 제어: 다이얼 조작, 터치 반응, 도어 잠금(Door Lock), 급수/배수.
    3. 특화 기능: 4방향 터보샷 동작 여부, 통살균.
    4. 스마트 기능: Wi-Fi 원격 제어 및 알림.
    5. 안전/예외: 언밸런스(불균형) 감지, 차일드락.

2.6.2. 기본 세탁 및 AI 센싱 (Washing & Sensing)

검증 목표: 세탁물을 넣었을 때 기기가 무게와 재질을 정확히 판단하여 시간과 물 높이를 자동 설정하는지 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
LG-01-01 AI 맞춤 세탁(표준 코스) 무게 감지 로직 전원 ON, 세탁물 투입 1. 다이얼을 돌려 '표준' 코스 선택
2. '동작' 버튼 클릭
3. 드럼 회전(센싱) 동작 관찰		 세탁물: 수건 5장 (약 1kg) 1. 급수 전, 드럼이 좌우로 몇 번 회전하며 무게를 감지해야 함.
2. 감지된 무게에 맞춰 '예상 시간'이 디스플레이에 표시되어야 함 (소량일 경우 시간이 줄어듦).
LG-01-02 4방향 터보샷 분사 확인 (헹굼 단계) 헹굼 단계 진입 상태 1. 헹굼 사이클 진행 중 도어 글라스를 통해 내부 관찰 - 1. 드럼 내부의 4개 노즐(또는 상단)에서 물줄기가 강력하게 분사되어야 함.
2. 터보샷 작동 시 소음이 급수 소음과 다르게 발생하는지 확인.
LG-01-03 세탁 중 빨래 추가(Add Item) 기능 세탁 시작 10분 경과 (물 차오름) 1. '빨래 추가' 버튼 터치
2. 도어 잠금 해제음(딸깍) 확인 후 도어 오픈 시도		 - 1. 드럼 회전이 멈추고, 수위가 안전한 높이라면 도어락이 해제되어야 함.
2. 수위가 높거나 온도가 높으면 "빨래추가 불가" 메시지 또는 기능 미동작.

2.6.3. 조작부 및 하드웨어 (Control & Hardware)

검증 목표: 다이얼과 LED 터치 패널의 응답성과 물리적인 도어 안전 장치 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
LG-02-01 다이얼(Knob) 코스 선택 및 LED 연동 전원 OFF 상태 1. 전원 버튼 터치
2. 다이얼을 시계 방향으로 빠르게 돌림
3. 반시계 방향으로 돌림		 - 1. 다이얼 회전 속도에 맞춰 코스 LED 표시등이 지연 없이 이동해야 함
2. '표준'에서 시작해 한 바퀴 돌렸을 때 다시 제자리로 돌아와야 함.
LG-02-02 도어 락(Door Lock) 안전 강제성 세탁 진행 중 (고속 탈수 구간) 1. 탈수가 진행 중일 때 도어 핸들을 당겨본다. - 1. 물리적으로 도어가 절대 열리지 않아야 함.
2. 억지로 당겼을 때 경고음이 발생하거나 유격이 없어야 함.
LG-02-03 차일드락(버튼 잠금) 설정 및 해제 세탁 진행 중 1. [헹굼]+[탈수] 버튼을 동시에 3초간 누름 (모델별 상이)
2. 임의의 버튼 조작 시도		 - 1. 화면에 'CL(Child Lock)' 문구가 표시됨.
2. 전원 버튼을 제외한 모든 버튼 조작이 먹통이어야 함.

2.6.4. 스마트 기능 (IoT - ThinQ)

검증 목표: 12kg급 세탁기는 베란다에 있는 경우가 많으므로 원격 제어 및 알림의 정확성이 중요.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
LG-03-01 스마트폰 원격 제어(Remote Start) 세탁기 Wi-Fi 연결됨, 도어 닫힘 1. 세탁기에서 '원격 제어' 버튼을 눌러 활성화
2. 스마트폰 앱에서 세탁 코스 선택 후 '시작' 누름		 앱: ThinQ 1. 세탁기 도어가 잠기며 자동으로 세탁이 시작되어야 함.
2. 앱 화면에 "세탁 중" 상태와 남은 시간이 동기화되어야 함.
LG-03-02 세탁 종료 푸시 알림(Push Notification) 세탁 종료 1분 전 1. 세탁 종료(End) 멜로디 울림 확인
2. 스마트폰 상단 알림 확인		 - 1. 세탁 종료 후 1분 이내에 "세탁이 완료되었습니다. 세탁물을 꺼내주세요" 알림이 수신되어야 함.
LG-03-03 에너지 모니터링 데이터 정합성 표준 코스 1회 완료 1. 앱 내 '에너지 모니터링' 메뉴 진입
2. 방금 돌린 세탁 코스가 카운트되었는지 확인		 - 1. 최근 사용 이력에 날짜/시간/코스가 정확히 기록되어야 함.

2.6.5. 예외 처리 및 유지보수 (Error & Maintenance)

검증 목표: 불균형(Unbalance) 상황에서의 기기 보호 로직과 통살균 기능 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
LG-04-01 탈수 진입 시 언밸런스(UB/UE) 감지 - 1. 물을 잔뜩 머금은 두꺼운 이불 1장만 넣음 (한쪽 쏠림 유도)
2. '강력 탈수' 실행		 데이터: 젖은 이불 1. 탈수 진입 전 드럼이 좌우로 천천히 돌며 빨래 펴기(Balancing) 동작을 반복해야 함.
2. 균형이 맞지 않으면 시간을 멈추고 계속 시도하다가, 결국 'UE(Unbalance Error)'를 띄우고 멈춰야 함 (진동/파손 방지).
LG-04-02 배수 필터 막힘 시 에러 처리 배수 호스를 꺾어놓음 (가정) 1. 헹굼/탈수 코스 시작
2. 배수 시점 관찰		 - 1. 배수 모터 소리는 나지만 물이 빠지지 않음.
2. 일정 시간(약 10분) 후 'OE(Output Error/Drain Error)' 에러 코드를 출력하고 동작 정지.
LG-04-03 통살균(Tub Clean) 코스 검증 세탁조 비어있음 1. '통살균' 코스 선택 및 시작
2. 동작 온도 및 패턴 확인		 - 1. 일반 세탁보다 높은 온도(고온 살균)로 물을 데워야 함.
2. 드럼이 고속 회전하며 통 내부를 세척하는 패턴이 보여야 함.

2.6.6. 가전제품(세탁기) QA 실무 팁

  1. 진동/소음 테스트: 기능이 작동하더라도 탈수 시 세탁기가 '걸어 다니면(Walking 현상)' 불량입니다. 바닥 수평이 맞는 상태에서 규격 용량(12kg) 대비 50%, 80%, 100% 부하 테스트를 수행해야 합니다.
  2. 거품 감지: 세제를 과다하게 넣었을 때, 센서가 거품을 감지하고 '거품 제거(Soapsuds removing)' 프로세스(물 추가 급수 후 배수)를 수행하는지 확인하는 것은 고급 TC에 속합니다.
  3. 정전 보상: 세탁 중에 코드를 뽑았다가 다시 꽂았을 때, 처음부터 다시 시작하는지 아니면 멈춘 시점부터 이어 하는지(Last State Memory) 확인해야 합니다. (LG 트롬은 보통 안전을 위해 초기화되거나, 전원만 들어오고 대기 상태가 됩니다.)

 

 

LG_Washer_TestCases.xlsx
0.01MB

 

 

 

2.7. 공공 (Public/Administrative Services)

핵심 전략: 워크플로우(Workflow) 준수와 입력 양식(Form) 유효성 검사입니다. 신청,접수,승인,발급의 절차가 엄격하며, 필수 서류나 입력값이 누락되면 절대 다음 단계로 넘어가면 안 됩니다.

  • 주요 기능 검증 포인트:
    • 자격 확인: 주민등록번호 유효성 검증(자리수, 생성 규칙), 본인 인증 여부.
    • 첨부 파일: 허용된 확장자(PDF, JPG 등) 및 용량 제한 체크.
    • 상태 추적: 민원 신청 후 '접수 대기' 상태가 '처리 중'으로 올바르게 바뀌는지.
  • 작성 예시
    • Scenario: 주민등록등본 온라인 발급 신청 및 프린터 출력 제어
    • Test Case:
      1. 전제 조건: 공인인증서(또는 간편인증) 로그인 완료.
      2. 단계 1 (필수값 누락): 발급 용도(제출처)를 선택하지 않고 '신청하기' 버튼을 누른다.
        • 예상 결과: "발급 용도를 선택해주세요" 경고창이 뜨고 신청이 진행되지 않아야 함.
      3. 단계 2 (대상 선택): '과거 주소 변동 사항 포함' 옵션을 체크하고 신청한다.
        • 예상 결과: 미리보기 화면에서 현주소뿐만 아니라 과거 주소 리스트가 모두 포함된 문서가 생성되어야 함.
      4. 단계 3 (출력 제어): '인쇄' 버튼을 누른다. (가상 프린터/PDF 저장을 시도해본다)
        • 예상 결과: "공문서는 위변조 방지를 위해 PDF 저장이나 캡처를 지원하지 않습니다" 메시지와 함께 출력이 차단되거나, 전용 뷰어가 실행되어야 함.

좀더 자세히 알아볼까요?

 

 

대한민국 전자정부의 핵심 포털인 정부24(Gov.kr)의 실무용 블랙박스 테스트 시나리오(TS)와 테스트 케이스(TC)

 

정부24 테스트의 핵심은 "다양한 본인 인증 수단(간편인증, 공동/금융인증서)의 호환성", "입력 서식의 복잡한 유효성 검사", 그리고 무엇보다 "문서 출력 시의 보안 및 위변조 방지(프린터 제어)"입니다.

2.7.1. 테스트 개요

  • 대상: 정부24 PC 웹사이트 (https://www.gov.kr/)
  • 테스트 유형: 블랙박스 기능 테스트 (Functional Testing)
  • 주요 검증 영역:
    1. 로그인/인증: 간편인증(카카오/PASS 등), 공동/금융인증서, 비회원 로그인.
    2. 민원 신청: 주민등록등본 등 주요 민원 신청 프로세스 및 입력값 검증.
    3. 발급/출력: 문서 뷰어 실행, 프린터 호환성 체크, PDF 저장 제어.
    4. My Gov: 신청 내역 조회 및 보조금24 맞춤 혜택 확인.

2.7.2. 로그인 및 통합 인증 (Authentication)

검증 목표: 민간 인증서(간편인증)와 전통적인 인증서 간의 연동 안정성 및 비회원 접근 제어.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
GOV-01-01 간편인증(카카오/PASS) 로그인 연동 스마트폰에 인증 앱 설치됨 1. 로그인 > 간편인증 선택
2. 이름/생년월일/휴대폰 입력 후 '인증 요청'
3. 모바일 앱에서 인증 완료		 - 1. PC 화면에서 "인증이 완료되었습니다" 메시지 수신.
2. 로그인 상태로 메인 페이지 리다이렉트되어야 함.
GOV-01-02 비회원 로그인 및 본인 확인 로그아웃 상태 1. 민원 서비스 신청 시 '비회원 신청' 선택
2. 개인정보 수집 동의 및 정보 입력
3. 입력 정보 내의 보안문자 입력		 - 1. 회원가입 없이 신청 단계로 진입해야 함.
2. 단, 민감한 민원(등본 등)은 비회원이라도 추가 인증(간편인증 등)을 요구해야 함.
GOV-01-03 인증 세션 만료 (Time-out) 검증 로그인 후 30분 이상 미동작 1. 아무 동작 없이 대기 (연장 버튼 클릭 X)
2. 30분 경과 후 메뉴 이동 시도		 - 1. "로그인 시간이 만료되었습니다" 알림 노출
2. 작업 중이던 데이터는 저장되지 않고 로그인 페이지로 이동.

2.7.3. 민원 신청 및 서식 작성 (Application Form)

검증 목표: 주민등록등본(초본)을 기준으로, 복잡한 선택 옵션(발급 형태, 수령 방법)에 따른 로직 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
GOV-02-01 주소지 검증 및 관할 주민센터 연동 로그인 상태 1. 주민등록등본 교부 신청 진입
2. '주민등록상 주소' 드롭다운 확인
3. 실제 거주지와 다른 시/도 선택 시도		 - 1. 로그인한 사용자의 주민등록 데이터베이스에 등록된 시/도만 선택 가능하거나 자동 세팅되어야 함.
2. 임의 변경이 불가능해야 함.
GOV-02-02 발급 형태(선택 발급) 옵션 로직 - 1. 발급 형태를 '선택 발급'으로 체크
2. '과거 주소 변동 사항(전체)' 체크
3. '주민등록 뒷자리'는 '미포함' 체크		 - 1. 미리보기 또는 최종 발급 문서에 과거 주소는 모두 나오되, 주민번호 뒷자리는 * 처리되어야 함 (옵션 교차 적용).
GOV-02-03 수령 방법 선택에 따른 프로세스 분기 - 1. 수령 방법을 '온라인 발급(본인출력)' 선택
2. 수령 방법을 '등기우편'으로 변경		 - 1. 본인출력: 수수료 무료(또는 감면) 및 즉시 처리.
2. 등기우편: 우편료 결제 화면으로 이동해야 하며 배송지 입력란이 활성화되어야 함.
GOV-02-04 제3자 제출 기능 검증 - 1. 수령 방법을 '온라인 발급(제3자 제출)' 선택
2. 수신인 ID(또는 기관명) 입력		 - 1. 내 PC에서 출력되지 않고, 지정된 수신인의 '문서지갑'으로 전송되어야 함.
2. "제출이 완료되었습니다" 안내 메시지 노출.

2.7.4. 문서 출력 및 보안 (Printing & Security)

검증 목표: 정부24의 가장 큰 기술적 허들인 '문서 뷰어 실행'과 '발급 불가 프린터 차단' 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
GOV-03-01 전용 뷰어 실행 및 팝업 차단 우회 브라우저 팝업 차단 설정됨 1. 신청 내역 > '문서 출력' 버튼 클릭
2. 뷰어 로딩 확인		 - 1. 팝업 차단 안내 바가 뜨거나, "팝업을 허용해주세요" 메시지가 떠야 함.
2. 허용 후 뷰어(EzPDF 등)가 정상 실행되어 문서 내용을 보여줘야 함.
GOV-03-02 지원하지 않는 프린터(공유/가상) 차단 가상 프린터(PDF저장) 설치됨 1. 뷰어 내 '인쇄' 버튼 클릭
2. 프린터 목록에서 'Microsoft Print to PDF' 선택		 - 1. "지원하지 않는 프린터입니다" 또는 "발급 불가" 마크가 떠야 함.
2. 위변조 방지를 위해 로컬에 연결된 물리 프린터 또는 'IP 연결 승인된 프린터'만 선택 가능해야 함.
GOV-03-03 진본 확인 번호 생성 확인 문서 출력 완료 1. 인쇄된 종이 문서의 상단/하단 확인 - 1. 문서 확인 번호(16자리 등)와 바코드가 선명하게 인쇄되어야 함.
2. 해당 번호로 정부24 사이트에서 진위 확인이 가능해야 함.

2.7.5. 보조금24 및 생활정보 (Subsidy & Info)

검증 목표: 사용자 데이터를 기반으로 맞춤형 혜택이 정확히 필터링되는지 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
GOV-04-01 맞춤 안내 조회 (가구원 정보 연동) 다자녀 가구 등 특정 조건 계정 1. 보조금24 메뉴 진입
2. '나의 혜택' 조회 클릭		 - 1. 사용자의 연령, 소득, 가구원 수에 맞는 혜택(예: 다자녀 전기요금 감면)이 리스트업 되어야 함.
GOV-04-02 가족 정보 제공 동의 프로세스 - 1. 가족 구성원의 혜택을 보기 위해 '가족 동의 요청' 발송
2. 가족 구성원 계정으로 로그인 후 동의		 - 1. 동의 완료 즉시 신청자 화면에서 가족 구성원의 맞춤 혜택까지 합산되어 보여야 함.

2.7.6. 공공기관(정부24) QA 실무 팁

  1. 환경 호환성 (Cross Browsing): 과거 ActiveX 시절과 달리 현재는 HTML5 기반으로 전환되었으나, 여전히 구형 IE 모드나 특정 보안 모듈(AnySign 등)이 Chrome/Edge/Whale 브라우저에서 충돌 없이 설치되고 실행되는지 확인하는 것이 최우선 과제입니다.
  2. 수수료 결제 모듈: 민원 수수료(400원 등) 결제 시 신용카드/계좌이체/휴대폰결제/페이코 등 다양한 PG사 창이 뜨는데, 결제 성공 후 반드시 '신청 완료' 페이지로 정상 복귀(Return URL) 되는지 확인해야 합니다. (돈만 나가고 신청 안 되는 케이스 방지)
  3. 대기열(Queue) 테스트: 연말정산 시즌이나 청년수당 신청 기간 등 트래픽이 몰릴 때, "현재 접속 대기자 OOO명" 안내 페이지가 뜨고 순번이 되면 정상 진입하는지 확인해야 합니다.

 

gov24_testcase.xlsx
0.01MB

 

 

 

 

 

2.8. 보험 (Insurance)

핵심 전략: 복잡한 조건문(Conditional Logic) 검증입니다. 나이, 병력, 차종, 기간 등 수많은 변수에 따라 보험료가 달라지고 가입 가능 여부가 결정됩니다. 이를 '결정 테이블(Decision Table)' 기반으로 테스트합니다.

  • 주요 기능 검증 포인트:
    • 가입 제한(UW): 특정 질병 이력 체크 시 가입 불가(Underwriting) 처리.
    • 나이 계산: '만 나이' 기준으로 보험료 산출 및 특약 가입 가능 여부 판별.
    • 특약 종속성: 주계약을 선택해야만 선택할 수 있는 특약들의 활성화/비활성화 처리.
  • 작성 예시
    • Scenario: 자동차 보험 견적 산출 시 '운전자 범위'에 따른 보험료 변동 및 나이 제한 검증
    • Test Case:
      1. 전제 조건: 차량 모델(2,000cc 중형차) 선택 완료.
      2. 단계 1 (연령 위반): 최연소 운전자 생년월일을 '만 20세'로 입력하고, 특약으로 '만 26세 이상 한정'을 선택한다.
        • 예상 결과: "운전자 범위와 최연소 운전자의 나이가 맞지 않습니다"라는 에러 메시지가 출력되고 다음 단계 진행 불가.
      3. 단계 2 (범위 변경): 운전자 범위를 '부부 한정'에서 '누구나(가족 외 포함)'로 변경한다.
        • 예상 결과: 화면 우측의 '예상 보험료' 금액이 즉시 재계산되어 인상된 금액으로 갱신되어야 함.
      4. 단계 3 (담보 추가): '긴급출동 서비스' 미가입 상태에서 가입(5회)으로 변경한다.
        • 예상 결과: 총 보험료에 해당 특약 비용만큼 정확히 합산되어야 함.

 

보험 도메인은 워낙 로직이 방대하고 복잡하기 때문에 좀더 자세히상품 가입(설계), 심사(U/W), 보상(청구) 단계별로 나누어 훨씬 구체적인 블랙박스 테스트 전략을 알아 볼까요?

 

보험 시스템 테스트의 핵심은 "수많은 조건(나이, 병력, 직업, 담보 등)의 조합에 따라 결과값(보험료, 가입 가능 여부, 지급금)이 명세서와 정확히 일치하는가?"입니다.

2.8.1. 설계 및 청약 단계 (Quotation & Subscription)

사용자가 직접 정보를 입력하여 보험료를 산출하고 가입하는 단계입니다. 상품 간의 교차 검증과 보험료 계산 로직이 핵심입니다.

  • 핵심 검증 포인트:
    • 상호 배타적 담보: A특약을 선택하면 B특약은 선택할 수 없는 로직(예: '운전자 한정' 특약과 '누구나 운전' 특약 동시 가입 불가).
    • 연계 비율: 주계약 가입 금액에 따라 의무적으로 가입해야 하는 특약의 최소/최대 금액 확인(예: 사망 담보 1억 이상 가입 시, 암 진단비 최대 5천만 원까지만 설정 가능).
    • 보험료 산출: 나이, 성별, 직업 급수(1~3급) 변경 시 보험료 즉시 변동 확인.
  • 작성 예시
    • Scenario: 주계약 금액 변경에 따른 연계 특약 가입 한도 체크
    • Test Case:
      1. 전제 조건: 상품 규정상 '상해 사망(주계약)' 1억 원 가입 시, '골절 진단비(특약)'는 최대 100만 원까지만 가입 가능.
      2. 단계 1 (정상): 주계약 1억, 골절 진단비 50만 원 입력.
        • 예상 결과: 정상적으로 보험료가 산출되고 '다음' 버튼 활성화.
      3. 단계 2 (한도 초과): 주계약은 1억으로 유지하고, 골절 진단비를 200만 원으로 상향 조정.
        • 예상 결과: "주계약 가입 금액 대비 골절 진단비 한도를 초과했습니다(최대 100만 원)" 메시지 출력 및 진행 불가.
      4. 단계 3 (연계 조건 변경): 주계약을 2억으로 올린다. (규정상 이때 골절 진단비 한도가 200만 원으로 늘어난다고 가정)
        • 예상 결과: 아까 입력한 골절 진단비 200만 원에 대한 에러 메시지가 사라지고 정상 승인 처리.

2.8.2. 인수 심사 단계 (Underwriting)

가입자가 제출한 고지 사항(병력, 운전 여부 등)을 바탕으로 시스템이 자동으로 가입 승인/거절을 판단하는 로직입니다.

  • 핵심 검증 포인트:
    • 알릴 의무(고지 사항): "최근 3개월 내 병원 방문"에 '예' 선택 시 자동 심사로 넘어가는지, 아니면 즉시 거절되는지.
    • BMI/건강검진 연동: 키와 몸무게 입력 시 BMI가 자동 계산되어 비만일 경우 할증(보험료 인상)이나 거절이 뜨는지.
    • 직업 급수: 위험 직군(예: 스턴트맨) 선택 시 상해 관련 담보 가입이 막히는지.
  • 작성 예시
    • Scenario: 최근 병력 고지에 따른 자동 심사(Auto Scoring) 결과 검증
    • Test Case:
      1. 전제 조건: 30세 남성, 사무직(위험등급 낮음).
      2. 단계 1 (클린 케이스): "최근 5년 이내 암, 백혈병 진단 여부" 등 모든 질문에 '아니오' 선택.
        • 예상 결과: "즉시 가입 가능" 메시지와 함께 결제 화면으로 이동.
      3. 단계 2 (거절 케이스): "최근 3개월 이내 입원/수술 이력" 질문에 '예'를 선택하고, 병명을 '디스크'로 입력.
        • 예상 결과: "심사가 필요합니다" 팝업이 뜨거나, 해당 담보(상해 수술비 등)가 자동 삭제되어야 함.
      4. 단계 3 (조건부 승인): 병력은 없으나, "오토바이 운행 여부"에 '예'를 선택.
        • 예상 결과: 가입은 되지만 '이륜차 부담보(오토바이 사고는 보상 안 함)' 특약이 강제로 체크되어야 함.

2.8.3. 보상 및 청구 단계 (Claims & Payout)

사고 발생 후 보험금을 청구했을 때, 약관에 따라 지급액이 정확히 계산되는지 확인합니다. 돈이 나가는 단계이므로 가장 중요합니다.

  • 핵심 검증 포인트:
    • 면책 기간(Waiting Period): 가입 후 90일 이내 암 진단 시 지급금 0원 처리.
    • 감액 기간: 가입 후 1년 이내 진단 시 가입 금액의 50%만 지급.
    • 자기부담금(Deductible): 실손보험 청구 시 병원 급(의원/병원/상급종합병원)에 따라 공제 금액(1만 원/1.5만 원/2만 원) 차감 로직.
  • 작성 예시
    • Scenario: 암 보험 가입 시기에 따른 감액/면책 기간 지급액 검증
    • Test Case:
      1. 전제 조건: 암 진단비 5,000만 원 가입. (90일 면책, 1년 내 50% 지급 조건)
      2. 단계 1 (면책 기간 내): 가입일로부터 '60일' 지난 시점에 암 진단 청구 데이터를 입력한다.
        • 예상 결과: 지급 예정 금액 0원, 사유: "면책 기간 이내".
      3. 단계 2 (감액 기간 내): 가입일로부터 '180일(약 6개월)' 지난 시점에 청구 입력.
        • 예상 결과: 가입 금액의 50%인 2,500만 원이 계산되어야 함.
      4. 단계 3 (정상 지급): 가입일로부터 '370일(1년 경과)' 지난 시점에 청구 입력.
        • 예상 결과: 가입 금액 100%인 5,000만 원 전액 산출.

2.8.4. 계약 관리 (Policy Management - 유지/변경)

가입 이후 해지, 부활, 정보 변경 등에 대한 테스트입니다.

  • 작성 예시
    • Scenario: 보험료 미납에 따른 실효(Lapse) 및 부활(Revival) 처리
    • Test Case:
      1. 전제 조건: 월납 보험료 10만 원, 현재 정상 유지 중.
      2. 단계 1 (미납 처리): 2개월 연속 보험료 미납 상태를 시뮬레이션한다(날짜 강제 변경).
        • 예상 결과: 계약 상태가 '정상'에서 '실효(효력 상실)'로 변경되고, 보장 기능이 정지되어야 함.
      3. 단계 2 (사고 접수): 실효된 기간 날짜로 사고 접수를 시도한다.
        • 예상 결과: "실효 상태의 계약입니다"라며 접수 불가 처리.
      4. 단계 3 (부활 신청): 미납된 보험료와 연체 이자를 합산하여 입금 처리한다.
        • 예상 결과: 계약 상태가 다시 '정상'으로 변경되고, '부활일' 이후의 사고부터 보장이 가능해져야 함.

보험 도메인 테스트 요약표

구분 테스트 초점 (Test Focus) 주요 키워드
설계 입력값 간의 논리적 충돌 방지 상호 배타, 연계 비율, 가입 한도
심사 (U/W) 위험도에 따른 승인/거절 로직 고지 의무, 할증, 부담보, 인수 거절
보상 약관 날짜 기준 정확한 금액 산출 면책 기간, 감액 지급, 자기부담금
관리 시간 경과에 따른 상태 변화 미납, 실효, 부활, 해지 환급금

 

좀더 실무적 관점에서 자세히 살펴 볼까요?

 

 

삼성생명 웹사이트 및 모바일 앱의 핵심 기능인 계약 조회, 보험금 청구, 보험계약대출, 상품 가입 설계를 중심으로 한 실무용 블랙박스 테스트 시나리오(TS)와 테스트 케이스(TC)입니다.

 

생명보험사는 장기 계약(Long-term Contract)이 많고, 수익자/피보험자/계약자가 서로 다를 수 있는 복잡한 관계 설정이 되어 있어 이에 대한 검증이 필수적입니다.

2.8.5. 테스트 개요

  • 대상: 삼성생명 PC 웹 / 모바일 앱 (삼성생명 모바일창구)
  • 테스트 유형: 블랙박스 기능 테스트 (Functional Testing)
  • 주요 검증 영역:
    1. MY삼성생명: 계약 내용 조회, 해지환급금 조회, 납입 내역 확인.
    2. 보험금 청구: 사고/수술 보험금 접수 및 서류 첨부, 계좌 검증.
    3. 금융(대출): 보험계약대출(약관대출) 가능 금액 조회 및 실행.
    4. 상품(다이렉트): 생년월일/성별에 따른 보험료 시뮬레이션 정확성.

2.8.6 로그인 및 계약 조회 (My Page)

검증 목표: 다양한 인증 수단(카카오, 금융인증서 등)의 로그인 안정성과 계약자/피보험자 관계에 따른 조회 권한 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
SL-01-01 간편비밀번호(PIN) 로그인 및 세션 연장 앱 설치 및 PIN 등록 완료 1. 앱 실행 후 PIN 6자리 입력
2. 로그인 후 10분간 미조작 상태 대기
3. 팝업 확인		 - 1. 정상 로그인 후 메인 'MY' 화면 진입.
2. 타임아웃 1분 전 "로그인 시간을 연장하시겠습니까?" 팝업 노출.
3. 미응답 시 자동 로그아웃 처리.
SL-01-02 계약 관계에 따른 상품 노출 검증 계약자=A, 피보험자=B인 상품 보유 1. A(계약자)로 로그인하여 계약 조회
2. B(피보험자)로 로그인하여 계약 조회		 - 1. A: 보험료 납입 내역, 환급금 조회, 변경 권한이 모두 활성화됨.
2. B: 보장 내용(담보)만 조회 가능하며, 납입/환급금 관련 정보는 숨김 또는 제한 처리.
SL-01-03 예상 해지환급금 조회 정확성 변액 보험(투자형) 가입자 1. MY보험 > 해지환급금 조회 메뉴 진입
2. 기준 일자 확인		 - 1. "오늘 기준 환급금"과 "최저 보증 환급금"이 구분되어 표기.
2. 변액 상품 특성상 "시장 상황에 따라 변동될 수 있습니다" 문구 필수 노출.

2.8.7. 사고 보험금 청구 (Claim)

검증 목표: 청구 사유 입력부터 서류 첨부, 그리고 수령 계좌 유효성 검증(Account Validation)까지의 프로세스.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
SL-02-01 소액 청구 시 AI 자동 심사(OCR) 테스트 청구 금액 100만 원 이하 건 1. 사고 접수 > 진료비 영수증 사진 촬영/업로드
2. AI 텍스트 인식(OCR) 결과 확인		 이미지: 영수증 1. 병원명, 진료 일자, 금액이 자동으로 입력 필드에 채워져야 함.
2. 인식이 잘못된 경우 수동 수정이 가능해야 함.
SL-02-02 청구 필수 서류 누락 및 파일 형식 제한 - 1. 필수 서류(진단서 등) 첨부 단계에서 파일 미첨부
2. '다음' 버튼 클릭
3. 지원하지 않는 포맷(exe, zip) 업로드		 - 1. "필수 서류를 첨부해주세요" 알림과 함께 진행 차단.
2. 이미지(JPG, PDF) 외 파일 업로드 시 "지원하지 않는 형식입니다" 에러 노출.
SL-02-03 수령 계좌 실명 인증 (예금주 불일치) 수익자 본인 명의 계좌 필요 1. 보험금 수령 계좌 입력 단계
2. 타인 명의(가족 등) 계좌번호 입력
3. '계좌 확인' 클릭		 데이터: 타인계좌 1. 펌뱅킹 망을 통해 예금주명을 조회.
2. "예금주 정보가 일치하지 않습니다(수익자 본인 계좌만 가능)" 메시지 출력 및 진행 불가.

2.8.8. 보험계약대출 및 상환 (Policy Loan)

검증 목표: 해지환급금 범위 내에서 대출 가능 금액이 정확히 산출되는지와 즉시 입금 프로세스 확인.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
SL-03-01 대출 가능 금액 한도 초과 신청 대출 가능 한도: 500만 원 1. 보험계약대출 신청 메뉴 진입
2. 신청 금액에 501만 원 입력
3. 신청 시도		 금액: 501만원 1. 입력 필드에서 입력이 막히거나, "신청 가능 금액을 초과하였습니다(최대 500만 원)" 경고 노출.
SL-03-02 대출 실행 및 이자율 안내 - 1. 100만 원 신청 > 약관 동의
2. 적용 금리 및 이자 납입일 확인
3. 전자서명(인증서) 완료		 - 1. 적용 금리(예: 4.5%)가 상품별 약관에 맞게 표기되어야 함.
2. 신청 완료 즉시 연결된 계좌로 입금 처리가 완료되어야 함(실시간성).
SL-03-03 원리금 부분 상환 로직 기존 대출 100만 원 보유 1. 대출 상환 > 50만 원 상환 선택
2. 출금 계좌 선택 후 상환 실행		 - 1. 출금 계좌에서 50만 원+경과 이자가 정확히 차감되어야 함.
2. 상환 직후 대출 잔액이 50만 원으로 갱신되어야 함.

2.8.9. 상품 공시 및 다이렉트 설계 (Product Simulation)

검증 목표: 나이, 성별, 직업 등 변수에 따라 보험료가 1원 단위까지 정확하게 계산(Rate Calculation)되는지 검증.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
SL-04-01 연령별 보험료 차등 적용 확인 인터넷 암보험 상품 페이지 1. 생년월일 입력 (30세 남성) -> 보험료 확인
2. 생년월일 변경 (50세 남성) -> 보험료 확인		 - 1. 50세 남성의 보험료가 30세보다 높게 산출되어야 함 (위험률 반영).
2. '보험료 계산' 버튼 클릭 시 로딩 후 결과값이 즉시 변경되어야 함.
SL-04-02 가입 불가 연령(가입 제한) 테스트 가입 가능 연령: 20~60세 1. 생년월일을 70세 기준으로 입력
2. '보험료 확인' 클릭		 나이: 70세 1. "해당 상품의 가입 가능 연령은 20~60세입니다" 안내 팝업 노출.
2. 설계 프로세스가 중단되거나 실버 전용 상품 안내로 유도.
SL-04-03 특약(Option) 선택에 따른 보험료 합산 주계약 보험료 10,000원 1. 선택 특약(표적항암 등) 체크박스 선택
2. 합계 보험료 확인		 특약가: 1,500원 1. 총 보험료가 11,500원으로 즉시 갱신되어야 함.
2. 특약을 해제하면 다시 10,000원으로 복구되어야 함.

2.8.10. 퇴직연금 (Pension)

검증 목표: DC/IRP 계좌의 자산 현황과 투자 상품 변경(Switching) 기능의 정합성.

TC ID 시나리오 (Scenario) 전제 조건 (Pre-condition) 테스트 단계 (Test Steps) 테스트 데이터 (Input Data) 기대 결과 (Expected Result)
SL-05-01 수익률 조회 및 자산 평가액 확인 퇴직연금 가입자 1. 퇴직연금 > 자산 현황 조회
2. 납입 원금 vs 평가 금액 비교		 - 1. (평가 금액 - 납입 원금) / 납입 원금 = 수익률이 소수점 둘째 자리까지 정확히 맞아야 함.
2. 기준가 적용 일자(오늘/어제)가 명시되어야 함.
SL-05-02 위험 자산 투자 한도 제한 (70% 룰) IRP 계좌 보유 1. 상품 변경(매수) 진입
2. 주식형 펀드(위험 자산) 비율을 80%로 설정 시도		 - 1. "위험 자산은 전체 적립금의 70%까지만 운용 가능합니다" 메시지 노출.
2. 매수 신청이 불가해야 함 (금융 감독 규정 준수).

2.8.11. 보험사 QA 실무 팁 (삼성생명 특화)

  1. 변액 보험(Variable Insurance) 테스트: 변액 상품은 주식/채권 시장 상황에 따라 매일 '해지환급금'이 달라집니다. 테스트 시 "기준일(T일, T+1일, T+2일)"에 따라 금액이 맞게 나오는지 확인하는 것이 고난도 핵심 QA입니다.
  2. 전자서명 호환성: 보험 계약이나 대출은 법적 효력이 필요하므로 공동인증서, 금융인증서, 삼성패스, 카카오페이 인증 등 다양한 인증 수단이 PC와 모바일 양쪽에서 끊김 없이(Cross-platform) 작동하는지 반복 검증해야 합니다.
  3. Legacy 시스템 연동: 화면에는 '처리 완료'가 떴는데, 실제 기간계(Core Banking System)에는 반영이 안 되는 경우가 종종 있습니다. 실무에서는 화면 테스트 후 반드시 "실제 데이터가 DB에 적재되었는지" 확인해야 합니다.

 

 

samsunglife_testcase.xlsx
0.01MB

 

 

2.9 요약: 각 도메인별 블랙박스 테스트 핵심 마인드셋

  1. 금융: "돈과 날짜는 1의 오차도, 1초의 오차도 허용하지 않는다." (계산기 두드려가며 검증)
  2. 전자: "사용자는 설명서를 읽지 않는다. 막 눌러도 고장 나거나 다치면 안 된다." (안전 장치 및 오작동 방지)
  3. 공공: "절차와 서류가 완벽하지 않으면 접수조차 받지 말아야 한다." (유효성 검사 및 프로세스 통제)
  4. 보험: "조건(나이/병력)이 하나라도 바뀌면 결과값(보험료)도 즉시 바뀌어야 한다." (변수 간의 상관관계 검증)
  5. Web/E-Com: 돈 계산과 주문 상태 흐름이 꼬이지 않는가
  6. IoT/AI: 물리적 기기와 앱의 상태가 일치하는가?
  7. Auto/Embedded: 주행 상태에 따라 기능이 안전하게 켜지고 꺼지는가?

 

 

3. 좋은 테스트 케이스를 위한 공통 팁

  1. 전제 조건(Pre-condition) 명시: 테스트 시작 전 로그인이 되어 있어야 하는지, 특정 데이터가 있어야 하는지 적습니다.
  2. 재현 가능성: 누가 테스트하더라도 같은 결과가 나와야 합니다. "적당히 입력한다" 대신 "글자 수 100자를 입력한다"로 적으세요.
  3. 예외 처리 포함: 정상적인 흐름(Happy Path)뿐만 아니라, 오류 상황(Negative Path)을 반드시 포함해야 소프트웨어 품질이 올라갑니다.

도메인별 특성을 이해하고 시나리오를 작성하면, 단순한 버그 발견을 넘어 제품의 완성도를 높이는 핵심적인 역할을 할 수 있습니다.

 

QA,소프트웨어테스트,테스트케이스,테스트시나리오,금융IT,임베디드소프트웨어,자율주행,IoT,전자상거래,개발자

저작자표시 (새창열림)