Test Automation のベスト プラクティス
最大限効果的なテスト作業とするために、アプリケーション テストであるか RPA テストであるかに応じて、以下のテスト オートメーションのベスト プラクティスを検討します。
- 各テスト ケースは互いに独立している必要があります。あるテスト ケースを実行するために別のテスト ケースの実行が必要になる状況が発生しないようにします。
- 1 つのテスト ケースに設定する具体的な目的は 1 つのみとします。各テスト ワークフローで実行する検証は 1 つのみとします。
- 機能ごとに単体テストを行います。例外を許可する場合は、テスト ケースごとに別々のテストを作成します。
- Given-When-Then のテスト ケース構造で、特定の部分の範囲が広すぎて管理しにくい場合は、テスト ケースの再定義を試みてください。より詳細な設定やリファクタリングが必要なことがあります。
- 現在のテスト ケースを維持し、変更リクエストがあれば更新します。
- テスト ケースの定義方法が 1 つのみとなるようにテストの管理ロジックを構築することを検討します。
- 個々のテスト プロジェクト間、およびテスト プロジェクトと RPA プロジェクト間で高い再利用性を実現するには、可能な限り、ライブラリとオブジェクト リポジトリを使用します。
- CI/CD パイプラインにテストを追加します。
- ビルドに遅れが発生しないように、CI パイプラインの過程で機能テストを可能な限り早期に実行する必要があります。したがって、できる限り多くのロボットで、これらのテストを並列実行します。
- アクティビティ名は、実行するアクションがわかるようなものとします。分かりづらいアクションについては、アクティビティに注釈を追加することを検討します。
- 詳細なログと例外処理を使用してプロセスをデバッグし、バグの検出漏れの発生を防止します。
- 失敗を回避するために、各ステージでエラーから回復する計画またはリトライする計画を作成します。
- テスト専用のフォルダー構造を使用すること、および各プロジェクトにわたって同じテスト ケース命名規則を使用することを検討します。
- 変更の可能性が高く、使用頻度が高い変数には、アセットを使用します。
- プロセスの特定のステップに進む前に、アプリケーションの状態を検証する必要がある場合は、検証方法を適用することを検討します。検証方法では、他のインタラクションの前に、アプリケーションが望ましい状態になるまで待機する追加のアクティビティを使用できます (ハードコードされた待機時間は適切な方法とは見なされません)。
- 可能な限り、模擬的なクリック操作や入力操作、Windows メッセージの模擬的な送信動作の使用を検討します。
- Studio 以外でテスト ケースの削除、移動、名前変更をしないようにします。これらの操作は、Studio でのみ実行します。参照先とする他のプロジェクトのテスト ケースがある場合は、[テスト ケースをインポート] を使用します。
- 各テスト ケースは互いに独立している必要があります。あるテスト ケースを実行するために別のテスト ケースの実行が必要になる状況が発生しないようにします。
- できる限り少ない数のアクションを扱う、小規模なワークフローの作成を検討します。これにより、単体テストがわかりやすくなり、実行しやすくなります。
- 1 つのテスト ケースに設定する具体的な目的は 1 つのみとします。各テスト ワークフローで実行する検証は 1 つのみとします。
- 機能ごとに単体テストを行います。例外を許可する場合は、テスト ケースごとに別々のテストを作成します。
- 個々のテスト プロジェクト間、およびテスト プロジェクトと RPA プロジェクト間で高い再利用性を実現するには、可能な限り、ライブラリとオブジェクト リポジトリを使用します。
- Given-When-Then のテスト ケース構造で、特定の部分の範囲が広すぎて管理しにくい場合は、テスト ケースの再定義を試みてください。より詳細な設定やリファクタリングが必要なことがあります。モジュール性は、優れた単体テストを実現するための要点です。テストの書き込みが、開発でのフィードバックやコード レビューとして機能することがあります。
- テスト ケースの目的とは関係のない複雑なステップがあり、それが置き換え可能な場合は、モックを使用します。
- テスト ケースの定義方法が 1 つのみとなるようにテストの管理ロジックを構築することを検討します。
- 現在のテスト ケースを維持し、変更リクエストがあれば更新します。
- CI/CD パイプラインにテストを追加します。
- RPA の内容を変更する場合は、必ずテスト ケースを実行して、バグが発生しないことを確認します。
- 環境変更 (Windows Update など) の展開を計画する場合は、運用前環境で IT 部門が実行できる RPA テスト セットを作成し、運用環境に展開する前に潜在的な問題を把握できるようにします。
- アクティビティ名は、実行するアクションがわかるようなものとします。分かりづらいアクションについては、アクティビティに注釈を追加することを検討します。
- 失敗を回避するために、各ステージでエラーから回復する計画またはリトライする計画を作成します。
- テスト専用のフォルダー構造を使用すること、および各プロジェクトにわたって同じテスト ケース命名規則を使用することを検討します。
- 変更の可能性が高く、使用頻度が高い変数には、アセットを使用します。
- プロセスの特定のステップに進む前に、アプリケーションの状態を検証する必要がある場合は、検証方法を適用することを検討します。検証方法では、他のインタラクションの前に、アプリケーションが望ましい状態になるまで待機する追加のアクティビティを使用できます (ハードコードされた待機時間は適切な方法とは見なされません)。
- 可能な限り、模擬的なクリック操作や入力操作、Windows メッセージの模擬的な送信動作の使用を検討します。
- Studio 以外でテスト ケースの削除、移動、名前変更をしないようにします。これらの操作は、Studio でのみ実行します。参照先とする他のプロジェクトのテスト ケースがある場合は、[テスト ケースをインポート] を使用します。
このページでは、特定のテスト シナリオに基づいて、有人オートメーションの RPA テストを実行する方法について説明します。
|
テストを実行するユーザー |
テスト手順 |
テスト結果のキャプチャ |
ライセンス要件 |
|---|---|---|---|
|
• 手動テスター • UAT または業務の内容領域専門家 (SME) |
|
UAT のテスターは、スクリーンショットやドキュメントを含む結果を Test Manager で確認できます。 |
UAT のテスターには Attended Automation ライセンスが必要です。ライセンスは、デプロイの種類に応じて管理できます。 • オンプレミス 次の 2 つのシナリオが考えられます。 • UAT のテスターに Attended Automation ライセンスが割り当てられている Orchestrator の運用環境にオートメーション パッケージをパブリッシュします。 • Attended User ライセンスのサブセットを Orchestrator の非運用環境に割り当てます。 |
|
テストを実行するユーザー |
テスト手順 |
テスト結果のキャプチャ |
ライセンス要件 |
|---|---|---|---|
| Testing ランタイム |
