S/4HANA 테스트 전략: 사이클, 기준, 역할

S/4HANA 테스트 전략은 어떤 테스트 사이클을 어떤 순서로 실행할지, 각 사이클의 책임자가 누구인지, 어떤 증거가 있어야 다음 사이클로 넘어갈 수 있는지를 정합니다. 제 프로젝트에서는 여러 라운드의 통합 테스트(SIT), 여러 라운드의 사용자 인수 테스트(UAT), 회귀 테스트를 다루며, 각각에 문서화된 진입 및 종료 기준과 승인자를 이름으로 지정합니다.

제가 계획하는 S/4HANA 프로젝트에서 테스트는 프로젝트 공수의 약 35%를 차지합니다. 그래서 테스트 전략에는 빌드 계획만큼의 정성이 필요합니다.

테스트 유형 자체는 SAP 테스트 완전 정리 가이드에서 다룹니다. 이 글은 그 위의 전략 계층, 즉 사이클, 기준, 역할, 문서 구성을 다룹니다.

SAP Activate는 테스트의 대부분을 Realize에 둡니다. SAP의 S/4HANA Cloud Private Edition 테스트 전략 자료는 단위 테스트와 스트링 테스트를 비공식 테스트로 봅니다. 전체 비즈니스 프로세스 테스트, 통합 테스트, 데이터 마이그레이션 테스트, 사용자 인수 테스트는 공식 테스트이며 반드시 문서화해야 합니다.

제가 S/4HANA 프로젝트에서 계획하는 순서는 다음과 같습니다.

S/4HANA 테스트 사이클

1. 01

   단위 및 스트링 테스트

   컨설턴트가 구성한 기능과 짧은 연결 흐름을 만들면서 테스트합니다.

2. 02

   SIT 라운드

   모듈, 인터페이스, 마이그레이션 데이터를 아우르는 전체 프로세스 체인을 테스트합니다.

3. 03

   UAT 라운드

   현업 사용자가 시스템이 자신의 프로세스를 처리한다는 것을 라운드별로 증명합니다.

4. 04

   회귀 테스트

   수정, 트랜스포트, 릴리스 후 이미 통과한 것을 다시 테스트합니다.

5. 05

   모의 전환과 리허설

   체크리스트에 따라 실제 당일 밤과 똑같이 컷오버를 실행합니다.

6. 06

   Go-Live

   합의된 컷오버 체크리스트가 완료되었을 때만 진행합니다.

단위 테스트와 스트링 테스트

컨설턴트와 개발자는 구성 항목과 개발 항목을 만들면서 하나하나 테스트합니다. 스트링 테스트는 판매 오더에서 출하까지처럼 몇 단계를 연결해 테스트합니다.

SAP 기준으로는 비공식 테스트지만 생략할 수 있는 것은 아닙니다.

여러 라운드의 통합 테스트

SIT는 모듈, 인터페이스, 전환되거나 로드된 데이터를 아우르는 완전한 비즈니스 프로세스를 테스트합니다. 저는 SIT를 한 번의 이벤트가 아니라 여러 라운드로 계획합니다. 한 라운드 후에 수정한 결함은 다음 라운드에서 다시 테스트합니다.

SIT 라운드 수를 고정해 두지는 않습니다. 라운드 수는 범위에 포함된 프로세스, 인터페이스, 법인의 수에 따라 달라지며, 전략 문서에 몇 라운드를 왜 하는지 적어야 합니다.

여러 라운드의 사용자 인수 테스트

UAT는 현업이 자기 인력과 실제와 같은 데이터로 시스템이 자기 프로세스를 처리한다는 것을 확인하는 단계입니다. SIT처럼 저는 UAT도 여러 라운드로 계획해, 한 라운드의 수정 사항을 다음 라운드에서 다시 테스트합니다.

UAT에는 최소 6~8주가 필요합니다. 현업 테스터는 평소 업무와 병행해서 테스트하며, 한 라운드 이상을 소화할 시간이 필요합니다. 스크립트, 라운드, 승인은 SAP 사용자 인수 테스트 가이드에서 자세히 다룹니다.

회귀 테스트

모든 수정, 트랜스포트, 릴리스는 이미 통과한 무언가를 깨뜨릴 수 있습니다. 회귀 테스트는 프로젝트 기간과 Go-Live 이후 모두, 변경이 있을 때마다 중요한 프로세스를 다시 실행합니다.

SAP 자료는 회귀 테스트를 주로 Run 단계, 릴리스 업그레이드 이후에 둡니다. 하지만 프로젝트에서는 더 일찍 필요합니다. 접근 방식, 영향 분석, 환경 구성은 SAP 회귀 테스트 가이드에 정리했습니다.

모의 전환과 컷오버 리허설

브라운필드 전환에서는 컷오버 전에 모의 전환을 세 번 계획합니다. 각 모의 전환은 프로세스만이 아니라 전환 자체, 소요 시간, 대사까지 테스트합니다.

마지막 리허설은 실제 당일 밤처럼 진행해야 합니다. 같은 순서, 같은 사람, 같은 체크리스트입니다. 이 실행들이 계획의 어디에 들어가는지는 S/4HANA 마이그레이션 일정과 프로젝트 계획에서 보여 드립니다.

가장 중요한 책임 결정은 하나입니다. 사용자 인수 테스트의 책임은 현업에 있습니다. 시스템 통합업체도 IT도 아닙니다.

통합업체는 스크립트를 준비하고 결함을 수정할 수 있습니다. 하지만 그 프로세스가 작동한다고 확인할 수 있는 사람은 귀사의 재무 결산, Order to Cash, 공장을 실제로 운영하는 사람들뿐입니다.

SAP의 지침도 같은 방향입니다. 파트너의 구성 전문가가 테스트 케이스를 만들고, 고객의 현업 부서 전문가가 UAT를 수행하고 결과를 기록합니다.

사이클별 책임을 저라면 다음과 같이 나눕니다.

사이클	책임자	수행자	승인자
단위 및 스트링 테스트	빌드 팀 리드	컨설턴트와 개발자	기능 리드와 기술 리드
SIT 라운드	테스트 매니저	컨설턴트, 이후 라운드부터 키 유저 합류	테스트 매니저와 프로세스 오너
UAT 라운드	이름이 지정된 프로세스 오너를 통한 현업	키 유저와 현업 테스터	프로세스 오너, 이어서 스폰서
회귀 테스트	테스트 매니저	테스트 팀, 물량이 정당화하면 자동화	테스트 매니저와 변경 위원회
모의 전환과 리허설	컷오버 리드	기술, 데이터, 기능 팀	컷오버 리드, 데이터 리드, 스폰서

전략 문서에는 역할이 아니라 이름을 적으십시오. ‘재무 프로세스 오너’는 역할일 뿐이고, 승인하기로 동의한 특정 인물이어야 책임자입니다.

진입 기준은 성공할 수 없는 상태에서 사이클이 시작되는 것을 막습니다. 종료 기준은 달력이 그렇다고 해서 사이클이 끝나는 것을 막습니다.

아무도 마감 압박을 받지 않는 Realize 시작 전에 두 가지를 모두 작성하십시오. 이 기준이 ‘준비되지 않았다’고 말할 수 있는 책임자를 가진 공식 게이트가 되는 방법은 SAP 품질 게이트 가이드에서 설명합니다.

아래 표는 그대로 베낄 표준이 아니라 상황에 맞게 조정할 지침입니다. 비율과 결함 한도는 스폰서와 함께 정하고 전략 문서에 기록하십시오.

사이클	진입 기준	종료 기준
단위 및 스트링 테스트	설계 승인 완료, 테스트 대상 항목의 구성과 개발 완료	모든 항목 테스트 및 문서화 완료, 결함은 수정되었거나 SIT 대상으로 기록됨
SIT 라운드	범위 내 프로세스의 단위 테스트 완료, 테스트 환경 구축 및 인터페이스 연결, 테스트 데이터 로드, 스크립트 검토 완료	합의된 비율의 스크립트 실행 및 통과, 미해결 치명적 결함 없음, 미해결 하위 등급 결함마다 책임자와 수정 일자 지정
UAT 라운드	SIT 종료 기준 충족, 현업 테스터 지정 및 본업에서 차출, 프로세스 오너의 스크립트 검토, 테스트 시스템 교육 완료	범위 내 모든 프로세스를 현업 사용자가 실행, 미해결 치명적 결함 없음, 프로세스 오너가 각자의 프로세스에 승인
회귀 테스트	이관할 변경, 수정 묶음 또는 릴리스 준비, 영향받는 프로세스에 대한 회귀 테스트 팩 합의	회귀 테스트 팩 통과, 실패 항목은 변경이 이관되기 전에 수정 및 재테스트
모의 전환 또는 리허설	운영 시스템 복사본 확보, 컷오버 체크리스트와 런북 초안 작성, 대사 규칙 합의	계획된 시간 안에 전환 또는 로드 완료, 데이터 리드의 대사 승인, 교훈을 반영한 체크리스트 갱신
Go-Live	이전 모든 종료 기준 충족, 컷오버 체크리스트 사전 합의	체크리스트의 모든 항목 완료 및 승인, 스폰서가 Go/No-Go 결정 기록

이 표가 작동하려면 두 가지 원칙이 필요합니다. 모든 기준은 예 또는 아니오로 답이 나와야 하고, 모든 종료에는 이름이 지정된 승인자가 있어야 합니다.

사이클이 종료 기준을 충족하지 못했는데도 현업이 다음으로 넘어가기를 원한다면 서면 결정으로 남기십시오. 위험을 수용한 사람과 이월된 결함을 명시하십시오.

테스트 전략 문서는 테스트 매니저가 Prepare 또는 Explore 초반에 작성하고 스폰서가 승인합니다. 프로세스 오너가 끝까지 읽을 수 있을 만큼 짧게 유지하십시오.

제가 기대하는 섹션은 다음과 같습니다.

1. 범위와 목표. 어떤 프로세스, 법인, 인터페이스, 보고서를 테스트하고, 무엇을 명시적으로 제외하는지.
2. 테스트 유형과 사이클. 단위, 스트링, SIT 라운드, UAT 라운드, 회귀, 성능, 데이터 마이그레이션 테스트, 모의 전환과 각각의 라운드 수 및 근거.
3. 일정과 공수. SAP Activate 계획 안에서 각 사이클의 날짜, UAT에 최소 6~8주 배정, 테스트 비중 약 35%를 기준으로 잡은 공수 예산.
4. 역할과 책임. 위의 책임 표에 이름을 넣은 것.
5. 진입 및 종료 기준. 사이클마다 한 세트, 각각의 승인자 포함.
6. 환경. 어떤 시스템을 어떤 사이클에 쓰는지, 어떻게 리프레시하는지, 프로젝트 변경을 운영 지원 변경과 어떻게 분리하는지.
7. 테스트 데이터. 데이터를 어디서 가져오는지, 어떻게 마스킹하는지, 라운드 사이에 어떻게 리프레시하는지. SAP 테스트 데이터 관리 가이드에서 자세히 다룹니다.
8. 결함 관리. 심각도 정의, 분류 회의 주기, 우선순위 결정권자, 심각도별 목표 수정 시간.
9. 도구. 테스트 케이스, 결과, 결함, 승인을 어디에 보관하는지, 단일 기록 시스템으로.
10. 자동화 접근 방식. 어떤 테스트를 자동화하고 어떤 테스트를 수동으로 남기는지, 그 이유.
11. 보고. 주간 테스트 보고서에 무엇을 보여 주고 누가 받는지.
12. 컷오버와 Go-Live 기준. 컷오버 체크리스트, 이를 증명하는 리허설, Go/No-Go 결정권자.
13. 위험과 가정. 테스터 가용성, 환경 준비 일자, 데이터 준비 상태, 제3자 의존성.

도구로는 신규 프로젝트라면 SAP Cloud ALM이 기본입니다. SAP는 SAP Cloud ALM에 별도 라이선스가 없다고 밝히고 있습니다. Enterprise Support에 포함되어 있으며, 테스트 관리 앱에 공식 테스트 케이스, 실행, 결과를 보관합니다.

SAP Solution Manager 7.2는 아직 많은 프로젝트에서 쓰이지만 메인스트림 유지보수가 2027년 말에 종료됩니다. 자동화용으로 SAP는 Cloud ALM과 함께 작동하는 SAP Test Automation by Tricentis를 판매합니다. 더 넓은 선택지는 SAP 테스트 도구 비교에서 다룹니다.

제가 가장 자주 보는 테스트 실패는 UAT와 SIT에서 테스트가 충분하지 않은 것입니다.

흔한 경로는 이렇습니다. 빌드가 늦어지고, Go-Live 날짜는 고정되어 있고, 테스트 사이클이 계획의 끝에 있다는 이유로 그 몇 주가 테스트에서 빠집니다.

이를 일으키는 패턴과 각각의 대응은 다음과 같습니다.

1. 단위 테스트가 끝나기 전에 SIT가 시작됩니다. 첫 SIT 라운드가 단위 테스트 라운드가 되어 버립니다. 진입 기준을 지키십시오.
2. UAT를 2~3주로 계획합니다. 현업 사용자는 그 기간에 본업과 병행해 제대로 테스트할 수 없습니다. 최소 6~8주를 계획하고 테스터를 본업에서 차출하십시오.
3. 통합업체가 현업 대신 UAT를 수행합니다. 스크립트는 통과하고, 현업은 Go-Live 이후에 공백을 발견합니다. UAT 책임은 프로세스 오너에게 두십시오.
4. 테스트를 작은 예산 항목으로 잡습니다. 테스트가 공수의 약 35%인데 그 일부만 예산으로 잡으면 가장 먼저 잘려 나갑니다.
5. 종료 기준을 사이클 도중에 작성합니다. 결국 팀이 달성한 결과에 맞춰지게 됩니다. Realize 전에 작성하십시오.
6. Go-Live를 체크리스트가 아니라 자신감으로 결정합니다. 무엇을 합의했는지 아무도 보여 줄 수 없으니, 무엇이 빠졌는지도 아무도 말할 수 없습니다.

마지막 항목은 제가 반드시 고집하는 부분입니다. 제 Go-Live 기준은 현업, IT, 통합업체와 사전에 합의한 상세한 컷오버 체크리스트입니다.

체크리스트에는 기술 작업, 데이터 로드, 대사, 현업 검증, 인터페이스 전환, 사용자 접근 권한, Go/No-Go 판단 지점이 들어갑니다. 완료되고 승인되지 않은 항목이 있다면 날짜가 언제든 프로젝트는 준비된 것이 아닙니다.

Realize가 시작되기 전에 테스트 매니저에게 테스트 전략 문서를 요청하고 위의 구성과 대조해 보십시오. UAT 책임자가 이름으로 지정되어 있지 않거나, UAT 기간이 6~8주보다 짧거나, 사이클별 진입 및 종료 기준이 없다면 그것부터 고치십시오.

테스트 전략이나 Go-Live 체크리스트에 대한 독립적인 검토가 필요하시면 제가 도와드리고 있습니다. 여기에서 연락하실 수 있습니다.

S/4HANA 테스트 전략이란 무엇입니까?

어떤 테스트 사이클을 어떤 순서로 실행할지, 각 사이클의 책임자와 승인자가 누구인지, 어떤 증거가 있어야 프로젝트가 다음 사이클로 넘어갈 수 있는지를 정하는 계획입니다. S/4HANA 프로젝트에서는 보통 단위 및 스트링 테스트, SIT 라운드, UAT 라운드, 회귀 테스트, 데이터 마이그레이션 테스트, 컷오버 리허설을 다룹니다.

S/4HANA 프로젝트에서 테스트는 얼마나 비중을 차지합니까?

제가 계획하는 프로젝트에서 테스트는 프로젝트 공수의 약 35%를 차지합니다. 처음부터 그 수준으로 예산을 잡으십시오. 예산이 부족한 테스트는 빌드가 늦어질 때 가장 먼저 잘려 나갑니다.

S/4HANA 프로젝트에서 UAT는 얼마나 걸려야 합니까?

최소 6~8주입니다. 현업 테스터는 평소 업무와 병행해 UAT를 수행하며, 첫 라운드의 수정 사항을 다시 테스트하려면 한 라운드 이상을 소화할 시간이 필요합니다.

SAP 사용자 인수 테스트는 누가 책임져야 합니까?

이름이 지정된 프로세스 오너를 통해 현업이 책임져야 합니다. 시스템 통합업체는 스크립트를 준비하고, 환경을 관리하고, 결함을 수정할 수 있지만, 시스템이 자신에게 맞게 작동한다고 확인할 수 있는 사람은 그 프로세스를 운영하는 사람들뿐입니다.

SAP 테스트에서 진입 기준과 종료 기준이란 무엇입니까?

진입 기준은 사이클을 시작하기 전에 갖춰야 할 조건으로, 단위 테스트 완료, 환경 구축, 테스트 데이터 로드 같은 것입니다. 종료 기준은 사이클을 끝내기 전에 충족해야 할 조건으로, 스크립트 실행, 미해결 치명적 결함 없음, 프로세스 오너 승인 같은 것입니다. 각 기준은 예 또는 아니오로 답이 나와야 하고 이름이 지정된 승인자가 있어야 합니다.

S/4HANA Go-Live 체크리스트에는 무엇이 들어가야 합니까?

기술 컷오버 작업, 데이터 로드와 대사, 현업 검증, 인터페이스 전환, 사용자 접근 권한, Go/No-Go 판단 지점입니다. 사전에 합의하고, 모의 전환이나 최종 리허설에서 연습하고, 모든 항목이 완료되고 승인되었을 때만 Go-Live하십시오.