TestArchitectを使用すると、CやJavaやPython言語のような面倒な文法や、複雑な記述を覚えたりする必要はありません。
テストの定義は、日本人が慣れ親しんだExcelライクなユーザインターフェースで作成できます。
1つのテストスクリプトはプラットフォームやハードウェア構成に依存せず走らせることができます。
TestArchitectはあなたのマニュアルテストケースをそのまま自動化できる可能性を持っています。
主な機能
- 最小のコード量で自動化作成
- レガシーアプリケーションのテスト
- 自動テスト結果の分析
- データベースのテスト
- CI/CDツールとの統合
- Webサービスのテスト
TestArchitectを
採用する３つの理由
- SAP GUI, Fioriへの完全対応
- 複数OSへの対応
- メンテナンスコストの最小化
-
-
![SAP GUI, Fioriへの完全対応]()
SAP GUI, Fioriへの完全対応 -
SAPGUIはWindows標準GUIとは少し異なるインターフェース、FioriはHTML5、JavaScript、CSSといったまたここでも異なる技術を使っています。
今後セキュリティアップデートやパッチなど頻繁にアップデートされるユーザーインターフェス側、自分の作った自動スクリプトが突然動かなくなったり、自動化しようとしたらGUIのコントロールが取れなくなる恐れがあります。
ロジギアではタイムリーにSAPのOSのアップデートに追従し、お客様にご迷惑のかけない製品作りを行っています。
-
-
-
![複数OSへの対応]()
複数OSへの対応 -
SAPのテストを他のプラットフォームと組み合わせることが可能です。
SAP GUIから、Webアプリケーションへの操作を１つのスクリプトで書いたり、FioriインターフェスからWindowsアプリに飛ぶこともできます。
まさにDX時代のテストツールとしてのTestArchitectがあります。
-
-
-
![メンテナンスコストの最小化]()
メンテナンスコストの最小化 -
テストの自動化をする上で一番考えなければならないのが、メンテナンスコストの最小化です。
自動化で失敗するほとんどのケースはメンテナンスコストの肥大化といっても過言ではないでしょう
（余談ですが、導入コストというのは中長期的に考えるとまったく要素にいれるべきではありません）。
-
TestArchitectがSAPアプリケーションのテストの課題を克服するのに
どのように役立ちますか？
| 課題 | TestArchitectソリューション |
|---|---|
|
技術的にも機能的にも、SAPアプリケーションは非常に複雑です。
一部のビジネスシナリオをテストする担当者はテスターはテストスクリプトを書くために強力なプログラミング言語のサポートを必要とします。 |
|
|
手動テストは時間がかかり、非効率的です。
テスト自動化なしでは、Continuous Delivery（CD）は不可能です。 |
|
|
SAP Fioriアプリケーションは、デスクトップブラウザとモバイルブラウザによってレンダリング方法が異なります。
したがって、クロスブラウザテストは必須です。 自動化ツールの中には、クロスブラウザテストをサポートしていないものがあります。 |
|
|
多くの自動化フレームワークにおいて長期的な成功を収めるためには、大規模な自動化スクリプトだけでなく、ソフトウェアアーキテクチャ設計の専門知識も必要です。
この必要なスキルと現存するテスト担当者のスキルのギャップは、SAPビジネスアプリケーション用のテスト自動化ソリューションを展開したい多くの組織にとって大きな障壁となります。 |
|
主な機能
- WindowsおよびWeb上のレガシーSAPGUIのサポートをカスタマイズしました
- Chrome、Firefox、Safari、Edgeなど、すべての主要ブラウザにわたるレスポンシブSAP Fioriアプリの個別サポート
- SAPUI5およびFioriのWeb要素は、XPath、CSSセレクタ、ID、名前など、さまざまな一般的な手法で認識できます
- デスクトップアプリケーションのテスト、Webサービスのテスト、ODBC準拠のDBMSテスト、画像ベースのテスト、PDFテストなどをサポートします
- コーディングなしですぐに再利用できるスマート機能を備えた400以上の組み込みアクションキーワード。
TestArchitectの特徴
ツールによる自動化ステップ
TestArchitectは、“Shift-left”を実現するアクション（キーワード）選択型のテスト自動化ツールです。
以下のようなステップで機械的にスムーズにテストスクリプトが作成されます。
- STEP1
インターフェイスを定義
- STEP2
シナリオを作成
- STEP3
レポート画面まで
レイヤーの管理
「Modules（シナリオ）」「Actions（キーワード）」「Interfaces（UI）」の3つのレイヤー構造となっているため、頻発するインターフェースの変更も、該当部分を変更するだけで、既存シナリオを継続利用できます。
データセットの管理
テストデータの変更・管理にも柔軟に対応します。
アクション選択型（キーワードドリブン）のメリット
「ログインテスト」を例にしたシナリオ作成イメージの比較
コード記述型（複雑であり、可読性がよくない）
アクション選択型（キーワード駆動）（簡潔であり可読性がよい）
ソフトウェアテストにおける基本的な動作をカバーするビルトインアクションを搭載。その他にも、よく使うアクションを登録しておくことで、シナリオ作成時にプルダウンで選択することができます。各テストに必要なデータ値を設定すれば、テストの自動化シナリオが短時間で作成できます。
※コード記述型のシナリオ修正の場合
インターフェース変更時の修正には、該当箇所を検索し、一ヶ所ずつ修正する作業が発生します。担当者によってコードの記述方法が異なりますが、上図の記述であれば、7～10行目を書き換え、以下のコード内に、該当箇所が含まれる場合は、同様に書き換えを行う作業が必要となります。
TestArchitectを使用してSAPアプリケーションを自動化する方法
GUIオブジェクトマッピングの作成
TestArchitectのInterface Viewerを使用すると、テスト担当者はChrome上のWeb要素を検査し、インターフェイスマッピングを作成してそれらを共有リポジトリに保存できます。インターフェイスマッピングの各項目には、特定のWeb要素が変更されたときにテストやアクションのキーワードを更新せずにマッピングを1回で更新できる一意の論理名があります。
TestArchitectのInterface Viewerを使用する以外に、POM Builderという新しいツールを使用することもできます。
POM Builderは、ブラウザの拡張機能としてChromeの内部に存在します。
Interface Viewerと比べて軽量ですが、機能はほとんど同じです。
スプレッドシートのようなテスト開発IDEを使ったテストのオーサリング
TestArchitectのインテリジェントテスト開発IDEを使用して、簡単にテストケースを作成・編集できます。エディタはスプレッドシートのようなインタフェースを持ち、ビジネスシナリオを担当するプログラム経験のないQAスタッフにもなじめる環境を提供します。 アクションは、入力するかドラッグアンドドロップでテストエディタに入力できます。 入力が始まると、エディタは選択可能なアクションのリストを表示し、パラメータの選択と、アクションに応じて期待値の選択を提示します。
アクションを自動化する
TestArchitectでは、組み込みアクションと他のユーザー定義のアクションを組み合わせることによって、ユーザー定義の「アクション」を作成できます。 テスト担当者は、これらのユーザー定義のアクションを使用してアプリケーション固有のワークフローを構築し、それらを結合してより高いレベルのワークフローを作成します。 次にこれらのアプリケーション固有のアクションがビジネスシナリオテストを構築するための構成要素として機能します。これらのテストが変更されたとき、テスト担当者は膨大なテストスクリプト変更することなく、少数のアクションを更新するだけで済みます。 その結果、アクション数が少し増やすだけど、簡易にテスト数を増大させることができます。
チームベースの自動化
TestArchitectは、さまざまなレベルの技術的/ビジネス的背景を持つすべてのチームメンバーの共同作業の自動化プロセスを可能にします。
ビジネスシナリオのテスト担当者は、テストの作成、テストデータの設計、インターフェイスマッピングのキャプチャ、アプリケーション固有のアクションの作成など、その製品ドメインに関する知識を含むほとんどのタスクをカバーします。テクニカルテスターは、すべてのテスト資産の設計と再利用を促進するためにビジネステスターと連携する重要な役割を果たします。 より技術的なスキルを持つテクニカルテスターは複雑なアクションの実装・TestArchitectのアクションライブラリの拡張、およびTestArchitectのCI / CDパイプラインへの統合を支援します。
TestArchitectプロジェクトでは、一人のテクニカルテスターが５人以上もしくは最大10人〜20人のビジネステスト担当者をサポートできます。
