SAP 테스트 케이스 설계: 시나리오 기반 E2E 테스트 가이드

SAP 프로젝트의 성패는 마지막 '품질 검증'에서 결정됩니다. 하지만 많은 실무자가 수천 장의 엑셀 테스트 시나리오를 관리하다 길을 잃습니다. "VA01(주문 생성) 테스트는 끝났는데, 왜 실제 배포 후에 회계 전표가 안 만들어지는 사고가 터질까?"라는 질문을 받아보셨다면, 지금 시스템의 테스트 케이스 설계 방식을 점검해야 할 때입니다.

오늘은 SAP 테스팅의 효율을 결정짓는 핵심 전략, '시나리오 중심의 E2E 테스트 설계'를 구체적인 예시와 함께 살펴보겠습니다.

1. T-Code 중심 테스트의 한계와 위험성

많은 기업이 여전히 T-Code(Transaction Code) 단위로 테스트 케이스를 작성합니다. 예를 들어 "VA01(주문 생성) 화면이 잘 뜨고 저장되는가?"를 확인하는 방식입니다. 하지만 이런 파편화된 접근은 다음과 같은 치명적인 한계를 가집니다.

• 비즈니스 단절: VA01 화면 자체는 정상이라도, 거기서 입력된 데이터가 이후의 출하(Outbound Delivery)나 회계 전표(FI) 생성까지 매끄럽게 이어지는지는 알 수 없습니다.

• 유지보수의 늪: SAP 표준 패치나 비즈니스 로직 변경 시, 영향받는 시나리오를 찾기 위해 수천 개의 엑셀 행을 일일이 필터링해야 합니다.

• 테스트 커버리지의 불확실성: 기능 단위의 테스트는 수행했을지 몰라도, 실제 현업이 수행하는 '전체 업무 흐름'을 얼마나 검증했는지 정량적으로 측정하기 어렵습니다.

2. 시나리오 중심의 E2E 테스트 설계

이 문제를 해결하기 위해서는 테스트 케이스를 비즈니스 흐름에 따라 시나리오 유형별로 재정의해야 합니다.

2-1. 시나리오 유형

1) 대표 시나리오 유형 (Representative Business Scenarios)

부서 간의 핸드오버(Hand-over)가 일어나는 핵심 업무 흐름 단위입니다.

예시:

• Order-to-Cash (O2C) - 고객 주문부터 대금 회수까지의 전 과정을 하나의 시나리오 묶음으로 관리

이는 실제 현업이 수행하는 '완결된 업무 프로세스'를 테스트의 기본 단위로 삼는 것입니다.

2) 크로스 모듈 시나리오 (Cross-Module Scenarios)

단순 모듈(SD, MM 등) 구분을 넘어 '영업관리', '구매관리', '생산관리' 등 기업의 핵심 밸류 체인 단위로 정의합니다.

예시:

• 판매-출하-청구-수금 (SD → MM → FI)

• 구매-입고-검수-지급 (MM → QM → FI)

• 생산계획-자재출고-생산실행-원가정산 (PP → MM → CO)

여러 모듈이 유기적으로 연결된 통합 시나리오를 검증하여, 모듈 간 인터페이스 오류를 사전에 발견할 수 있습니다.

3) 경우의 수가 다양한 시나리오 (Variant Scenarios)

실제 테스트가 수행되는 최소 단위입니다. 동일한 업무 흐름이라도 데이터 조건에 따라 처리 로직이 달라지는 경우를 세분화합니다.

예시:

• 일반 주문, 긴급 주문, 반품 주문

• 국내 판매, 해외 판매 (통화, 세금 차이)

• 과세 거래, 면세 거래, 영세율 거래

2-2. 구체적인 설계 예시: O2C(Order-to-Cash) 시나리오

"시나리오 중심 설계"가 막연하게 느껴진다면, SAP의 가장 대표적인 프로세스인 O2C(주문-수금)를 어떻게 구조화하는지 살펴보겠습니다.

• 크로스 모듈 시나리오: Sales & Distribution (영업관리)

• 대표 시나리오: 국내 표준 판매 프로세스 (Standard Sales)

• 경우의 수가 다양한 시나리오 - 상세 단계:

  • Step 1: 고객 주문 등록 (VA01) - 주문 유형, 고객 정보 입력

  • Step 2: 가용성 점검 및 출하 지시 (VL01N) - 재고 확인 및 물류 전달

  • Step 3: 피킹 및 출고 확인 (PGI) - 실제 창고 출고 처리

  • Step 4: 대금 청구 및 송장 생성 (VF01) - 고객 고지서 발행

  • Step 5: 고객 입금 처리 및 반제 (F-28) - 회계 전표 확정 및 수금 완료

이렇게 구조화하면 "긴급 주문"이나 "반품 주문" 프로세스를 테스트할 때, 이미 검증된 Step 2~3(출하/출고)은 그대로 두고 Step 1(주문)과 Step 4(청구) 로직만 교체하여 테스트 설계 시간을 50% 이상 단축할 수 있습니다.

3. 시나리오 기반 구조 설계 4단계 전략

단순히 구조만 나눈다고 효율이 생기지는 않습니다. 이를 '자산'으로 만들기 위한 실무 전략이 필요합니다.

Step 1: 비즈니스 인벤토리 파악 및 매핑

현재 사용 중인 모든 T-Code를 나열하는 것부터 시작하지 마세요. 대신 현업의 업무 기술서(Manual)를 펼치고, 부서 간 업무가 넘어가는 '바톤 터치(Hand-over)' 시점을 기준으로 프로세스 맵을 그려야 합니다. 이 맵이 테스트의 지도가 됩니다.

Step 2: 공통 컴포넌트(Reusable Component) 분리

로그인, 조직 코드 입력, 마스터 데이터 조회 등 모든 테스트에서 중복되는 동작은 하나의 '부품'으로 만듭니다. 나중에 시스템 환경설정이 바뀌었을 때, 수백 개의 엑셀 행을 고치는 대신 이 '부품' 하나만 수정하면 모든 시나리오에 자동으로 반영됩니다.

Step 3: 데이터 기반의 변수(Variant) 설정

하나의 대표 시나리오 안에서도 데이터에 따라 결과가 달라집니다. "법인 A는 과세, 법인 B는 면세"와 같은 비즈니스 규칙을 시나리오에 매핑하세요. 이때 중요한 것은 단순한 '임의 데이터'가 아니라, 실제로 운영에서 발생하는 유효한 데이터 조합을 사용하는 것입니다.

Step 4: 테스트 결과의 자산화 및 회귀 테스트(Regression) 연결

성공한 테스트 케이스는 '완료'하고 끝내는 것이 아닙니다. 시스템 업그레이드나 패치 시 동일한 품질을 보장하기 위한 '기준점(Baseline)'이 됩니다. 시나리오 기반으로 구조화된 케이스는 그대로 자동화 도구에 이식되어, 다음 배포 시 '무중단 서비스'를 보장하는 강력한 무기가 됩니다.

4. 산업군별 적용 사례: 시나리오 설계가 가져온 변화

사례 A: 복잡한 생산 체인을 가진 [제조업]

기존: 생산(PP)-구매(MM)-영업(SD) 부서가 각자 테스트하여, 부서 간 데이터 연계 오류를 놓침.

변화: '생산-출하-정산'을 잇는 크로스 모듈 시나리오 구조화

효과: 부서 간 인터페이스 오류를 사전에 100% 식별하고, 전체 E2E 테스트 커버리지를 40% 이상 확대함.

사례 B: 프로모션이 빈번한 [유통/CPG업]

기존: 수많은 할인 조건과 채널별 시나리오를 엑셀에 나열하여 관리하여, 시나리오 누락으로 인한 정산 오류 빈발.

변화: '채널별-프로모션 유형별' 경우의 수가 다양한 시나리오 구조화 및 가격 결정(Pricing) 로직 모듈화

효과: 신규 프로모션 추가 시 시나리오 작성 시간을 50% 단축하고, 정산 데이터 정합성을 완벽히 확보함.

5. 결론: 단순 기능 테스트를 넘어 시나리오 중심 검증으로

많은 기업이 여전히 T-Code 단위의 기능 테스트에 머물러 있습니다. VA01 화면이 뜨는지, 저장 버튼이 작동하는지 확인하는 것만으로는 실제 비즈니스의 안정성을 보장할 수 없습니다.

테스팅의 핵심은 '시나리오' 입니다.

실제 현업에서 발생하는 업무는 단일 트랜잭션으로 완결되지 않습니다. 주문을 받고, 재고를 확인하고, 출하하고, 청구하고, 수금하는 전체 흐름이 끊김없이 이어져야 합니다.

따라서 테스트도 이 흐름을 그대로 반영한 시나리오 중심으로 설계되어야 합니다.

시나리오 기반으로 설계된 테스트는 단순히 '화면이 작동하는가'를 넘어 '비즈니스가 정상적으로 흘러가는가'를 검증합니다. 이것이 진정한 품질 보증이며, 안정적인 SAP 운영의 시작점입니다.

[다음 편 예고] 이렇게 구조화된 시나리오를 완벽하게 실행하기 위해선 '데이터'가 필요합니다. 다음 포스팅에서는 "테스트 데이터 준비 시간을 70% 단축하는 데이터 프로비저닝 전략"에 대해 다뤄보겠습니다.