SAP 테스트 완전 정리: 유형, 단계, 책임자

SAP 테스트는 구성된 SAP 시스템이 귀사의 데이터와 귀사의 물량으로 비즈니스 프로세스를 올바르게 처리한다는 것을 증명하는 작업입니다. Go-Live 전에 한 번, 그리고 이후 시스템이 바뀔 때마다 해야 합니다. S/4HANA 프로젝트에서는 단위 테스트, 통합 테스트(SIT), 사용자 인수 테스트(UAT), 회귀 테스트, 성능 테스트, 컷오버 리허설의 여섯 가지 유형을 다룹니다.

유형마다 답하는 질문이 다르고, 어느 하나가 다른 것을 대신하지 못합니다. 제 경험상 테스트는 프로젝트 공수의 약 35%를 차지합니다. 그래서 빌드 끝에 몇 주를 붙이는 식이 아니라 자체 계획과 예산, 책임자를 가져야 합니다.

이 글은 개요입니다. 유형별 상세 가이드는 아래 각 섹션에 링크해 두었습니다.

SAP 시스템은 구성, 마스터 데이터, 커스텀 코드, 인터페이스가 함께 맞물려 돌아가는 구조입니다. 한 곳을 바꾸면 다른 곳의 프로세스가 깨질 수 있고, 아무도 손대지 않은 모듈에서 문제가 생기는 경우도 많습니다.

그래서 SAP 테스트는 화면이 아니라 비즈니스 프로세스를 중심으로 구성합니다. Order to Cash, Procure to Pay, Record to Report는 여러 모듈에 걸쳐 있습니다. 트랜잭션 하나에서 멈추는 테스트로는 증명되는 것이 거의 없습니다.

테스트는 Go-Live로 끝나지도 않습니다. 운영 중 변경, SAP 릴리스, 새로운 롤아웃이 모두 시스템을 바꾸기 때문에 같은 원칙이 Run 단계까지 이어집니다.

제가 S/4HANA 프로젝트에서 계획하는 여섯 가지 유형입니다. 아래 표에 각 유형이 무엇을 증명하는지, 언제 수행하는지, 누가 책임져야 하는지를 정리했습니다.

테스트 유형	증명하는 것	SAP Activate에서의 위치	책임자
단위 테스트	각 구성 항목, 프로그램, 개선 사항이 단독으로 작동함	Realize, 각 빌드 스프린트 안에서	기능 및 기술 컨설턴트
통합 테스트(SIT)	실제와 같은 데이터로 전체 프로세스가 모듈과 인터페이스를 넘나들며 실행됨	Realize, 빌드가 안정된 뒤 여러 라운드로	프로젝트 테스트 리드, 프로세스 오너와 함께
사용자 인수 테스트(UAT)	현업이 실제 시나리오를 시스템에서 수행할 수 있음	Realize 후반, Deploy 전	현업
회귀 테스트	변경 후에도 이전에 작동하던 기능이 여전히 작동함	Realize부터, 이후 Run에서 모든 릴리스마다	테스트 리드, 물량이 정당화하면 자동화와 함께
성능 테스트	많은 사용자와 운영 수준의 물량을 동시에 감당함	Realize, Go-Live 전에 완료	프로젝트 차원의 성능 리드, Basis와 함께
컷오버 리허설	Go-Live 순서, 데이터 로드, 소요 시간이 처음부터 끝까지 맞아떨어짐	Deploy	컷오버 매니저

SAP Activate 전반의 SAP 테스트

1. 01

   Prepare

   테스트 도구, 팀, 테스트 랜드스케이프를 준비합니다.

2. 02

   Explore

   Fit-to-Standard 결정을 내리는 동안 테스트 전략을 작성해 요구사항을 테스트 가능한 형태로 만듭니다.

3. 03

   Realize

   스프린트 안에서 단위 테스트를 하고, 빌드가 안정되면 SIT 라운드, 성능 테스트, UAT를 진행합니다.

4. 04

   Deploy

   합의된 체크리스트에 따라 컷오버 리허설을 한 뒤 Go-Live를 결정합니다.

5. 05

   Run

   모든 운영 변경, 업그레이드, 릴리스마다 회귀 테스트를 합니다.

단위 테스트

단위 테스트는 해당 항목을 만든 사람이 합니다. 기능 컨설턴트는 가격 조건을 확인하고, 개발자는 개선 사항이나 인터페이스 매핑을 확인합니다.

꼭 필요하지만 그것만으로는 충분하지 않습니다. 단위 테스트가 깨끗하게 통과해도 그 항목이 나머지 프로세스와 만났을 때 어떻게 되는지는 전혀 알 수 없습니다.

통합 테스트

SIT는 설계가 실제로 작동하는지 프로젝트가 확인하는 단계입니다. 판매 오더는 출하, 대금 청구, 회계, 보고까지 흘러가야 하고, 그 사이의 모든 인터페이스가 올바르게 전기되어야 합니다.

저는 SIT를 한 번의 실행이 아니라 여러 라운드로 계획합니다. 첫 라운드에서 발견한 결함을 수정하고, 다음 라운드에서 그 수정이 다른 곳을 깨뜨리지 않았는지 증명합니다. 라운드, 진입 기준, 종료 기준이 어떻게 맞물리는지는 S/4HANA 테스트 전략 가이드에 정리했습니다.

사용자 인수 테스트

UAT는 Go-Live 이후 일하는 방식을 시스템이 뒷받침하는지 현업이 확인하는 과정입니다. 시스템을 인수할 수 있는 주체는 현업뿐이므로, UAT는 시스템 통합업체가 아니라 현업의 몫입니다.

UAT에는 최소 6~8주가 필요합니다. 늦어진 빌드에 맞추려고 UAT를 줄이면 서류상으로는 승인을 받지만 운영에서 문제가 터집니다. 스크립트, 역할, 승인 절차는 SAP 사용자 인수 테스트 가이드에서 다룹니다.

회귀 테스트

회귀 테스트는 변경 후 이미 검증된 테스트를 다시 실행해 변경이 깨뜨린 부분을 찾아내는 작업입니다. 프로젝트가 길어지면 운영 지원 수정과 프로젝트 변경이 동시에 시스템을 통과합니다.

제 방식은 랜드스케이프를 두 개로 분리하는 것입니다. 하나는 프로젝트용, 하나는 일상 운영(BAU)용입니다. 그러면 운영 지원 변경과 프로젝트 변경을 따로 테스트할 수 있고, 한쪽이 다른 쪽의 결함을 가리지 않습니다. 두 랜드스케이프 방식, 업그레이드, 영향 분석은 SAP 회귀 테스트 가이드에서 다룹니다.

성능 테스트

성능 테스트는 반드시 Go-Live 전에 해야 합니다. 가장 중요한 것은 동시성 테스트, 즉 많은 사용자가 같은 순간에 트랜잭션을 실행하는 테스트입니다.

사용자 한 명에게는 정상인 트랜잭션이 이백 명에게는 타임아웃이 날 수 있습니다. 기능 테스트로는 절대 드러나지 않습니다. IT 리더를 위한 SAP 성능 테스트 가이드에서 부하, 스트레스, 소크 테스트와 인수 기준 작성법을 다룹니다.

컷오버 리허설

컷오버 리허설은 Go-Live 자체를 테스트합니다. 기술 작업 순서, 데이터 로드, 대사, 승인 절차를 소요 시간과 함께 점검합니다. 브라운필드 전환에서는 컷오버 전에 모의 전환을 세 번 계획합니다.

제가 반드시 요구하는 Go-Live 기준은 사전에 합의된 상세한 컷오버 체크리스트입니다. 체크리스트를 컷오버 주말에 작성하고 있다면, 그동안의 리허설은 진짜 리허설이 아니었던 것입니다.

제 경험상 테스트는 프로젝트 공수의 약 35%를 차지합니다. 테스트를 빌드와 Go-Live 사이의 짧은 공백 정도로 생각하는 스폰서는 이 수치에 놀랍니다.

공수는 여러 사람에게 나뉩니다. 컨설턴트는 단위 테스트를 하고, 테스트 팀은 SIT를 준비하고 실행하고, 현업 사용자는 UAT를 수행하고, Basis와 통합 팀은 성능 테스트와 컷오버 리허설을 지원합니다.

데이터 마이그레이션은 이와 나란히 진행되며 그 자체로 공수의 30~40%를 차지합니다. 테스트 라운드마다 운영 환경과 비슷한 마이그레이션 데이터가 필요하기 때문에 두 작업은 크게 겹칩니다.

제가 가장 자주 보는 테스트 실패는 단순히 SIT와 UAT에서 테스트가 충분하지 않은 것입니다. 빌드가 늦어지면 라운드가 잘려 나가는데 Go-Live 날짜는 그대로입니다. 제가 이끌거나 구해낸 21개 SAP 프로젝트를 통틀어 가장 큰 실수는 여전히 처음에 계획을 제대로 세우지 않는 것이고, 그 문제는 보통 테스트에서 가장 먼저 드러납니다.

테스트는 그 테스트가 사용하는 데이터만큼만 의미가 있습니다. 제 원칙은 마스킹한 데이터를 쓰되 운영 수준으로 쓰는 것입니다. 운영 규모의 물량과 실제와 같은 레코드를 쓰고, 개인 정보와 민감한 필드는 마스킹합니다.

작고 깨끗한 테스트 데이터는 중요한 문제를 가립니다. 레코드 몇천 건에서는 몇 초 만에 끝나는 보고서가 1년치 전기 데이터에서는 몇 시간씩 걸릴 수 있습니다.

환경도 데이터만큼 중요합니다. Prepare 단계에서 테스트 랜드스케이프를 계획하고, 라운드 사이에 어떻게 리프레시할지 정하고, 프로젝트 변경과 BAU 변경을 분리하십시오. 시스템 복사, 마스킹, 선택적 테스트 데이터는 SAP 테스트 데이터 관리 가이드에서 다룹니다.

자동화에 대한 제 원칙은 단순합니다. 광범위하게 반복 테스트해야 하는 테스트 케이스가 많다면 자동화합니다. 그보다 적다면 수동 테스트로 충분합니다.

자동화의 효과가 가장 먼저 나는 곳은 보통 회귀 테스트입니다. 변경할 때마다 같은 테스트를 실행하기 때문입니다. UAT는 대부분 수동으로 남습니다. UAT의 목적은 스크립트의 판단이 아니라 현업 사용자의 판단이기 때문입니다.

일찍 결정해야 하는 현실적인 이유도 있습니다. 자동화 테스트는 구축하고 유지하는 데 시간이 들기 때문에 여러 번 실행될 때만 투자가 회수됩니다. 어디서 시작하고 언제 효과가 나는지는 SAP 테스트 자동화 가이드에서 다룹니다.

도구는 테스트 관리, 기능 자동화, 성능 테스트의 세 그룹으로 나뉩니다. 제가 이끌었거나 함께 일한 팀은 Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath, LoadRunner를 사용했습니다.

각 그룹이 하는 일과 해당 제품은 다음과 같습니다.

도구 그룹	하는 일	팀이 흔히 쓰는 제품
테스트 관리	테스트 계획, 테스트 케이스, 실행 기록, 결함, 요구사항 추적성	SAP Cloud ALM, SAP Solution Manager, Panaya
기능 테스트 자동화	SAP와 비SAP 애플리케이션 전반에서 스크립트 기반 또는 모델 기반 테스트를 실행	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
성능 테스트	다수의 동시 사용자와 운영 수준의 물량을 시뮬레이션	OpenText LoadRunner, 현재 OpenText Professional Performance Engineering으로 판매

도구를 고르기 전에 알아 둘 만한 제품 정보가 몇 가지 있습니다.

1. SAP Cloud ALM은 SAP Enterprise Support 고객과 Enterprise Support, cloud editions가 포함된 클라우드 구독 고객에게 포함되어 있습니다(SAP Support). 테스트 관리 기능은 테스트 준비, 테스트 계획과 실행을 다루며 UAT용 수동 테스트 케이스도 포함합니다(SAP Learning).
2. SAP Solution Manager 7.2의 메인스트림 유지보수는 2027년 말에 종료됩니다. 테스트 스위트를 포함한 일부 기능에 대해서는 2030년 말까지 선택적 연장 유지보수가 제공됩니다(SAP Support).
3. SAP Test Automation by Tricentis는 SAP가 재판매하는 자동화 제품으로, SAP Cloud ALM과 통합되어 있으며 SAP와 서드파티 시스템을 위해 만들어졌습니다(SAP).
4. LoadRunner는 OpenText 제품입니다. LoadRunner Professional은 현재 OpenText Professional Performance Engineering이라는 이름이며 SAP GUI와 SAP Web 프로토콜을 지원합니다(OpenText).

새 프로젝트를 시작한다면 테스트 관리는 Solution Manager가 아니라 Cloud ALM으로 계획하십시오. 더 자세한 비교는 SAP 테스트 도구 가이드를 참고하십시오.

SAP Cloud ERP public edition(S/4HANA Cloud Public Edition)에서는 SAP가 자체 일정에 따라 모든 고객을 업그레이드합니다. SAP Learning에 따르면 업그레이드는 6개월마다, 현재는 2월과 8월에 이루어지고 그 사이에는 매달 새 기능이 제공됩니다(SAP Learning).

업그레이드 날짜를 고를 수 없으므로 회귀 테스트는 프로젝트가 아니라 고정된 일정 항목이 됩니다. 퍼블릭 클라우드 시스템에서 회귀 테스트를 일찍 자동화해야 하는 가장 강력한 이유입니다.

프라이빗 클라우드와 온프레미스에서는 업그레이드 시점을 직접 정합니다. 그래도 업그레이드마다 변경이 영향을 주는 프로세스에 맞춘 규모의 회귀 테스트 사이클이 필요합니다.

무엇보다 먼저 테스트를 자체 책임자와 예산을 가진 워크스트림으로 계획에 넣고, 규모는 전체 공수의 약 3분의 1로 잡으십시오. 그다음 UAT의 현업 책임자를 지정하고, 빌드 일정이 UAT를 밀어내기 전에 지금 바로 일정표에 6~8주를 확보하십시오.

측정 가능한 종료 기준으로 테스트 결과를 Go/No-Go 결정과 연결하십시오. 방법은 SAP 품질 게이트 가이드에 정리했습니다. 프로젝트가 이미 어려움에 처해 있다면 SAP 프로젝트 회복에 관한 제 글에서 무엇부터 고쳐야 하는지 다룹니다.

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

SAP 테스트란 무엇입니까?

SAP 테스트는 구성된 SAP 시스템이 귀사의 데이터와 물량으로 비즈니스 프로세스를 올바르게 처리한다는 것을 증명하는 작업입니다. S/4HANA 프로젝트에서는 단위 테스트, 통합 테스트, 사용자 인수 테스트, 회귀 테스트, 성능 테스트, 컷오버 리허설을 포함합니다. Go-Live 이후에도 모든 운영 변경과 릴리스마다 계속됩니다.

SAP 테스트의 유형에는 무엇이 있습니까?

주요 유형은 단위 테스트, 통합 테스트(SIT), 사용자 인수 테스트(UAT), 회귀 테스트, 성능 테스트, 컷오버 리허설의 여섯 가지입니다. 단위 테스트는 개별 항목을, SIT는 모듈과 인터페이스를 넘나드는 전체 프로세스를 확인하고, UAT는 현업이 시스템을 인수하는 과정입니다. 회귀 테스트, 성능 테스트, 컷오버 리허설은 각각 변경, 부하, Go-Live 자체로부터 시스템을 보호합니다.

SAP 사용자 인수 테스트는 얼마나 걸립니까?

UAT에는 최소 6~8주를 계획하십시오. 현업이 책임을 지고 실제 시나리오를 수행한 뒤 승인해야 합니다. UAT와 SIT에서 테스트가 충분하지 않은 것이 제가 가장 자주 보는 테스트 실패입니다.

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

제 경험상 테스트는 프로젝트 공수의 약 35%를 차지합니다. 단위 테스트, SIT 라운드, UAT, 회귀 테스트, 성능 테스트, 컷오버 리허설의 준비와 실행이 모두 포함됩니다. 데이터 마이그레이션이 이와 나란히 진행되며, 테스트 라운드마다 운영 환경과 비슷한 데이터가 필요합니다.

SAP 테스트는 자동화해야 합니까?

광범위하게 반복 테스트해야 하는 테스트 케이스가 많을 때 자동화하십시오. 보통은 회귀 테스트가 여기에 해당합니다. 그보다 적다면 수동 테스트로 충분합니다. UAT의 목적은 현업의 판단이므로 대부분 수동으로 남습니다.

SAP 테스트에는 어떤 도구를 사용합니까?

대부분의 프로젝트는 테스트 관리 도구, 자동화 도구, 성능 테스트 도구를 함께 씁니다. 흔한 선택은 테스트 관리에 SAP Cloud ALM 또는 Solution Manager, 자동화에 Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft 또는 UiPath, 성능에 OpenText LoadRunner입니다. Solution Manager의 메인스트림 유지보수가 2027년에 종료되므로 신규 프로젝트는 Cloud ALM으로 계획해야 합니다.