SAP 회귀 테스트: 업그레이드, 릴리스, 범위

SAP 회귀 테스트는 변경, 서포트 패키지, 새 릴리스가 이미 작동하던 비즈니스 프로세스를 깨뜨리지 않았음을 증명합니다. 영향 분석으로 범위를 정하고, 위험이 가장 큰 프로세스부터 실행하며, Go-Live 전에 한 번이 아니라 시스템이 바뀔 때마다 반복합니다.

회귀 테스트를 촉발하는 것은 트랜스포트, 업그레이드, 클라우드 릴리스입니다. SAP Cloud ERP public edition에서는 업그레이드 날짜를 SAP가 정하므로, 릴리스가 도착하기 전에 회귀 테스트 스위트가 준비되어 있어야 합니다.

회귀 테스트는 SAP 테스트 가이드에서 다루는 테스트 유형 중 하나입니다. 이 글에서는 무엇이 회귀 테스트를 촉발하는지, 범위를 어떻게 정하는지, 언제 자동화하는지, 그리고 프로젝트와 운영 지원이 서로의 작업을 깨뜨리지 않게 하는 방법을 다룹니다.

SAP는 통합 시스템입니다. 가격 조건 하나를 바꾸면 대금 청구가 깨질 수 있고, 판매 오더에 필드 하나를 추가하면 인터페이스가 멈출 수 있습니다. 서포트 패키지가 귀사가 의존하는 표준 프로그램을 바꿀 수도 있습니다.

회귀 테스트는 바뀌지 않아야 할 프로세스의 테스트를 다시 실행합니다. 기능 테스트는 새로운 것이 작동하는지를 묻고, 회귀 테스트는 나머지가 모두 여전히 작동하는지를 묻습니다.

회귀 테스트는 프로젝트 기간에만이 아니라 시스템의 전체 수명 동안 적용됩니다.

1. 트랜스포트. 개발에서 품질 시스템으로 옮겨지는 모든 변경은 그 변경이 닿는 프로세스에 회귀 위험이 됩니다.
2. 서포트 패키지와 feature pack. SAP의 수정 사항과 새 기능은 귀사의 구성 아래에 있는 표준 코드를 바꿉니다.
3. 릴리스 업그레이드. 새 릴리스로 이동하거나 귀사가 일정을 정하지 않은 클라우드 릴리스가 오면 훨씬 많은 것이 한꺼번에 바뀝니다.
4. 전환. ECC에서 S/4HANA로 전환하면 구성과 커스텀 코드가 그대로 유지되므로, 유지한 모든 것을 다시 테스트해야 합니다. 이것이 계획의 어디에 들어가는지는 ECC에서 S/4HANA로의 마이그레이션 가이드에 설명했습니다.
5. 통합과 확장. 연결된 시스템이나 side-by-side 확장이 바뀌면 SAP 트랜스포트가 전혀 없어도 SAP 쪽이 깨질 수 있습니다.

회귀 테스트 스위트는 새 기능을 위해 작성한 테스트와 분리해서 관리하십시오. 스위트는 Order to Cash, Procure to Pay, 월 마감처럼 현업이 절대 잃어서는 안 되는 프로세스의 안정된 라이브러리입니다.

온프레미스에서는 업그레이드 시점을 직접 정합니다. 클라우드 에디션에서는 SAP가 일정의 더 많은 부분을 정하고, 회귀 테스트는 정기적으로 돌아오는 일정상의 약속이 됩니다.

Public edition: 1년에 두 번 업그레이드

SAP Cloud ERP public edition(이전 명칭 S/4HANA Cloud Public Edition)은 1년에 두 번, 2월과 8월에 주요 업그레이드를 받습니다. 그 사이에 더 작은 기능 업데이트가 제공됩니다.

SAP는 테스트 시스템을 먼저 업그레이드하고 몇 주 뒤에 운영 시스템을 업그레이드합니다. 그 사이의 간격이 회귀 테스트 기간이며, 운영 시스템이 업그레이드되고 나면 두 번째 기회는 없습니다.

SAP의 업그레이드 후 테스트와 회귀 테스트에 관한 Cloud ALM 과정은 Cloud ALM에서 회귀 테스트 계획을 만들어 릴리스마다 재사용할 것을 권장합니다. Public edition에는 사전 제공 테스트 스크립트가 포함된 무료 테스트 자동화 도구도 있어 표준 프로세스는 출발점이 있습니다.

Private edition: 2년 릴리스 주기

RISE with SAP로 판매되는 private edition인 SAP Cloud ERP Private는 온프레미스 릴리스 주기를 따릅니다. SAP Learning에 따르면 2년마다 새 기본 릴리스가 나오고, 6개월마다 feature pack stack이 이어지며, 각 릴리스에는 7년간 메인스트림 유지보수가 제공됩니다.

메인스트림 유지보수를 유지하려면 최소 7년에 한 번은 업그레이드를 설치해야 하며, RISE에서는 1년에 한 번 업그레이드를 요청할 수 있습니다. 기술 업그레이드는 SAP가 수행하지만, 계획, 준비, 테스트는 여전히 고객이나 파트너의 일입니다.

이 구분은 예산에 중요합니다. 업그레이드 자체는 구독에 포함될 수 있지만, 그에 따르는 회귀 테스트는 포함되지 않습니다.

회귀 테스트를 촉발하는 요인을 표로 나란히 정리했습니다.

변경	빈도	날짜를 정하는 주체	회귀 테스트 실행이 다뤄야 하는 것
품질 시스템으로의 트랜스포트	매일 또는 매주	귀사 팀	변경된 오브젝트가 닿는 프로세스
Public edition 업그레이드	1년에 두 번, 2월과 8월	SAP	범위 내 모든 프로세스, 커스텀 로직 우선, 운영 시스템 업그레이드 전 기간 안에
Private edition feature pack stack	적용한다면 6개월마다	귀사, SAP 일정 안에서	사용 중인 변경된 표준 기능과 커스텀 코드
Private edition 릴리스 업그레이드	최소 7년에 한 번, RISE에서 요청 시 1년에 한 번까지	귀사, SAP와 함께	전체 스위트, 커스텀 코드, 통합
ECC에서 S/4HANA로의 전환	한 번	귀사	유지한 모든 것

변경할 때마다 전체 스위트를 실행하면 느리고 비쌉니다. 너무 적게 실행하면 결함이 빠져나가고, 그 공백은 운영 환경에서 드러납니다.

영향 분석은 그 사이에 있습니다. 무엇이 바뀌었는지와 실제로 무엇을 쓰고 있는지를 비교해 가장 위험한 프로세스와 오브젝트를 나열하므로, 회귀 테스트를 거기서부터 시작할 수 있습니다.

접하게 될 도구는 다음과 같습니다.

1. SAP Solution Manager. Test Suite의 일부인 Business Process Change Analyzer는 변경이 어떤 비즈니스 프로세스에 영향을 주는지 보여 줍니다. Scope and Effort Analyzer는 서포트 패키지나 enhancement package를 설치하기 전에 영향을 추정하며, SAP는 이를 계획 도구라고 부릅니다.
2. SAP Cloud ALM. Cloud ALM은 회귀 테스트 계획, 실행, 결함을 관리하고 자동화 도구와 연결됩니다. Public edition 업그레이드에서는 SAP의 Release Assessment and Scope Dependency 도구가 릴리스의 어떤 변경이 귀사의 범위에 영향을 주는지 보여 줍니다.
3. Tricentis LiveCompare. LiveCompare 문서에 따르면 테스트할 최소한의 고위험 오브젝트 집합을 찾아낸 뒤, 테스트 저장소와 대조해 테스트가 다루는 부분과 빠진 부분을 보고합니다. SAP는 이를 SAP Change Impact Analysis by Tricentis라는 이름으로 재판매하며, Tricentis Tosca와 통합됩니다.
4. Panaya. Panaya의 SAP 업그레이드 제품은 변경 영향 분석, 코드 수정, 테스트 관리, 자동화를 결합하며 S/4HANA 버전, feature pack stack, support package stack을 다룹니다.

Solution Manager 위에 무언가를 구축하기 전에 현재 상태를 확인하십시오. SAP Support에 따르면 Solution Manager 7.2의 메인스트림 유지보수는 2027년 말에 종료됩니다. Business Suite 7 연장 유지보수를 선택한 고객은 2030년 말까지 유지되며, SAP는 2027년 말 전에 Cloud ALM으로 이전할 것을 권장합니다.

영향 분석은 범위를 좁혀 줍니다. 그것만으로 범위를 정하지는 않으므로, 도구가 뭐라고 하든 매번 실행하는 비즈니스 핵심 프로세스 묶음을 유지하십시오.

SAP 테스트 및 검증 도구 비교 글에서 이 제품들이 어떻게 맞물리는지, 그리고 귀사의 SAP 지원 계약에 이미 무엇이 포함되어 있는지 다룹니다.

회귀 테스트는 같은 테스트가 반복해서 실행되기 때문에 테스트 자동화가 제값을 하는 곳입니다. 그렇다고 모든 회귀 테스트 스위트를 자동화해야 한다는 뜻은 아닙니다.

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

1년에 두 번 전체 스위트를 실행하고 그 사이에 트랜스포트까지 테스트하는 public edition 고객은 금방 이 기준을 넘습니다. 1년에 몇 번만 바뀌는 작은 private edition 시스템은 그렇지 않을 수 있습니다.

구매 전에 다음 질문을 던지십시오.

1. 회귀 테스트 케이스가 몇 개이며, 그중 몇 개가 사이클마다 실행됩니까?
2. 얼마나 자주 실행합니까? 릴리스 업그레이드만이 아니라 트랜스포트, feature pack, 업그레이드를 모두 세어 보십시오.
3. 수동 실행에 얼마나 걸리며, 회귀 테스트 기간 안에 들어갑니까?
4. 화면과 프로세스가 바뀔 때 스크립트는 누가 유지보수합니까?

스크립트 유지보수는 사람들이 과소평가하는 비용입니다. 아무도 업데이트하지 않는 자동화 스위트는 시스템과 아무 관계없는 이유로 실패하고, 팀은 그 결과를 더 이상 신뢰하지 않게 됩니다.

제가 이끈 프로젝트에서 팀은 Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath를 사용했습니다. 데모가 아니라 귀사의 시스템과 팀에 맞는지를 기준으로 고르십시오. 어디서 시작하고 투자 회수를 어떻게 판단할지는 SAP 테스트 자동화 가이드에서 다룹니다.

SAP 프로젝트에서 가장 어려운 회귀 테스트 문제는 도구가 아닙니다. 두 갈래의 변경이 같은 시스템을 동시에 통과한다는 점입니다.

프로젝트가 새 기능을 만드는 동안에도 운영 지원은 운영 환경을 계속 수정합니다. 두 흐름이 하나의 개발 및 품질 경로를 공유하면, 운영 지원 수정이 프로젝트 테스트를 깨뜨리고 프로젝트 변경이 운영 지원 릴리스에 섞여 들어갈 수 있습니다. 그러면 어떤 변경이 실패를 일으켰는지 아무도 알 수 없습니다.

제 해법은 랜드스케이프를 두 개로 분리하는 것입니다. 하나는 프로젝트용, 하나는 일상 운영(BAU)용이며, 운영 지원 변경과 프로젝트 변경을 따로 테스트합니다.

프로젝트 랜드스케이프BAU 랜드스케이프

통과하는 것프로젝트 랜드스케이프프로젝트를 위한 새 기능, 구성, 커스텀 코드BAU 랜드스케이프운영 시스템의 수정 사항과 작은 변경

회귀 테스트 초점프로젝트 랜드스케이프프로젝트가 바꾸는 프로세스와 핵심 스위트BAU 랜드스케이프각 수정이 닿는 프로세스와 핵심 스위트

운영 환경 반영프로젝트 랜드스케이프Go-Live 또는 릴리스 웨이브 시점BAU 랜드스케이프평소 일정에 따른 운영 지원 릴리스

두 랜드스케이프는 분리 문제를 해결하지만 새로운 일을 만듭니다. 모든 BAU 수정은 프로젝트 랜드스케이프에도 반영되어야 합니다. 그렇지 않으면 프로젝트가 그 수정 없이 Go-Live하게 됩니다.

처음부터 이에 대비하십시오.

1. 모든 BAU 변경을 정해진 주기로 프로젝트 랜드스케이프에 레트로핏하고 하나하나 추적합니다.
2. 레트로핏할 때마다 영향을 받는 프로젝트 테스트를 다시 실행합니다. 마지막에만 하지 않습니다.
3. 컷오버가 다가오면 BAU 변경을 동결합니다. 두 랜드스케이프를 모두 거치는 긴급 수정만 예외로 합니다.
4. Go-Live 전에 프로젝트 랜드스케이프에서 전체 회귀 테스트 스위트를 실행합니다. 운영 수준의 마스킹된 데이터를 사용합니다.

두 번째 랜드스케이프에는 비용이 듭니다. 하지만 어떤 변경이 대금 청구를 깨뜨렸는지 아무도 말하지 못하는 Go-Live에도 비용이 듭니다. 회귀 테스트 사이클이 통합 테스트, 사용자 인수 테스트와 함께 어디에 들어가는지는 S/4HANA 테스트 전략에 정리했습니다.

필요해지기 전에 회귀 테스트 스위트를 만드십시오. 현업이 절대 잃어서는 안 되는 프로세스를 나열하고, 각각에 대한 테스트를 작성하고, 수동으로 한 번 실행해 전체 사이클에 얼마나 걸리는지 확인하십시오.

그 수치를 보면 다음 업그레이드 기간이 현실적인지, 자동화가 투자를 회수할지 알 수 있습니다. 프로젝트가 진행 중이라면 프로젝트 변경과 BAU 변경이 운영 환경으로 가는 경로를 하나로 공유하고 있지 않은지 확인하십시오.

회귀 테스트 접근 방식이나 업그레이드 계획에 대해 독립적인 의견이 필요하시면 제가 도와드리고 있습니다. 여기에서 연락하실 수 있습니다.

SAP 회귀 테스트란 무엇입니까?

바뀌지 않아야 할 SAP 비즈니스 프로세스의 테스트를 다시 실행해, 트랜스포트, 서포트 패키지, 업그레이드, 새 릴리스가 그 프로세스를 깨뜨리지 않았음을 증명하는 것입니다. 변경된 오브젝트만이 아니라 Order to Cash나 월 마감 같은 통합 흐름까지 다룹니다.

SAP Cloud ERP public edition은 얼마나 자주 회귀 테스트가 필요합니까?

SAP가 public edition을 2월과 8월에 업그레이드하므로 최소 1년에 두 번입니다. SAP는 테스트 시스템을 먼저, 운영 시스템을 몇 주 뒤에 업그레이드하므로 회귀 테스트는 그 간격 안에 끝나야 합니다. 릴리스 사이의 트랜스포트에는 별도의 더 작은 실행이 필요합니다.

RISE with SAP private edition 업그레이드에서 회귀 테스트는 누가 합니까?

기술 업그레이드는 SAP가 수행합니다. 계획, 준비, 테스트는 고객이나 구축 파트너의 몫이므로, 회귀 테스트 공수는 구독과 별도로 예산을 잡으십시오.

SAP 회귀 테스트 범위를 정하는 데 어떤 도구가 도움이 됩니까?

영향 분석 도구는 무엇이 바뀌었는지와 무엇을 쓰고 있는지를 비교합니다. 흔한 선택지는 SAP Solution Manager의 Business Process Change Analyzer와 Scope and Effort Analyzer, 그리고 public edition용 Release Assessment and Scope Dependency 도구입니다. Tricentis LiveCompare와 Panaya도 같은 일을 하며, SAP Cloud ALM은 회귀 테스트 계획과 실행을 관리합니다.

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

광범위하게 반복 테스트해야 하는 테스트 케이스가 많을 때 자동화하십시오. 그보다 적다면 수동 테스트로 충분합니다. 도구를 사기 전에 테스트 케이스 수와 실행 빈도를 세어 보고, 스크립트 유지보수 비용도 예산에 넣으십시오.

운영 시스템을 지원하면서 SAP 프로젝트 기간에 회귀 테스트는 어떻게 합니까?

랜드스케이프를 두 개로 분리해 하나는 프로젝트용, 하나는 일상 운영용으로 운영하십시오. 그러면 운영 지원 변경과 프로젝트 변경을 따로 테스트할 수 있습니다. 모든 BAU 수정을 프로젝트 랜드스케이프에 레트로핏하고 영향을 받는 테스트를 다시 실행하십시오.