S/4HANAのテスト戦略：サイクル、基準、役割

S/4HANAのテスト戦略は、どのテストサイクルを、どの順序で実施し、誰がそれぞれに責任を持ち、どのような証拠があれば次のサイクルに進めるのかを決めるものです。私のプログラムでは、複数ラウンドの結合テスト（SIT）、複数ラウンドのユーザー受入テスト（UAT）、回帰テストをカバーし、それぞれに文書化した開始基準と終了基準、そして指名された承認者を置きます。

私が計画するS/4HANAプログラムでは、テストがプログラム工数の約35パーセントを占めます。ですから、テスト戦略には構築計画と同じだけの注意を払うべきです。

テストの種類そのものは、私のSAPテストとはのガイドで解説しています。この記事は戦略のレイヤーを扱います。サイクル、基準、役割、そして文書の構成案です。

SAP Activateでは、テストの大部分をRealizeに置いています。SAP自身のS/4HANA Cloud Private Edition向けテスト戦略の資料では、単体テストとストリングテストを非公式なものとして扱っています。業務プロセス全体のテスト、結合テスト、データ移行テスト、ユーザー受入テストは公式なもので、文書化が必須です。

S/4HANAプログラムで私が計画する順序は次のとおりです。

S/4HANAのテストサイクル

1. 01

   単体テストとストリングテスト

   コンサルタントが構築しながら、設定した各機能と短い連鎖をテストします。

2. 02

   SITのラウンド

   モジュール、インターフェース、移行済みデータにまたがるプロセスの連鎖全体をテストします。

3. 03

   UATのラウンド

   業務ユーザーが、システムで自分たちのプロセスを処理できることをラウンドごとに証明します。

4. 04

   回帰テスト

   修正、移送、リリースの後に、すでに合格したものを再テストします。

5. 05

   模擬変換とリハーサル

   本番当夜と同じようにカットオーバーを、チェックリストに沿って実行します。

6. 06

   本稼働

   合意したカットオーバーチェックリストが完了したときだけ本稼働します。

単体テストとストリングテスト

コンサルタントと開発者は、各設定項目と各開発を構築しながらテストします。ストリングテストは、受注から出荷までのように、いくつかの手順をつなげてテストします。

SAPの用語では非公式ですが、省略してよいものではありません。

複数ラウンドの結合テスト

SITでは、モジュール、インターフェース、変換またはロードしたデータにまたがって、業務プロセス全体をテストします。私はSITを1回のイベントではなく複数のラウンドで計画し、あるラウンドの後に修正した不具合を次のラウンドで再テストします。

SITのラウンド数を固定してはいません。ラウンド数は対象範囲のプロセス、インターフェース、エンティティの数によって決まります。テスト戦略には、何ラウンド行うのか、そしてその理由を書くべきです。

複数ラウンドのユーザー受入テスト

UATは、業務部門が自分たちの人員と現実的なデータを使って、システムで自分たちのプロセスを処理できることを確認する場です。SITと同様に、私はUATを複数のラウンドで計画し、あるラウンドでの修正を次のラウンドで再テストします。

UATには最低でも6〜8週間が必要です。業務側のテスト担当者は通常業務と並行してこれを行い、複数のラウンドをこなす時間が必要です。私のSAPユーザー受入テストのガイドでは、スクリプト、ラウンド、承認を詳しく解説しています。

回帰テスト

修正、移送、リリースはどれも、すでに合格したものを壊す可能性があります。回帰テストは、プログラムの期間中も本稼働後も、変更のたびに重要なプロセスを再実行します。

SAPの資料では回帰テストを主にRunのリリースアップグレード後に位置づけていますが、プログラムではもっと早い段階から必要です。アプローチ、影響分析、環境の構成については、私のSAP回帰テストのガイドで解説しています。

模擬変換とカットオーバーリハーサル

ブラウンフィールドのシステム変換では、私はカットオーバーの前に3回の模擬変換を計画します。それぞれ、プロセスだけでなく、変換そのもの、所要時間、照合をテストします。

最後のリハーサルは本番当夜と同じように実行すべきです。同じ順序、同じ人員、同じチェックリストです。私のS/4HANA移行のスケジュールとプロジェクト計画では、これらの実行が計画のどこに位置するかを示しています。

責任の所在に関する最も重要な決定は1つです。ユーザー受入テストの責任者は業務部門です。システムインテグレーターでも、IT部門でもありません。

インテグレーターはスクリプトを準備し、不具合を修正できます。しかし、財務の決算、受注から入金、工場を実際に回している人だけが、それらのプロセスが機能することを確認できます。

SAP自身のガイダンスも同じ方向を示しています。パートナーの設定の専門家がテストケースを作成し、顧客の業務部門の専門家がUATを実行して結果を記録します。

サイクルごとの責任の分担は、私なら次のようにします。

サイクル	責任者	実行者	承認者
単体テストとストリングテスト	構築チームのリード	コンサルタントと開発者	機能リードと技術リード
SITのラウンド	テストマネージャー	コンサルタント（後半のラウンドにはキーユーザーも参加）	テストマネージャーとプロセスオーナー
UATのラウンド	業務部門（指名されたプロセスオーナーを通じて）	キーユーザーと業務側のテスト担当者	プロセスオーナー、次にスポンサー
回帰テスト	テストマネージャー	テストチーム（件数に見合う場合は自動化）	テストマネージャーと変更諮問委員会
模擬変換とリハーサル	カットオーバーリード	技術、データ、機能の各チーム	カットオーバーリード、データリード、スポンサー

テスト戦略には役割ではなく名前を書いてください。「財務のプロセスオーナー」は役割です。承認することに同意した、名前のある個人が責任者です。

開始基準は、成功できる状態になる前にサイクルが始まるのを防ぎます。終了基準は、カレンダーがそう言っているという理由でサイクルが終わるのを防ぎます。

どちらも、誰も期限のプレッシャーにさらされていないRealize開始前に書いてください。私のSAP品質ゲートのガイドでは、これらの基準を、「準備ができていない」と言える責任者を持つ正式なゲートにする方法を説明しています。

次の表は、そのまま写すための標準ではなく、自社に合わせて調整するための指針です。パーセンテージと不具合の上限はスポンサーと一緒に決め、テスト戦略に記録してください。

サイクル	開始基準	終了基準
単体テストとストリングテスト	設計が承認済み。テスト対象の項目について設定と開発が完了	すべての項目をテストし文書化済み。不具合は修正済み、またはSITに対して記録済み
SITのラウンド	対象範囲のプロセスについて単体テストが完了。テスト環境が構築され、インターフェースが接続済み。テストデータがロード済み。スクリプトがレビュー済み	合意した割合のスクリプトが実行され合格。未解決の重大な不具合がない。未解決の軽度の不具合にはそれぞれ責任者と修正日がある
UATのラウンド	SITの終了基準を満たしている。業務側のテスト担当者が指名され、通常業務から外れている。スクリプトがプロセスオーナーによりレビュー済み。テストシステムでのトレーニングが完了	対象範囲のすべてのプロセスを業務ユーザーが実行。未解決の重大な不具合がない。プロセスオーナーが自分のプロセスを承認済み
回帰テスト	変更、修正のまとまり、またはリリースが移送できる状態。影響を受けるプロセスについて回帰テストパックが合意済み	回帰テストパックが合格。失敗があれば、変更を先に進める前に修正し再テスト済み
模擬変換またはリハーサル	本番のコピーが利用可能。カットオーバーチェックリストとランブックが起草済み。照合ルールが合意済み	変換またはロードが計画した時間内に完了。照合がデータリードにより承認済み。教訓を反映してチェックリストを更新済み
本稼働	それまでのすべての終了基準を満たしている。カットオーバーチェックリストが事前に合意済み	チェックリストのすべての項目が完了し承認済み。本稼働可否の判断がスポンサーにより記録済み

この表を機能させるルールは2つです。すべての基準がはい、いいえで答えられること、そしてすべての終了に指名された承認者がいることです。

サイクルが終了基準を満たさないまま、それでも業務部門が先に進みたいと言うなら、それを文書化された決定にしてください。リスクを受け入れた人と、持ち越す不具合を明記します。

テストマネージャーがPrepareまたはExploreの初期に作成し、スポンサーが承認します。プロセスオーナーが読む程度の短さに保ってください。

私が含まれていることを期待する項目は次のとおりです。

1. 範囲と目的。 どのプロセス、エンティティ、インターフェース、レポートをテストし、どれを明示的に対象外とするか。
2. テストの種類とサイクル。 単体テスト、ストリングテスト、SITのラウンド、UATのラウンド、回帰テスト、パフォーマンステスト、データ移行テスト、模擬変換。ラウンド数とその根拠も記載します。
3. スケジュールと工数。 SAP Activateの計画の中での各サイクルの日程。UATには最低でも6〜8週間を割り当て、工数はテストが占める約35パーセントの割合に照らして予算化します。
4. 役割と責任。 上の責任分担表に、名前を入れたもの。
5. 開始基準と終了基準。 サイクルごとに1セット。それぞれの承認者も記載します。
6. 環境。 どのサイクルにどのシステムを使うか、どう更新するか、プロジェクトの変更を本番保守の変更とどう分けておくか。
7. テストデータ。 データの出どころ、マスキングの方法、ラウンド間の更新方法。私のSAPテストデータ管理のガイドで詳しく解説しています。
8. 不具合管理。 重大度の定義、トリアージの頻度、優先度を決める人、重大度ごとの目標修正時間。
9. ツール。 テストケース、結果、不具合、承認をどこで管理するか。記録のシステムは1つにします。
10. 自動化のアプローチ。 どのテストを自動化し、どれを手動のままにするか、そしてその理由。
11. 報告。 週次のテストレポートで何を示し、誰が受け取るか。
12. カットオーバーと本稼働の基準。 カットオーバーチェックリスト、それを証明するリハーサル、そして本稼働可否を判断する人。
13. リスクと前提条件。 テスト担当者の確保、環境の日程、データの準備状況、第三者への依存。

ツールについては、新しいプログラムではSAP Cloud ALMが標準です。SAPはSAP Cloud ALMに個別のライセンスは不要と明言しています。Enterprise Supportに含まれており、そのテスト管理アプリで正式なテストケース、実行、結果を管理します。

SAP Solution Manager 7.2は今も多くのプログラムで使われていますが、そのメインストリームメンテナンスは2027年末に終了します。自動化については、SAPがCloud ALMと連携するSAP Test Automation by Tricentisを販売しています。より広い選択肢は、私のSAPテストツールの比較で解説しています。

私が最もよく目にするテストの失敗は、UATとSITでのテスト不足です。

よくある仕組みはこうです。構築が遅れ、本稼働日は固定されたままで、計画の最後にあるテストサイクルから週が削られていきます。

その原因となるパターンと、それぞれへの対処は次のとおりです。

1. 単体テストが終わる前にSITが始まる。 最初のSITのラウンドが単体テストのラウンドになってしまいます。開始基準を守ってください。
2. UATが2〜3週間で計画される。 業務ユーザーは、その期間では通常業務と並行して十分にテストできません。最低でも6〜8週間を計画し、テスト担当者を通常業務から外してください。
3. インテグレーターが業務部門の代わりにUATを行う。 スクリプトは合格し、業務部門は本稼働後にギャップを見つけます。UATの責任はプロセスオーナーに置いてください。
4. テストが小さな予算項目として扱われる。 工数の約35パーセントを占めるテストに、その何分の一かの予算しかなければ、真っ先に削られます。
5. 終了基準がサイクルの途中で書かれる。 結局、チームが達成したものに合わせた内容になります。Realizeの前に書いてください。
6. 本稼働をチェックリストではなく自信で判断する。 何が合意されたのか誰も示せないので、何が欠けているのか誰も言えません。

最後の点は、私が譲らないものです。私の本稼働の基準は、業務部門、IT部門、インテグレーターと事前に合意した詳細なカットオーバーチェックリストです。

そこには、技術的な手順、データロード、照合、業務での検証、インターフェースの切り替え、ユーザーアクセス、本稼働可否の判断ポイントが含まれます。完了して承認されていない項目があれば、日付が何であれ、プログラムの準備はできていません。

Realizeが始まる前に、テストマネージャーにテスト戦略書を求め、上の構成案と照らし合わせてください。UATの責任者が指名されていない、UATが6〜8週間未満になっている、サイクルごとの開始基準と終了基準がない、といった場合は、まずそこを直してください。

テスト戦略や本稼働チェックリストについて独立したレビューが必要であれば、私はこうした支援を行っています。こちらからご連絡ください。

S/4HANAのテスト戦略とは何ですか？

どのテストサイクルを、どの順序で実施し、誰がそれぞれに責任を持って承認し、どのような証拠があればプログラムが次のサイクルに進めるのかを決める計画です。S/4HANAプログラムでは通常、単体テストとストリングテスト、SITのラウンド、UATのラウンド、回帰テスト、データ移行テスト、カットオーバーリハーサルをカバーします。

S/4HANAプログラムのうちテストはどれくらいを占めますか？

私が計画するプログラムでは、テストがプログラム工数の約35パーセントを占めます。最初からその水準で予算を組んでください。予算が不足したテストは、構築が遅れたときに真っ先に削られるからです。

S/4HANAプロジェクトのUATにはどれくらいの期間をかけるべきですか？

最低でも6〜8週間です。業務側のテスト担当者は通常業務と並行してUATを行い、最初のラウンドの修正を再テストできるよう、複数のラウンドをこなす時間が必要です。

SAPのユーザー受入テストの責任者は誰であるべきですか？

業務部門です。指名されたプロセスオーナーを通じて責任を持ちます。システムインテグレーターはスクリプトの準備、環境の管理、不具合の修正はできますが、システムが自分たちに合っていることを確認できるのは、そのプロセスを実際に回している人だけです。

SAPテストの開始基準と終了基準とは何ですか？

開始基準は、サイクルを始める前に必要な条件です。たとえば、単体テストの完了、環境の構築、テストデータのロードです。終了基準は、サイクルを終える前に満たさなければならない条件です。たとえば、スクリプトの実行、未解決の重大な不具合がないこと、プロセスオーナーの承認です。どちらも、はい、いいえで答えられ、指名された承認者がいるべきです。

S/4HANAの本稼働チェックリストには何を含めるべきですか？

技術的なカットオーバーの手順、データロードと照合、業務での検証、インターフェースの切り替え、ユーザーアクセス、本稼働可否の判断ポイントです。事前に合意し、模擬変換または本番さながらのリハーサルで予行演習し、すべての項目が完了して承認されたときだけ本稼働してください。