テストオートメーション

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

アプリケーションテスト

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

RPA テスト

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