SAPの回帰テスト：アップグレード、リリース、範囲の決め方

SAPの回帰テストは、変更、サポートパッケージ、新しいリリースが、すでに動いていた業務プロセスを壊していないことを証明するものです。影響分析で範囲を決め、リスクの最も高いプロセスから実行し、本稼働前に一度だけではなく、システムが変わるたびに繰り返します。

きっかけになるのは、移送、アップグレード、クラウドのリリースです。SAP Cloud ERP public editionではアップグレードの日程をSAPが決めるため、回帰テストスイートはリリースが来る前に準備できていなければなりません。

回帰テストは、私のSAPテストのガイドで取り上げているテストの種類の1つです。この記事では、何がきっかけになるのか、範囲をどう決めるか、いつ自動化するか、そしてプログラムと本番保守が互いの作業を壊さないようにする方法を解説します。

SAPは統合されたシステムです。価格条件の変更が請求を壊すことがあり、受注に追加した新しい項目がインターフェースを止めることもあります。サポートパッケージが、頼りにしている標準プログラムを変えてしまうこともあります。

回帰テストは、変わるはずではなかったプロセスについてテストをもう一度実行します。機能テストは新しいものが動くかどうかを問い、回帰テストはそれ以外のすべてが引き続き動くかどうかを問います。

回帰テストはプログラムの期間中だけでなく、システムのライフサイクル全体にわたって適用されます。

1. 移送。 開発から品質保証へ移送される変更はどれも、それが関わるプロセスにとって回帰のリスクです。
2. サポートパッケージとフィーチャーパック。 SAPの修正と新機能は、自社の設定の下にある標準コードを変えます。
3. リリースのアップグレード。 新しいリリースへの移行や、自社で日程を決めていないクラウドのリリースは、一度にはるかに多くのものを変えます。
4. システム変換。 ECCからS/4HANAへのシステム変換では設定とカスタムコードを引き継ぐため、引き継いだものはすべて再テストが必要です。それが計画のどこに位置するかは、私のECCからS/4HANAへの移行ガイドで説明しています。
5. 連携と拡張。 接続先のシステムやサイドバイサイドの拡張での変更は、SAPの移送がなくてもSAP側を壊すことがあります。

回帰テストスイートは、新しい機能のために書いたテストとは分けておいてください。スイートは、受注から入金、購買から支払、月次決算のように、業務部門が失うわけにはいかないプロセスを集めた安定したライブラリです。

オンプレミスでは、アップグレードの時期は自社で選びます。クラウドのエディションではスケジュールの多くをSAPが決め、回帰テストはカレンダー上で繰り返し発生する約束事になります。

Public edition：年2回のアップグレード

SAP Cloud ERP public edition（旧S/4HANA Cloud Public Edition）では、年2回、2月と8月に大きなアップグレードがあります。その間には、より小規模な機能提供があります。

SAPはまずテストシステムをアップグレードし、その数週間後に本番をアップグレードします。その間が回帰テストの期間であり、本番がアップグレードされてしまえば二度目のチャンスはありません。

SAPのアップグレード後テストと回帰テストに関するCloud ALMのコースでは、Cloud ALMで回帰テスト計画を作成し、リリースごとに再利用することを推奨しています。Public editionには、事前提供のテストスクリプトを備えた無償のテスト自動化ツールも含まれているため、標準プロセスには出発点があります。

Private edition：2年のリリースサイクル

RISE with SAPを通じて販売されるプライベートエディションのSAP Cloud ERP Privateは、オンプレミスのリリースサイクルに従います。SAP Learningによると、新しいベースリリースは2年ごとに出荷され、フィーチャーパックスタックが6か月ごとに続き、各リリースには7年間のメインストリームメンテナンスがあります。

メインストリームメンテナンスの対象であり続けるには、少なくとも7年に1回はアップグレードを適用する必要があり、RISEでは年1回のアップグレードを依頼できます。技術的なアップグレードはSAPが行いますが、計画、準備、テストは引き続き顧客またはパートナーの仕事です。

この分担は予算にとって重要です。アップグレード自体はサブスクリプションに含まれていても、その周辺の回帰テストは含まれていません。

回帰テストのきっかけを次の表で並べて比較します。

変更	頻度	日程を決めるのは誰か	回帰テストでカバーすべきもの
品質保証システムへの移送	毎日または毎週	自社のチーム	変更されたオブジェクトが関わるプロセス
Public editionのアップグレード	年2回、2月と8月	SAP	対象範囲のすべてのプロセス。カスタムロジックを優先し、本番前の期間内に
Private editionのフィーチャーパックスタック	適用する場合は6か月ごと	自社（SAPのスケジュールの範囲内で）	使用している標準機能のうち変更されたものと、カスタムコード
Private editionのリリースアップグレード	少なくとも7年ごと。RISEでは依頼により年1回まで	自社（SAPと共に）	スイート全体、カスタムコード、連携
ECCからS/4HANAへのシステム変換	1回	自社	引き継いだものすべて

変更のたびにスイート全体を実行するのは、時間もコストもかかります。実行が少なすぎれば不具合をすり抜けさせ、そのすき間は本番で表面化します。

影響分析はその中間に位置します。何が変わったかと実際に何を使っているかを比較し、最もリスクの高いプロセスとオブジェクトを洗い出すので、回帰テストの実行はそこから始められます。

目にすることになるツールは次のとおりです。

1. SAP Solution Manager。 Test Suiteの一部であるBusiness Process Change Analyzerは、変更がどの業務プロセスに影響するかを示します。Scope and Effort Analyzerは、サポートパッケージやエンハンスメントパッケージを適用する前にその影響を見積もるもので、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のバージョン、フィーチャーパックスタック、サポートパッケージスタックをカバーします。

Solution Managerの上に何かを構築する前に、その状況を確認してください。SAP Supportによると、Solution Manager 7.2のメインストリームメンテナンスは2027年末に終了します。Business Suite 7の延長メンテナンスを選択した顧客は2030年末まで使い続けられ、SAPは2027年末までにCloud ALMへ移行することを推奨しています。

影響分析は範囲を絞り込みます。しかし、それだけで範囲が決まるわけではありません。ツールが何と言おうと毎回実行する、業務上重要なプロセスの中核は残しておいてください。

私のSAPのテストおよび検証ツールの比較記事では、これらの製品がどう組み合わさるか、そしてSAPのサポート契約にすでに何が含まれているかを解説しています。

テスト自動化が真価を発揮するのは回帰テストです。同じテストを何度も繰り返し実行するからです。だからといって、すべての回帰テストスイートを自動化すべきだというわけではありません。

私のルールはシンプルです。広範囲で繰り返しのテストが必要なテストケースが大量にあるなら、自動化します。それに満たないなら、手動テストで十分です。

年2回スイート全体を実行し、その間にも移送があるpublic editionの顧客は、すぐにこの基準に達します。年に数回しか変更がない小規模なprivate editionのシステムは、達しないかもしれません。

購入する前に、次の問いを立ててください。

1. 回帰テストケースはいくつあるか。 そのうちいくつをサイクルのたびに実行するか。
2. どれくらいの頻度で実行するか。 リリースのアップグレードだけでなく、移送、フィーチャーパック、アップグレードも数に入れます。
3. 手動での実行にどれくらいかかるか。 それは回帰テストの期間内に収まるか。
4. 画面やプロセスが変わったとき、誰がスクリプトを保守するか。

スクリプトの保守は、多くの人が過小評価するコストです。誰も更新しない自動化スイートは、システムとは関係のない理由で失敗するようになり、チームはそれを信頼しなくなります。

私が率いたプログラムでは、チームがTricentis Tosca、Worksoft、Panaya、SAP Cloud ALM、SAP Solution Manager、UiPathを使ってきました。デモではなく、自社のシステムとチームへの適合性で選んでください。私のSAPテスト自動化ガイドでは、どこから始めるべきか、投資回収をどう判断するかを解説しています。

SAPプログラムで最も難しい回帰テストの問題は、ツールではありません。2つの変更の流れが同時に同じシステムを通っていくことです。

プログラムが新しい機能を構築している間も、本番保守は本番環境の修正を続けます。両方の流れが1つの開発、品質保証の経路を共有していると、保守の修正がプロジェクトのテストを壊したり、プロジェクトの変更が保守のリリースに紛れ込んだりします。そうなると、どの変更が障害を引き起こしたのか誰にもわかりません。

私の答えは、2つの環境を別々に運用することです。1つはプロジェクト用、もう1つは通常業務（BAU）用で、本番保守の変更とプロジェクトの変更を分けてテストします。

プロジェクト環境BAU環境

通過するものプロジェクト環境プログラムのための新機能、設定、カスタムコードBAU環境本番システムへの修正と小さな変更

回帰テストの焦点プロジェクト環境プログラムが変更するプロセスと中核スイートBAU環境各修正が関わるプロセスと中核スイート

本番への反映プロジェクト環境本稼働時またはリリースのウェーブでBAU環境保守リリースとして通常のスケジュールで

2つの環境は分離の問題を解決しますが、新しい仕事を生みます。BAUの修正はすべてプロジェクト環境にも反映しなければなりません。そうしないと、プロジェクトはその修正なしで本稼働を迎えます。

最初から次のことを計画に入れてください。

1. BAUの変更はすべて、決まったリズムでプロジェクト環境にレトロフィットし、1件ずつ追跡します。
2. 影響を受けるプロジェクトのテストを再実行します。 最後にまとめてではなく、レトロフィットのたびに行います。
3. カットオーバーが近づいたらBAUの変更を凍結します。 ただし、両方の環境を通す緊急の修正は例外です。
4. 本稼働前に、プロジェクト環境で回帰テストスイート全体を実行します。 データは本番レベルでマスキングしたものを使います。

2つ目の環境にはコストがかかります。しかし、どの変更が請求を壊したのか誰にも説明できない本稼働にもコストがかかります。私のS/4HANAテスト戦略では、回帰テストのサイクルが結合テストやユーザー受入テストとどう並ぶかを示しています。

必要になる前に回帰テストスイートを作ってください。業務部門が失うわけにはいかないプロセスを書き出し、それぞれにテストを書き、一度手作業で実行して、1サイクル全体にどれくらいかかるかを確かめます。

その数字から、次のアップグレード期間が現実的かどうか、自動化で元が取れるかどうかがわかります。プログラムの途中であれば、プロジェクトとBAUの変更が本番への1つの経路を共有していないかを確認してください。

回帰テストのアプローチやアップグレード計画について独立した視点が必要であれば、私はこうした支援を行っています。こちらからご連絡ください。

SAPの回帰テストとは何ですか？

変わるはずではなかったSAPの業務プロセスについてテストを再実行し、移送、サポートパッケージ、アップグレード、新しいリリースがそれらを壊していないことを証明するものです。変更されたオブジェクトだけでなく、受注から入金や月次決算のような統合されたフローもカバーします。

SAP Cloud ERP public editionではどれくらいの頻度で回帰テストが必要ですか？

少なくとも年2回です。SAPはpublic editionを2月と8月にアップグレードするからです。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プログラムの期間中に回帰テストを行うにはどうすればよいですか？

プロジェクト用と通常業務用の2つの環境を別々に運用します。そうすれば本番保守の変更とプロジェクトの変更を分けてテストできます。BAUの修正はすべてプロジェクト環境にレトロフィットし、影響を受けるテストを再実行してください。