SAPテストとは：種類、フェーズ、責任者

SAPテストとは、設定済みのSAPシステムが自社のデータと自社のボリュームで業務プロセスを正しく処理できることを、本稼働の前に、そしてその後システムが変わるたびに証明する作業です。S/4HANAプログラムでは、単体テスト、結合テスト（SIT）、ユーザー受入テスト（UAT）、回帰テスト、パフォーマンステスト、カットオーバーリハーサルの6種類のテストが対象になります。

それぞれの種類は異なる問いに答えるもので、どれも他の代わりにはなりません。私の経験では、テストはプログラム工数の約35パーセントを占めます。だからこそ、構築の最後に数週間を割り当てるのではなく、独自の計画、予算、責任者を持たせるべきなのです。

このページは全体像の解説です。各種類には個別のガイドがあり、以下の各セクションからリンクしています。

SAPシステムは、設定、マスタデータ、カスタムコード、インターフェースが一体となって動くものです。ある箇所の変更が別の場所のプロセスを壊すことがあり、しかもそれは誰も触っていないモジュールで起こることが少なくありません。

そのため、SAPテストは画面ではなく業務プロセスを軸に組み立てます。受注から入金、購買から支払、記帳から報告といったプロセスは複数のモジュールにまたがるので、1つのトランザクションで止まるテストではほとんど何も証明できません。

テストは本稼働で終わるわけでもありません。保守での変更、SAPのリリース、新たなロールアウトはどれもシステムを変えるため、同じ規律がRunフェーズにも引き継がれます。

S/4HANAプログラムで私が計画に組み込む6つの種類です。表では、それぞれが何を証明し、いつ実施され、誰が責任を持つべきかを示しています。

テストの種類	証明すること	SAP Activateでの位置づけ	責任者
単体テスト	各設定項目、プログラム、拡張機能が単独で動作すること	Realize、各構築スプリントの中	機能コンサルタントと技術コンサルタント
結合テスト（SIT）	現実的なデータで、プロセス全体がモジュールとインターフェースをまたいで動くこと	Realize、構築が安定してからラウンド制で	プログラムのテストリード（プロセスオーナーと共に）
ユーザー受入テスト（UAT）	業務部門が実際のシナリオをシステムで処理できること	Realizeの終盤、Deployの前	業務部門
回帰テスト	変更後も、以前動いていたものが引き続き動くこと	Realize以降、その後Runでのリリースごと	テストリード（件数に見合う場合は自動化を活用）
パフォーマンステスト	多数のユーザーと本番並みのボリュームが同時にかかってもシステムが持ちこたえること	Realize、本稼働前に完了	プログラムレベルのパフォーマンスリードとBasis
カットオーバーリハーサル	本稼働の手順、データロード、所要時間が最初から最後まで機能すること	Deploy	カットオーバーマネージャー

SAP ActivateにおけるSAPテスト

1. 01

   Prepare

   テストツール、チーム、テスト環境を整えます。

2. 02

   Explore

   Fit-to-Standardの決定と並行してテスト戦略を作成し、要件をテスト可能なものにします。

3. 03

   Realize

   スプリント内で単体テストを行い、構築が安定したらSITのラウンド、パフォーマンステスト、UATを実施します。

4. 04

   Deploy

   合意したチェックリストに沿ってカットオーバーリハーサルを行い、本稼働を判断します。

5. 05

   Run

   保守での変更、アップグレード、リリースのたびに回帰テストを行います。

単体テスト

単体テストは、その項目を構築した本人が行います。機能コンサルタントは価格条件を確認し、開発者は拡張機能やインターフェースのマッピングを確認します。

必要ではありますが、それだけでは十分ではありません。単体テストがきれいに通っても、その項目がプロセスの残りの部分とつながったときに何が起きるかは何もわかりません。

結合テスト

SITは、設計が機能するかどうかをプログラムが確かめる場です。受注は出荷、請求、会計、レポートへと流れなければならず、途中のすべてのインターフェースが正しく転記しなければなりません。

私はSITを1回の実施ではなく、複数のラウンドで計画します。最初のラウンドで見つかった不具合を修正し、次のラウンドでその修正が他の何も壊していないことを証明します。ラウンド、開始基準、終了基準の組み立て方は、私のS/4HANAテスト戦略ガイドで解説しています。

ユーザー受入テスト

UATは、本稼働後の業務の進め方をシステムが支えられることを業務部門が確認するものです。責任はシステムインテグレーターではなく業務部門にあります。システムを受け入れられるのは業務部門だけだからです。

UATには最低でも6〜8週間が必要です。遅れた構築に合わせて圧縮すれば、書類上の承認と本番環境での問題が手に入るだけです。私のSAPユーザー受入テストのガイドでは、スクリプト、役割、承認について解説しています。

回帰テスト

回帰テストは、変更が壊したものを見つけるために、すでに検証済みのテストを変更後にもう一度実行するものです。長期のプログラムでは、本番保守の修正とプロジェクトの変更が同時にシステムを通っていきます。

私のやり方は、プロジェクト用と通常業務（BAU）用の2つの環境を別々に運用することです。そうすれば本番保守の変更とプロジェクトの変更を分けてテストでき、どちらかがもう一方の不具合を覆い隠すことがありません。私のSAP回帰テストのガイドでは、2環境のアプローチ、アップグレード、影響分析を解説しています。

パフォーマンステスト

パフォーマンステストは本稼働前に実施しなければなりません。最も重要なのは同時実行テストで、多数のユーザーが同じ瞬間にトランザクションを実行する状況を再現します。

1人のユーザーでは正しく動くトランザクションが、200人ではタイムアウトすることがあります。機能テストでは、それは決して見えてきません。IT責任者向けのSAPパフォーマンステストのガイドでは、負荷テスト、ストレステスト、ソークテストと、受入基準の書き方を解説しています。

カットオーバーリハーサル

カットオーバーリハーサルは、本稼働そのものをテストします。技術的な手順の順序、データロード、照合、承認を、所要時間も含めて確認します。ブラウンフィールドのシステム変換では、私はカットオーバーの前に3回の模擬変換を計画します。

私が譲らない本稼働の基準は、事前に合意した詳細なカットオーバーチェックリストです。チェックリストがカットオーバーの週末に書かれているなら、それまでのリハーサルは本当の意味でのリハーサルではなかったということです。

私の経験では、テストはプログラム工数の約35パーセントを占めます。テストを構築と本稼働の間の短いすき間だと考えているスポンサーは、この数字に驚きます。

工数は多くの人に分散しています。コンサルタントが単体テストを行い、テストチームがSITを準備して実行し、業務ユーザーがUATを行い、Basisとインテグレーションのチームがパフォーマンステストとカットオーバーリハーサルを支えます。

データ移行はこれと並行して進み、それだけで工数の30〜40パーセントを占めます。テストのラウンドごとに本番に近い移行済みデータが必要になるため、両者は大きく重なります。

私が最もよく目にするテストの失敗は、単純にSITとUATでのテスト不足です。構築が遅れるとラウンドが削られ、本稼働日はそのまま据え置かれます。私が主導または立て直した21のSAPプログラムを通じて、最大の失敗は今でも最初にきちんと計画しないことであり、それが最初に表面化するのはたいていテストです。

テストの質は、テストに使うデータの質で決まります。私のルールは、マスキングしたデータを本番レベルで使うことです。つまり、本番規模のボリュームと現実的なレコードを使い、個人情報や機密性の高い項目はマスキングします。

小さくきれいなテストデータは、重要な問題を隠してしまいます。数千件のレコードなら数秒で終わるレポートが、1年分の転記では何時間もかかることがあります。

環境はデータと同じくらい重要です。Prepareでテスト環境を計画し、ラウンドの間にどう更新するかを決め、プロジェクトとBAUの変更を分けておいてください。私のSAPテストデータ管理のガイドでは、コピー、マスキング、選択的なテストデータを解説しています。

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

自動化が最初に効果を出すのはたいてい回帰テストです。変更のたびに同じテストを実行するからです。UATは主に手動のままです。その目的はスクリプトではなく業務ユーザーの判断にあるからです。

早めに判断すべき実務上の理由もあります。自動テストは構築と保守に時間がかかるため、何度も実行してはじめて元が取れます。私のSAPテスト自動化ガイドでは、どこから始めるべきか、いつ元が取れるかを解説しています。

ツールは、テスト管理、機能テストの自動化、パフォーマンステストの3つのグループに分かれます。私が率いた、あるいは一緒に仕事をしたチームは、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を含むクラウドサブスクリプション（クラウドエディション）の顧客に含まれています（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の業務側の責任者を指名し、構築に押しつぶされる前に、今のうちに6〜8週間をカレンダーで確保してください。

測定可能な終了基準を使って、テスト結果を本稼働可否の判断に結びつけてください。その方法は私のSAP品質ゲートのガイドで紹介しています。すでにプログラムが問題を抱えているなら、SAPプログラムの立て直しについての私のメモで、最初に何を直すべきかを解説しています。

テスト戦略や本稼働の判断について独立した視点が必要であれば、私はこうした支援を行っています。こちらからご連絡ください。

SAPテストとは何ですか？

SAPテストは、設定済みのSAPシステムが自社のデータと自社のボリュームで業務プロセスを正しく処理できることを証明するものです。S/4HANAプログラムでは、単体テスト、結合テスト、ユーザー受入テスト、回帰テスト、パフォーマンステスト、カットオーバーリハーサルが含まれます。本稼働後も、保守での変更やリリースのたびに続きます。

SAPテストにはどのような種類がありますか？

主な6つの種類は、単体テスト、結合テスト（SIT）、ユーザー受入テスト（UAT）、回帰テスト、パフォーマンステスト、カットオーバーリハーサルです。単体テストは個々の項目を、SITはモジュールとインターフェースにまたがるプロセス全体を確認し、UATは業務部門がシステムを受け入れるためのものです。回帰テスト、パフォーマンステスト、カットオーバーリハーサルは、変更、負荷、そして本稼働そのものに対する備えです。

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を前提に計画すべきです。