SAP 테스트 자동화: 어디서 시작하고 언제 효과가 나는가

SAP 테스트 자동화는 반복해서 실행하는 SAP 테스트, 주로 회귀 테스트를 사람이 아니라 도구가 실행하도록 바꾸는 것입니다. 광범위하게 반복 테스트해야 하는 테스트 케이스가 많을 때 효과가 나고, 그보다 적다면 수동 테스트로 충분합니다.

제가 S/4HANA 프로젝트에서 쓰는 원칙입니다. 제 경험상 테스트는 프로젝트 공수의 약 35%를 차지합니다. 그래서 테스트를 할지 말지는 애초에 질문이 아닙니다. 그 공수 중 어느 부분을 도구가 맡아야 하는지가 질문입니다.

자동화가 단위 테스트, 통합 테스트, 인수 테스트, 성능 테스트와 어떻게 함께 돌아가는지는 SAP 테스트 완전 정리부터 보십시오. 이 글에서는 어디서 시작할지, 언제 효과가 나는지, 프레임워크, 그리고 SAP Cloud ALM, Solution Manager, Tricentis가 무엇을 제공하는지 다룹니다.

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

이유는 비용 구조에 있습니다. 자동화 테스트는 수동으로 한 번 실행하는 것보다 구축 비용이 더 들고, 프로세스나 화면이나 데이터가 바뀔 때마다 유지보수가 필요합니다. 그 비용은 반복을 통해서만 회수됩니다.

SAP 프로젝트에서 반복은 예측 가능한 곳에서 나옵니다.

1. 트랜스포트. 품질 시스템으로 옮겨지는 모든 변경은 어제까지 작동하던 무언가를 깨뜨릴 수 있습니다.
2. SAP 릴리스와 서포트 패키지. 온프레미스와 프라이빗 클라우드의 업그레이드, 그리고 SAP S/4HANA Cloud Public Edition의 정기 업그레이드입니다.
3. 반복되는 테스트 라운드. 통합 테스트(SIT)는 같은 엔드투엔드 흐름을 여러 라운드에 걸쳐 실행합니다.
4. 롤아웃 웨이브. 글로벌 템플릿은 국가나 회사 코드마다 다시 테스트됩니다.
5. 데이터 비중이 큰 검증. 가격, 세금, 계정 결정처럼 데이터만 바뀌는 조합이 많은 경우입니다.

이 중 어느 것에도 해당하지 않는다면 도구는 절약하는 것보다 더 많은 비용을 들게 합니다.

테스트 유형별로 작업을 어떻게 나눌지 표로 정리했습니다.

테스트 유형	자동화 여부	이유
Order to Cash, Procure to Pay, Record to Report 같은 핵심 프로세스의 회귀 테스트	예, 가장 먼저	모든 트랜스포트와 모든 릴리스 후에 실행됨
SIT 라운드	일부	안정된 흐름은 자동화하고, 새롭거나 바뀌는 시나리오는 수동으로 유지
사용자 인수 테스트(UAT)	드물게	프로세스가 자신에게 맞는지는 현업 사용자가 판단하며, 스크립트는 그 판단을 할 수 없음
탐색적 테스트와 네거티브 테스트	아니요	아무도 스크립트로 만들지 않은 것을 사람이 찾아내는 데 가치가 있음
성능과 부하	예, 부하 도구로	다수의 동시 사용자는 수작업으로 만들어 낼 수 없음
일회성 데이터 마이그레이션 검증	대개 아니요	같은 로드가 모의 실행마다 반복되지 않는 한 대사 보고서가 더 적합함

Decide

이 SAP 테스트를 자동화해야 할까요

테스트 케이스가 많고 모든 변경이나 릴리스 후에 반복됨

→자동화합니다

테스트 케이스가 적거나 한두 번만 실행됨

→수동으로 테스트합니다

프로세스 설계가 아직 바뀌는 중

→안정될 때까지 기다린 뒤 결정합니다

실망스러운 자동화는 대개 너무 넓게 시작한 경우입니다. 설계 단계에서 모든 것을, 결과를 책임지는 사람 없이 자동화하려 한 것입니다. 저라면 다음 순서를 따릅니다.

1. 현업이 절대 깨져서는 안 되는 프로세스를 고릅니다. 월 마감, 대금 청구, 지급, 그리고 여러 사이트에 롤아웃되는 모든 것이 있으면 좋은 보고서보다 먼저입니다.
2. 먼저 수동으로 테스트를 실행합니다. 도구는 이미 수동으로 작동하는 테스트를 자동화할 뿐, 테스트를 설계해 주지는 않습니다.
3. 설계가 안정될 때까지 기다립니다. Explore나 Realize 초반에 자동화하면 설계 결정이 바뀔 때마다 테스트를 다시 만들어야 합니다.
4. 작은 회귀 테스트 팩을 만듭니다. 핵심 프로세스를 엔드투엔드로 다루고, 품질 시스템으로 들어가는 모든 트랜스포트마다 이 팩을 실행합니다.
5. 유지보수 책임자를 지정합니다. 화면, 역할, 데이터가 바뀔 때 누군가는 테스트를 고쳐야 합니다. 그렇지 않으면 몇 번의 릴리스 안에 팩이 쓸모없어집니다.
6. 반복이 정당화하는 곳에서만 커버리지를 늘립니다. 커버리지 목표 때문이 아니라 자주 실행될 테스트일 때 추가합니다.

프로젝트와 일상 운영을 분리하십시오

프로젝트 기간 동안 저는 랜드스케이프를 두 개로 분리해 운영합니다. 하나는 프로젝트용, 하나는 일상 운영(BAU)용입니다. 그러면 운영 지원 변경과 프로젝트 변경을 따로 테스트할 수 있습니다.

이는 자동화에서 중요합니다. 회귀 테스트가 실패했을 때 조사할 변경의 출처가 두 개가 섞여 있는 것이 아니라 하나여야 합니다. 두 랜드스케이프 방식과 영향 분석은 SAP 회귀 테스트 가이드에서 더 깊이 다룹니다.

저는 여러 프로젝트에서 Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath, LoadRunner를 직접 쓰거나 팀이 쓰도록 했습니다. 이 글에서 순위를 매기지는 않습니다. 올바른 선택은 귀사의 랜드스케이프, 지원 계약, 그리고 누가 테스트를 유지보수할지에 달려 있습니다.

SAP가 이미 제공하는 것부터 확인하십시오. 일부는 이미 비용을 내고 있을 수 있습니다.

SAP Cloud ALM

SAP Cloud ALM은 테스트 관리 계층입니다. 프로세스와 요구사항을 기준으로 수동 테스트와 자동화 테스트를 계획하고, 실행하고, 추적합니다. SAP Enterprise Support, Product Support for Large Enterprises 또는 해당 클라우드 구독을 보유한 고객은 테넌트 하나를 프로비저닝할 수 있습니다(SAP usage rights).

Cloud ALM 자체가 자동화 테스트를 실행하지는 않습니다. SAP는 Cloud ALM에 자체 개발한 자동화 엔진이 없으며 ALM 플랫폼은 서드파티 테스트 자동화에 열려 있다고 밝히고 있습니다(SAP Support, test automation).

SAP 설정 가이드에는 기본 제공 통합과 다른 공급업체를 위한 공개 Test Automation API가 설명되어 있습니다(SAP Help Portal). Panaya와 UiPath는 자동화 테스트 케이스를 위한 Cloud ALM 통합을 문서화하고 있습니다. Worksoft는 통합 대상에 Cloud ALM과 Solution Manager를 올려 두었고, OpenText는 클라우드 성능 테스트 제품용 Cloud ALM 통합을 제공합니다.

Tricentis Test Automation for SAP와 SAP Test Automation by Tricentis

무엇이든 구매하기 전에 사용 권한부터 확인하십시오. SAP는 SAP Enterprise Support, Enterprise Support cloud editions, Product Support for Large Enterprises에 Cloud ALM과 통합된 Tricentis Test Automation for SAP 기간 라이선스를 제공합니다. 현재 기한은 2028년 12월 31일까지입니다(SAP usage rights).

제한은 빡빡합니다. 지정 사용자 5명, 달력 기준 월 500회 테스트 실행, 고객이 관리하는 실행 에이전트 5개, 결과 보존 12개월입니다. 운영 중인 비즈니스 프로세스를 자동화하는 데는 쓸 수 없습니다. 프로젝트 규모의 도구가 아니라 시작하기 위한 수단으로 보십시오.

SAP Test Automation by Tricentis는 유료 상위 단계입니다. SAP가 솔루션 확장으로 판매하고 지원하는 SaaS 제품이며 SAP와 서드파티 애플리케이션을 다룹니다. Cloud ALM에 포함된 Tricentis 기능의 한도가 부족해지면 이를 확장합니다.

SAP Solution Manager

Solution Manager 7.2의 메인스트림 유지보수는 2027년 말까지입니다. SAP Business Suite 7의 연장 유지보수를 선택한 고객은 2030년 말까지 Solution Manager 연장 유지보수를 받습니다. 연장 유지보수는 테스트 스위트를 포함한 제한된 영역만 다룹니다(SAP Support).

Solution Manager 자체의 자동화 기능인 Component-Based Test Automation(CBTA)은 SAP 클라우드 제품으로 확장되지 않습니다. Solution Manager 통합용 Tricentis 라이선스는 현재 2027년 12월 31일까지입니다. 이미 Solution Manager를 운영하고 있다면 랜드스케이프가 이전될 때까지 유지하되, 새로운 자동화를 Solution Manager 중심으로 구축하지는 마십시오.

SAP S/4HANA Cloud Public Edition

Public Edition에는 자체 Test Automation Tool이 있습니다. SAP의 지침은 파트너가 각 프로세스를 구성하면서 테스트 자동화 스크립트를 만들거나 갱신해 두라는 것입니다. 그래야 업그레이드 때 테스트 시스템에서 실행할 수 있습니다(SAP Learning).

고객이 동의하면 SAP는 수정하지 않은 표준 프로세스에 대해 업그레이드 후 테스트를 실행합니다. Go-Live 이후 커스터마이징한 부분의 회귀 테스트는 고객이 자체 자동화 스크립트로 책임져야 합니다.

위에서 언급한 도구를 선호도가 아니라 역할 기준으로 표에 정리했습니다.

도구	주요 역할	적합한 곳
SAP Cloud ALM	테스트 관리와 오케스트레이션	신규 프로젝트, 수동 테스트와 자동화 테스트를 프로세스에 연결
SAP Solution Manager	테스트 관리, 온프레미스	이미 운영 중인 랜드스케이프, 메인스트림 유지보수는 2027년에 종료
Tricentis Tosca와 SAP Test Automation by Tricentis	모델 기반 자동화	SAP와 비SAP 애플리케이션, SAP가 재판매하고 지원
Worksoft	코드 없는 프로세스 자동화	Cloud ALM, Solution Manager와 통합
Panaya	테스트 관리와 코드 없는 자동화	자동화 테스트를 위한 Cloud ALM 통합
UiPath	Test Manager를 갖춘 자동화 플랫폼	자동화 테스트 케이스를 위한 Cloud ALM 통합
OpenText LoadRunner	성능 및 부하 테스트	Go-Live 전 동시성 및 물량 테스트

Xray for Jira를 포함한 더 깊은 비교는 SAP 테스트 도구 가이드를 참고하십시오. 부하 테스트는 IT 리더를 위한 SAP 성능 테스트를 참고하십시오.

도구보다 중요한 것은 테스트를 어떻게 만들고 누가 유지보수하느냐입니다. 대부분의 SAP 자동화는 다음 방식 중 하나에 속합니다.

1. 모델 기반. 화면과 API를 스캔해 재사용 가능한 모듈로 만든 뒤 테스트 케이스로 조립합니다. 기능 컨설턴트가 코드 없이 만들고 읽을 수 있습니다.
2. 코드 없는 프로세스 캡처. 비즈니스 프로세스 단계를 기록해 재사용 가능한 테스트로 바꿉니다. 키 유저가 회귀 테스트 팩 구축을 돕는 팀에 맞습니다.
3. 코드 기반. 테스트 엔지니어가 프로그래밍 프레임워크로 테스트를 작성합니다. 개발팀이 소유한 Fiori 앱과 API에 맞으며, 유지보수에 개발자가 필요합니다.
4. 테스트 모듈을 갖춘 RPA 플랫폼. 비즈니스 자동화와 테스트 자동화를 하나의 플랫폼에서 하는 방식으로, 이미 운영 중이라면 유용합니다.
5. SAP가 제공하는 자동화 스크립트. Public Edition에서 Test Automation Tool과 함께 제공되는 테스트 자동화 스크립트를 귀사의 데이터와 변경에 맞게 조정합니다.

어떤 방식을 고르든 테스트가 살아남을지는 세 가지 설계 선택이 결정합니다.

1. 가능하면 API 수준에서 테스트합니다. API 테스트는 화면을 클릭해 나가는 테스트보다 덜 자주 깨집니다.
2. 테스트 데이터를 초기화할 수 있게 유지합니다. 지난 실행에서 소진된 데이터에 의존하는 테스트는 엉뚱한 이유로 실패합니다.
3. 공유 모듈로 구축합니다. 화면이 바뀌면 그 화면을 거치는 모든 테스트가 아니라 모듈 하나만 고치면 됩니다.

자동화된 회귀 테스트 팩은 프로젝트 산출물이 아니라 하나의 제품입니다. 책임자, 예산 항목, 변경 프로세스 안의 자리가 필요합니다.

변경 관리와 연결하십시오. 회귀 테스트 팩을 실행하고 그 결과를 테스트 관리 도구에 기록하기 전에는 어떤 트랜스포트도 운영 환경으로 옮기지 않습니다. 테스트 결과를 Go/No-Go 결정의 일부로 만드는 방법은 SAP 품질 게이트에 관한 제 글에 정리했습니다.

SAP의 릴리스 주기도 계획에 넣으십시오. Public Edition 업그레이드는 귀사가 아니라 SAP의 일정에 따라 오고, 프라이빗 클라우드와 온프레미스 시스템에도 서포트 패키지와 업그레이드가 필요합니다. 하나하나가 회귀 테스트 실행이며, 바로 그곳에서 자동화가 비용을 회수합니다.

불안정한 테스트는 고치고, 아무도 실행하지 않는 테스트는 폐기하고, 사람들이 결과를 신뢰할 수 있을 만큼 팩을 작게 유지하십시오.

자동화는 테스트 계획 안에 있어야 합니다. 사이클, 진입 및 종료 기준, 역할이 먼저입니다. 이 내용은 S/4HANA 테스트 전략에 정리했습니다.

모든 트랜스포트와 모든 SAP 릴리스 후에 다시 테스트할 비즈니스 프로세스를 나열하십시오. 그 뒤에 있는 테스트 케이스 수와 각각이 1년에 몇 번 실행될지 세어 보십시오.

수가 많고 실행이 반복된다면 자동화의 근거가 있습니다. 그다음 누군가 데모를 보여 주기 전에 귀사의 SAP 지원 계약에 이미 무엇이 포함되어 있는지 확인하십시오.

테스트 자동화 계획이나 공급업체 제안서에 대해 독립적인 의견이 필요하시면 제가 도와드리고 있습니다. 여기에서 연락하실 수 있습니다.

SAP 테스트 자동화란 무엇입니까?

수동으로 실행하던 SAP 테스트, 주로 변경과 업그레이드 후의 회귀 테스트를 도구로 실행하는 것입니다. SAP Cloud ALM 같은 테스트 관리 도구가 테스트를 계획하고 기록하며, 자동화 도구가 테스트를 실행합니다.

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

모든 트랜스포트, 릴리스, 롤아웃 웨이브 후의 회귀 테스트처럼 광범위하게 반복 테스트해야 하는 테스트 케이스가 많을 때입니다. 그보다 적다면 수동 테스트로 충분합니다. 프로세스 설계가 안정될 때까지 기다리십시오. 그렇지 않으면 설계가 바뀔 때마다 테스트를 다시 만들게 됩니다.

SAP Cloud ALM은 테스트 자동화를 합니까?

자동화 테스트를 관리하고 실행을 트리거하지만 자체 자동화 엔진은 없습니다. Tricentis Test Automation for SAP, S/4HANA Cloud Public Edition의 Test Automation Tool과 통합되며, 공개 Test Automation API를 통해 다른 공급업체와도 통합됩니다.

SAP Test Automation by Tricentis란 무엇입니까?

SAP가 솔루션 확장으로 판매하고 지원하는 SaaS 테스트 자동화 제품으로, SAP와 서드파티 애플리케이션을 다룹니다. SAP Enterprise Support에 포함된 입문용 Tricentis Test Automation for SAP 라이선스를 확장합니다. 이 라이선스는 지정 사용자 5명과 월 500회 테스트 실행으로 제한됩니다.

SAP 사용자 인수 테스트를 자동화할 수 있습니까?

드물게만 가능하며, 그것이 목표가 되어서는 안 됩니다. UAT는 현업 사용자가 시스템이 자신에게 맞는지 판단하기 위해 존재하고, 스크립트는 그 판단을 할 수 없습니다. 주변의 반복적인 회귀 테스트를 자동화하고 인수 결정은 사람에게 맡기십시오.

테스트 자동화에 SAP Solution Manager를 계속 써도 됩니까?

이미 랜드스케이프를 Solution Manager로 운영하고 있는 경우에만 그렇습니다. Solution Manager 7.2의 메인스트림 유지보수는 2027년에 종료되며, CBTA 자동화는 SAP 클라우드 제품으로 확장되지 않습니다. 새로운 자동화는 Cloud ALM 중심으로 계획하십시오.