SAPテスト自動化：どこから始め、いつ元が取れるのか

SAPテスト自動化とは、何度も繰り返し実行するSAPのテスト（主に回帰テスト）を、人の代わりにツールが実行するテストに置き換えることです。広範囲で繰り返しのテストが必要なテストケースが大量にあるときに元が取れます。それに満たないなら、手動テストで十分です。

これは私がS/4HANAプログラムで使っているルールです。私の経験では、テストはプログラム工数の約35パーセントを占めます。ですから、問題はテストをするかどうかではありません。その工数のどの部分をツールに担わせるかです。

自動化が単体テスト、結合テスト、受入テスト、パフォーマンステストとどう組み合わさるかについては、まず私の概要記事SAPテストとはをお読みください。この記事では、どこから始めるべきか、自動化がいつ元を取れるのか、フレームワーク、そしてSAP Cloud ALM、Solution Manager、Tricentisで何が得られるのかを解説します。

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

理由はコストの構造にあります。自動テストは、手作業で1回実行するよりも構築にコストがかかり、プロセス、画面、データが変わるたびに保守が必要です。そのコストを取り戻せるのは、繰り返し実行することによってだけです。

SAPプログラムでは、繰り返しは予測できる場所から生まれます。

1. 移送。 品質保証システムに移送される変更はどれも、昨日まで動いていたものを壊す可能性があります。
2. SAPのリリースとサポートパッケージ。 オンプレミスとプライベートクラウドでのアップグレード、そしてSAP S/4HANA Cloud Public Editionでの定期アップグレードです。
3. 繰り返されるテストのラウンド。 結合テスト（SIT）では、同じエンドツーエンドのフローを複数のラウンドで実行します。
4. ロールアウトのウェーブ。 グローバルテンプレートは、国や会社コードごとに再びテストされます。
5. データ量の多いチェック。 価格設定、税、勘定決定の多数の組み合わせで、変わるのはデータだけというケースです。

どれにも当てはまらないなら、ツールは節約できる以上のコストを生みます。

テストの種類ごとに、私なら作業をどう分けるかを表にまとめました。

テストの種類	自動化するか	理由
受注から入金、購買から支払、記帳から報告といったコアプロセスの回帰テスト	はい、最優先で	移送のたび、リリースのたびに実行するため
SITのラウンド	一部	安定したフローは自動化し、新しいシナリオや変更中のシナリオは手動のままにする
ユーザー受入テスト（UAT）	ほとんどしない	プロセスが自分たちに合っているかを判断するのは業務ユーザーであり、スクリプトにはできないため
探索的テストと異常系テスト	いいえ	価値は、誰もスクリプト化していないものを人が探すことから生まれるため
パフォーマンスと負荷	はい、負荷テストツールで	多数の同時ユーザーを手作業で生み出すことはできないため
1回限りのデータ移行チェック	通常はしない	同じロードが模擬実行のたびに繰り返されない限り、照合レポートのほうが適しているため

Decide

このSAPテストを自動化すべきか

テストケースが多く、変更やリリースのたびに繰り返す

→自動化する

テストケースが少ない、または実行は一度か二度

→手動でテストする

プロセス設計がまだ変わっている

→安定するまで待ってから判断する

期待外れに終わる自動化は、たいてい範囲を広げすぎて始まっています。すべてを対象にし、設計中に着手し、結果に誰も責任を持たないという形です。私なら次の順序で進めます。

1. 業務部門が絶対に壊せないプロセスを選ぶ。 月次決算、請求、支払、多数の拠点に展開するものは、あれば便利という程度のレポートより先です。
2. まず手動でテストを実行する。 ツールが自動化するのは、手作業ですでに動くテストです。テストを設計してくれるわけではありません。
3. 設計が安定するのを待つ。 ExploreやRealizeの初期に自動化すると、設計の決定が変わるたびにテストを作り直すことになります。
4. 小さな回帰テストパックを作る。 重要なプロセスをエンドツーエンドでカバーし、品質保証システムへの移送のたびにそのパックを実行します。
5. 保守の責任者を指名する。 画面、ロール、データが変わったときに誰かがテストを直さなければ、パックは数回のリリースで劣化します。
6. 繰り返しに見合う場合にだけカバー範囲を広げる。 カバー率の目標があるからではなく、頻繁に実行されるからテストを追加します。

プロジェクトと通常業務を分ける

プログラムの期間中、私はプロジェクト用と通常業務（BAU）用の2つの環境を別々に運用します。そうすれば、本番保守の変更とプロジェクトの変更を分けてテストできます。

これは自動化にとって重要です。回帰テストが失敗したとき、調べるべき変更の出どころは、2つが混ざったものではなく1つであってほしいのです。私のSAP回帰テストのガイドでは、2環境のアプローチと影響分析をさらに詳しく解説しています。

私は自分のプログラムで、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、または対象となるクラウドサブスクリプションを契約している顧客は、テナントを1つプロビジョニングできます（SAP usage rights）。

自動テストそのものは実行しません。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の延長メンテナンスを選択した顧客は、Solution Managerの延長メンテナンスを2030年末まで受けられます。対象はテストスイートを含む限られた領域です（SAP Support）。

Solution Manager独自の自動化であるComponent-Based Test Automation（CBTA）は、SAPのクラウド製品には拡張されません。Solution Manager連携向けのTricentisのライセンスは、現在2027年12月31日までです。すでにSolution Managerを運用しているなら、環境が移行するまでは使い続けてかまいませんが、新しい自動化をその上に構築しないでください。

SAP S/4HANA Cloud Public Edition

Public Editionには独自のTest Automation Toolが付属しています。SAPのガイダンスでは、パートナーが各プロセスを設定する際にテストオートメートを作成または更新し、アップグレード時にテストシステムで実行できるようにすることになっています（SAP Learning）。

顧客が同意すれば、SAPは変更を加えていない標準プロセスに対してアップグレード後のテストを実行します。本稼働後、カスタマイズしたものについての回帰テストは、自社のオートメートを使って自社で責任を持ちます。

上で挙げたツールを、好みではなく役割ごとに表にまとめました。

ツール	主な役割	適する場面
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	パフォーマンステストと負荷テスト	本稼働前の同時実行テストとボリュームテスト

Xray for Jiraを含むより詳しい比較は、私のSAPテストツールのガイドをお読みください。負荷テストについては、IT責任者のためのSAPパフォーマンステストをお読みください。

ツールよりも重要なのは、テストをどう構築し、誰が保守するかです。SAPの自動化のほとんどは、次のいずれかのアプローチに当てはまります。

1. モデルベース。 画面とAPIをスキャンして再利用可能なモジュールにし、それを組み合わせてテストケースを作ります。機能コンサルタントがコードなしで作成し、読むことができます。
2. コードレスのプロセスキャプチャ。 業務プロセスの手順を記録し、再利用可能なテストに変えます。キーユーザーが回帰テストパックの作成を手伝うチームに向いています。
3. コードベース。 テストエンジニアがプログラミングフレームワークでテストを書きます。開発チームが所有するFioriアプリやAPIに適しており、保守には開発者が必要です。
4. テストモジュールを備えたRPAプラットフォーム。 業務の自動化とテストの自動化を1つのプラットフォームで行います。すでに運用しているなら有用です。
5. SAPが提供するオートメート。 Public Editionでは、Test Automation Toolとともに提供されるテストオートメートを、自社のデータと変更に合わせて調整します。

どのアプローチを選んでも、テストが生き残るかどうかは3つの設計上の選択で決まります。

1. 可能な限りAPIレベルでテストする。 APIのテストは、画面をクリックしていくテストより壊れにくいです。
2. テストデータをリセットできるようにしておく。 前回の実行で使い切ったデータに依存するテストは、本来とは違う理由で失敗します。
3. 共有モジュールから構築する。 画面が変わったとき、その画面に関わるすべてのテストではなく、1つのモジュールを直せば済みます。

自動化された回帰テストパックは、プロジェクトの成果物ではなく1つのプロダクトです。責任者、予算項目、そして変更プロセスの中での位置づけが必要です。

変更管理と結びつけてください。回帰テストパックを実行し、その結果をテスト管理ツールに記録するまで、どの移送も本番に進めません。私の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 7.2のメインストリームメンテナンスは2027年に終了し、CBTAによる自動化はSAPのクラウド製品には拡張されません。新しい自動化はCloud ALMを前提に計画してください。