１. はじめに
私は現在、SAP Public Cloud の導入案件における設計・テストに携わっています。
その中で、結合テストや回帰テストの重要性を強く感じる一方で、「SAP界隈には自動テストの文化がまだ根付いていない」 という現実に直面しました。
特に以下のような課題があります：
複数のアドオンや標準機能をまたいだ結合テストが必須
例：受注伝票の登録 → 出荷 → 請求 → 独自アドオンの実行、といった一連の業務フローの確認。
テストは多くが手作業に頼っている
テスト担当者が Fiori アプリや SAP GUI を操作しながらチェックするため、工数が大きく、ヒューマンエラーも発生しやすい。
（特に、スクリーンショットをひたすら貼り付ける作業は本当に苦痛です……）
こうした背景から、私は 「SAP特化の自動テストツール」 の必要性を強く感じました。
ただし、既存のテストツール製品を導入するかどうかはプロジェクトの方針次第です。
そこで、プロジェクトに依存せず、個人でも気軽に使えるツールを開発するに至ったのが今回ご紹介する取り組みの背景です。
２. 完成したアプリ紹介
コンセプト
「SAP特化」
Fioriを前提としたテストが中心。汎用テストツールより導入障壁を下げる。
「業務フロー単位でのテスト」
「1つのアドオンだけ」ではなく、受注～出荷～請求～アドオン処理といった業務横断の流れをテストできる。
「ノーコード／ローコード的な操作性」
JSONや既存テンプレートを使ってテスト定義できるので、テスト担当者が新たにプログラミングを学ばなくても扱いやすい。
「結果をわかりやすく可視化」
実行結果をHTMLレポート化し、どこで失敗したのかを一目で確認できる。
３. 機能紹介
※個人で使う用なので、UIは手がこんでないです
3-1. 対象のテストシナリオを選択
リストから今回テストしたいテストシナリオを選択します。
3-2. テストケースを選択
第二画面では、テストしたいケースを選択します。
今回は正常ケースをテストしていきたいと思います。
3-3. テスト実行画面
第三画面で実際にテストを実行していきます。
特徴は、単なるログ表示ではなく、フロー図を使ってテストの進行状況を視覚的に確認できる点です。
どのノード（処理ステップ）が実行中か、成功したのか、エラーで止まったのかが一目でわかるので、
「テストケースがどこで失敗したのか」を直感的に把握できます。
3-4. 実行してみる
「フローを実行」ボタンを押すと、左側のフロー図に沿ってノードが順番に処理されていきます。
右側には実行ログがリアルタイムで表示され、例えば「受注伝票登録が成功し、番号1000000001が発行された」といった具体的な結果も確認可能です。
3-5. テスト結果を確認
実行が完了すると、結果は HTMLレポート として自動生成されます。
この仕組みは内部で Robot Framework を利用しており、その標準機能を活用しています。
レポートには以下の情報が含まれます：
・ステップごとの実行結果（成功／失敗を色分け表示）
・実行ログやエラーメッセージ
・発行された伝票番号などの詳細情報
・実行全体の統計（成功率、処理時間 など）
・スクリーンショット（Robot Framework が自動でキャプチャ）
3-6. スケジュール機能
本ツールでは、作成したテストをスケジュール実行する機能も備えています。
・毎日決まった時間に定期的な実行が可能
・実行結果は HTML レポートと Fiori アプリの履歴に自動保存
・エラーが発生した場合は履歴からすぐに原因を確認できる
これにより、開発フェーズだけでなく 本番稼働後の継続的な品質チェック（回帰テスト） にも対応できます。
４. SAP特化な点
本ツールはSAP特化を意識して設計しています。
具体的には以下のポイントがあります：
「Fiori UIの自動操作に対応」
ログイン → アプリ起動 → フィルター設定 → 伝票登録 → 明細確認、といった業務ユーザーが日常的に行う操作を自動化。
SAP標準アプリやカスタムFioriアプリも対象にでき、手作業テストをそのまま置き換え可能。
「実行履歴をFioriアプリに保存」
RAPで作成したカスタムFiori appにて実行履歴を確認可能です。
HTMLレポートだけでなく、SAP上で履歴を一元管理でき、メンバー間で共有しやすい。
「SAP API連携をサポート」
画面操作だけでなく、OData APIを通じて処理を実行・検証可能。
これにより「画面テスト」と「バックエンドAPIテスト」を組み合わせた実運用に近い検証が可能。
５. 開発してみて
今回開発してみて、あらためてSAP環境での自動テストの難しさを実感しました。
課題1：SAPは画面操作が独特
FioriアプリのUIはモダンですが、入力欄やテーブル操作は一般的なWebアプリと違うクセがあり、自動化に工夫が必要でした。
課題2：テスト結果を業務ユーザーが理解できる形にする
開発者視点のログではなく、「どの伝票番号で失敗したのか」「どの処理が止まったのか」を分かりやすく表示する仕組みが重要でした。
課題3：SAPらしさをどう取り込むか
Robot Frameworkをそのまま使うだけでは「汎用の自動テスト」と変わらないため、
Fiori UI操作対応 や 実行履歴をFioriアプリに保存 する仕組みを加えたことで「SAP特化」にできたと思います。
一方で、自分で作ってみることで「SAPに本当に合ったテスト自動化って何だろう？」と考える良いきっかけになりました。
単なる効率化だけでなく、業務ユーザーにとってもわかりやすいテストの仕組みを作ることが大切だと強く感じています。
６. 今後の展望
今回のツールはまだ試作段階ですが、今後はさらに以下のような機能を拡張していきたいと考えています。
・AIによるテスト品質評価
ABAPクラスのコードやテスト結果を解析し、抜け漏れや品質のリスクを自動でアドバイスできるようにしたい。
・業務ユーザー向けのUI改善
開発者だけでなく、業務担当者も直感的に使えるUIを追求。
「テストはエンジニアのもの」から「チーム全体で使うもの」へ広げていきたい。
初めての個人開発ということもあり試行錯誤の連続でしたが、
「SAPでもここまで自動化できるんだ」という手応えを得ることができました。
この記事をきっかけに、少しでも多くの方に SAPの自動テストの可能性を感じてもらえたら嬉しいです。
ご意見やフィードバックもぜひお待ちしています！