最大限効果的なテスト作業とするために、アプリケーション テストであるか RPA テストであるかに応じて、以下のテスト オートメーションのベスト プラクティスを検討します。

アプリケーション テスト

• 各テスト ケースは互いに独立している必要があります。あるテスト ケースを実行するために別のテスト ケースの実行が必要になる状況が発生しないようにします。
• 1 つのテスト ケースに設定する具体的な目的は 1 つのみとします。各テスト ワークフローで実行する検証は 1 つのみとします。
• 各機能での単体テストは 1 つのみとします。例外を許可する場合は、テスト ケースごとに別々のテストを作成します。
• Given-When-Then のテスト ケース構造で、特定の部分の範囲が広すぎて管理しにくい場合は、テスト ケースの再定義を試みてください。より詳細な設定やリファクタリングが必要なことがあります。
• 現在のテスト ケースを維持し、変更リクエストがあれば更新します。
• テスト ケースの定義方法が 1 つのみとなるようにテストの管理ロジックを構築することを検討します。
• To increase reusability between individual test projects, as well as between test and RPA projects, try to use libraries and object repository, whenever possible.
• CI/CD パイプラインにテストを追加します。
• ビルドに遅れが発生しないように、CI パイプラインの過程で機能テストを可能な限り早期に実行する必要があります。したがって、できる限り多くのロボットで、これらのテストを並列実行します。
• アクティビティ名は、実行するアクションがわかるようなものとします。分かりづらいアクションについては、アクティビティに注釈を追加することを検討します。
• 詳細なログと例外処理を使用してプロセスをデバッグし、バグの検出漏れの発生を防止します。
• 失敗を回避するために、各ステージでエラーから回復する計画またはリトライする計画を作成します。
• テスト専用のフォルダー構造を使用すること、および各プロジェクトにわたって同じテスト ケース命名規則を使用することを検討します。
• 変更の可能性が高く、使用頻度が高い変数には、アセットを使用します。
• プロセスの特定のステップに進む前に、アプリケーションの状態を検証する必要がある場合は、検証方法を適用することを検討します。検証方法では、他のインタラクションの前に、アプリケーションが望ましい状態になるまで待機する追加のアクティビティを使用できます (ハードコードされた待機時間は適切な方法とは見なされません)。
• 可能な限り、模擬的なクリック操作や入力操作、Windows メッセージの模擬的な送信動作の使用を検討します。
• Studio 以外でテスト ケースの削除、移動、名前変更をしないようにします。これらの操作は、Studio でのみ実行します。参照先とする他のプロジェクトのテスト ケースがある場合は、[テスト ケースをインポート] を使用します。

RPA テスト

• 各テスト ケースは互いに独立している必要があります。あるテスト ケースを実行するために別のテスト ケースの実行が必要になる状況が発生しないようにします。
• できる限り少ない数のアクションを扱う、小規模なワークフローの作成を検討します。これにより、単体テストがわかりやすくなり、実行しやすくなります。
• 1 つのテスト ケースに設定する具体的な目的は 1 つのみとします。各テスト ワークフローで実行する検証は 1 つのみとします。
• 各機能での単体テストは 1 つのみとします。例外を許可する場合は、テスト ケースごとに別々のテストを作成します。
• To increase reusability between individual test projects, as well as between test and RPA projects, try to use libraries and object repository, whenever possible.
• Given-When-Then のテスト ケース構造で、特定の部分の範囲が広すぎて管理しにくい場合は、テスト ケースの再定義を試みてください。より詳細な設定やリファクタリングが必要なことがあります。モジュール性は、優れた単体テストを実現するための要点です。テストの書き込みが、開発でのフィードバックやコード レビューとして機能することがあります。
• テスト ケースの目的とは関係のない複雑なステップがあり、それが置き換え可能な場合は、モックを使用します。
• テスト ケースの定義方法が 1 つのみとなるようにテストの管理ロジックを構築することを検討します。
• 現在のテスト ケースを維持し、変更リクエストがあれば更新します。
• CI/CD パイプラインにテストを追加します。
• RPA の内容を変更する場合は、必ずテスト ケースを実行して、バグが発生しないことを確認します。
• 環境変更 (Windows Update など) の展開を計画する場合は、運用前環境で IT 部門が実行できる RPA テスト セットを作成し、運用環境に展開する前に潜在的な問題を把握できるようにします。
• アクティビティ名は、実行するアクションがわかるようなものとします。分かりづらいアクションについては、アクティビティに注釈を追加することを検討します。
• 失敗を回避するために、各ステージでエラーから回復する計画またはリトライする計画を作成します。
• テスト専用のフォルダー構造を使用すること、および各プロジェクトにわたって同じテスト ケース命名規則を使用することを検討します。
• 変更の可能性が高く、使用頻度が高い変数には、アセットを使用します。
• プロセスの特定のステップに進む前に、アプリケーションの状態を検証する必要がある場合は、検証方法を適用することを検討します。検証方法では、他のインタラクションの前に、アプリケーションが望ましい状態になるまで待機する追加のアクティビティを使用できます (ハードコードされた待機時間は適切な方法とは見なされません)。
• 可能な限り、模擬的なクリック操作や入力操作、Windows メッセージの模擬的な送信動作の使用を検討します。
• Studio 以外でテスト ケースの削除、移動、名前変更をしないようにします。これらの操作は、Studio でのみ実行します。参照先とする他のプロジェクトのテスト ケースがある場合は、[テスト ケースをインポート] を使用します。