Test Suite から Test Cloud に移行する

このセクションでは、フレックス プライシング プランの Test Suite からユニファイド プライシング プランの Test Cloud (プライベート) に移行する場合の重要な考慮事項と大まかな手順について説明します。

価格について詳しくは、こちらで料金プランを参照するか、担当者にお問い合わせください。

Test Cloud に移行するメリット

Test Cloud (プライベート) にアップグレードすべきかどうか判断できない場合のために、以下に主な利点と考慮事項をいくつか示します。

• Test Cloud (プライベート) は、アプリケーションのテストに特化した専用のクラウド サービスです。Test Cloud (プライベート) は、これまで UiPath® Test Suite で提供されていたテスト機能を拡張します。より広範なオートメーション サービスの一部であった UiPath Test Suite とは異なり、Test Cloud は Automation Cloud に似たクラウド サービスでありながら、アプリケーションのテスト専用に設計されています。これまで、UiPath Test Suite の機能は Automation Suite またはスタンドアロンの MSI 製品の一部として提供されていました。これらの機能は、RPA テストとアプリケーション テストの両方に対応していました。
• 今後は、提供オプションに関係なく、新規のアプリケーション テスト機能はすべて Test Cloud (プライベート) のみでのリリースとなり、UiPath® Test Suite ではリリースされなくなります。UiPath® Test Suite が提供する機能を使用し続けると、アプリケーション テストにおける将来のイノベーションの機会を逃すことになります。
• Test Cloud (プライベート) は、新しいユニファイド プライシング プランでのみライセンスされます。これに対し、UiPath® Test Suite で提供される機能は、引き続き従来のフレックス プライシング プランでのみ利用可能です。つまり、Test Cloud (プライベート) にアップグレードすれば、技術的にも商業的にも将来の UiPath Platform との整合性が保証されます。
• もし IT チームが Test Cloud (プライベート) のセキュリティ レビューについて懸念を抱いていても、心配ありません。Test Cloud (プライベート) は組織に新規に導入するツールではありません。このアプリケーションは、Automation Suite と同じ安全なインフラストラクチャで実行されます。Test Cloud (プライベート) は、同じ安全な基盤上で提供される別のユーザー エクスペリエンスだと考えてください。つまり、Test Cloud (プライベート) に追加のセキュリティ レビューや承認は必要ありません。

ライセンスの移行

Test Cloud にアップグレードするということは、組織をフレックス プライシング プランからユニファイド プライシング プランに切り替えることを意味します。切り替えは即時に行われます。ユニファイド ライセンスが割り当てられ、同時にフレックス ライセンスの割り当てが解除されます。重複期間はありません。両方のライセンスの種類を同じ組織で同時にアクティブにすることはできません。

注:

フレックス ライセンスの割り当てが解除されても、以前の割り当ては組織に引き続き表示されます。ユーザー、ロボット、テナントを新しいユニファイド ライセンスに再割り当てする際に、この情報を参考にすることができます。

切り替え後もフレックス ライセンスに割り当てられたままのユーザーがいる場合は、ライセンスの割り当てを更新するよう求めるメールと製品内通知がすべての組織管理者に一度だけ送信されます。

ライセンスのマッピング

以下の表は、フレックス プライシング プランの Test Suite ライセンスと、ユニファイド プライシング プランの同等の Test Cloud ライセンスとのマッピングを示しています。

フレックス プライシング プラン — Test Suite	ユニファイド プライシング プラン — Test Cloud
ユーザー
UiPath - フレックス - Automation Developer	UiPath - Uni - App Test Developer
UiPath - フレックス - Tester User	UiPath - Uni - App Tester
ロボット
UiPath - フレックス - Unattended Testing ロボット	UiPath - Uni - App Test Robot
プラットフォーム
UiPath - フレックス - Test Management	UiPath - Uni - App Test Platform
UiPath - フレックス - Insights	UiPath - Uni - App Test Platform
UiPath - フレックス - Insights Designer	UiPath - Uni - App Test Platform
消費型
UiPath - フレックス - SAP 移送ユニット	UiPath - Uni - SAP 移送ユニット
対応するライセンスはフレックス プライシング プランにはありません。	UiPath - Uni - テスト実行ユニット
UiPath - フレックス - AI ユニット	UiPath - Uni - プラットフォーム ユニット
UiPath - フレックス - エージェント ユニット	UiPath - Uni - プラットフォーム ユニット
UiPath - Cloud - ロボット ユニット	UiPath - Uni - プラットフォーム ユニット

主な考慮事項

再割り当てプロセスを開始する前に、以下を確認してください。

• ユーザー ライセンス: 切り替え後直ちに、新しいユニファイド ライセンスにユーザーを再割り当てしてください。そうしないと、ユーザーのサービスが中断される可能性があります。
• ロボット ライセンス: Unattended ロボットは、再割り当てするまで引き続きフレックス ライセンスで実行されます。そのため、切り替えによってロボットのワークロードが中断されることはありません。
• 消費可能なユニット数: 組織レベルで利用可能なままで、すぐにテナント レベルで割り当てられることはありません。テナント固有の予算を設定するまで、テナントは引き続き組織全体のプールから差し引きます。

1. ユーザー ライセンスを再割り当てする

ユーザー ライセンスを再割り当てするには、以下の手順を実行します。

1. [管理] > [ライセンス] > [ユーザー] に移動します。

2. 個々のユーザーの場合、[ライセンスの割り当てを編集] を選択し、App Test Developer および/または App Tester を割り当てます。

3. ユーザー グループの場合、[グループ割り当てルールを編集] を選択し、App Test Developer および/または App Tester を割り当てます。

   変更は、保存するとすぐに有効になります。Named User ライセンスは組織全体に適用されるため、テナント レベルでの割り当ては不要です。

注:

ユニファイド プライシング プランでユーザー ライセンスを表示および管理するには、ユーザー ライセンス管理を有効化する必要があります。

2. ロボット ライセンスを再割り当てする

ロボットのキャパシティはテナントごとに配分されます。ロボット ライセンスを再割り当てするには、以下の手順を実行します。

1. [管理] > <テナント> > [ライセンス] に移動し、[割り当てを編集] を選択して、そのテナントの App Test Robot ランタイムの数を入力します。
2. Orchestrator を開き、[テナント] > [マシン] に移動します。
3. マシン テンプレートを編集または作成し、ランタイムの種類を、目的の同時実行数を持つ App Testing に設定します。

3. プラットフォーム ライセンスを再割り当てする

App Test Platform ライセンス (Enterprise ティアおよび Standard ティア) は組織ライセンスです。個々のテナントに割り当てる必要はありません。このライセンスを組織に追加すると、Test Cloud とそのサービス (Test Manager と Insights を含む) は、すぐに自動的に利用可能になります。

App Test Platform ライセンスはいくつかのライセンスを自動的に置き換えます。対象となるライセンスは、UiPath - フレックス - Test Management、UiPath - フレックス - Insights、および UiPath - フレックス - Insights Designer です。

Test Manager をまだ有効化していない場合は、テナントで有効化します。そのためには、[管理] > <テナント> > [サービス] > [サービスを追加] に移動し、[Test Manager] を選択して確定します。

4. 消費可能なユニット数を再割り当てする

利用できる消費可能なユニット数は、購入したライセンスによって異なります。消費可能なユニット数を表示するには、[管理] > [ライセンス] > [消費型] に移動します。

注:

SAP 移送ユニットは、常に単一の組織全体のプールで管理されます。テナントはこの一元的な残数から差し引きます。SAP 移送ユニットに対して個別にテナントの割り当てを設定することはできません。

テスト実行ユニットとプラットフォーム ユニットにテナント固有の予算を設定するには、以下の手順を実行します。

1. [管理] > <テナント> > [ライセンス] > [消費型] に移動します。
2. [割り当てを編集] を選択して、対象のテナントのテスト実行ユニットおよび/またはプラットフォーム ユニットの数を入力します。

移行プロセスを開始する

移行プロセスを開始するにあたってサポートが必要な場合は、UiPath が対応します。最初に必要な作業は以下のとおりです。

担当者に問い合わせる

専任の UiPath® テクニカル アカウント マネージャー (TAM) がいる場合は、まず、移行を計画および実行するためにそのマネージャーに連絡します。TAM がご自身のアカウントに割り当てられていない場合は、UiPath のプロフェッショナル サービス チームがお客様に代わって移行を主導および実行できます。

さらに、UiPath のサポート チームが手順を明確化し、必要なアクティビティとツールのチェックリストを共有できます。ただし、サポート チームは移行そのものは行いません。

移行の初期情報を共有する

移行計画について UiPath に問い合わせる際は、以下の情報をご用意ください。この情報は、UiPath がお客様のコンテキストを理解し、その状況を適切な移行アプローチに素早くマップするのに役立ちます。

• 現在の環境はどこでホストされているか: 使用している提供オプションをお知らせください。
• 現在 UiPath を使用している目的は何か: アプリケーション テスト、RPA/オートメーション テスト、またはアプリケーション テストと RPA/オートメーション テストの両方のどれが目的であるかをお知らせください。
• それらのアクティビティはどこで実行されるか: アプリケーション テストと RPA/オートメーション テストを同じ組織内で管理しているか、それとも別々の組織で管理しているかをお知らせください。
• 移行予定のアクティビティ: Test Cloud へのアプリケーション テストのみを行うのか、それとも RPA/オートメーションのテスト機能も Test Cloud にアップグレードするのかを指定します。

計画と評価

このフェーズの目標は、現在の設定を把握し、移行の範囲を計画することです。

ヒント:

以下に示す大まかな手順のいくつかは、移行を適切に開始するために役立ちます。

• 関係者の意識を合わせ、目標を定義し、成功のメトリックを設定します。
• 現在のアセット (パッケージ、ワークフロー、テスト ケース) の詳細を収集します。
• 何を移行するのか (アプリケーション テスト、RPA/オートメーション テスト、またはその両方) を明確化します。
• 必要なユーザー ロール、アクセス権限、ガバナンスを確認します。
• タスク、所有者、タイムラインを記載した移行ロードマップを作成します。
• 潜在的な課題を特定し、移行戦略の概要を示します。

UiPath Cloud の準備の設定

このセクションでは、Test Cloud (プライベート) の環境を移行に向けて準備する方法について説明します。

• テナントおよび組織構造を設定して構成します。
• 必要に応じて、アクセス ロールとユーザー権限を設定します。
• Test Manager を ALM ツール (Jira や Azure DevOps など) に接続します。
• Test Manager を有効化し、利用可能なライセンスを確認します。
• 現在の設定の環境とフォルダー構造を再現します。
• Automation Suite から移行する場合は、インフラストラクチャをセットアップします。
• ライセンスの割り当てを調べ、プロビジョニングが完了していることを確認します。

アセットとパッケージの移行

次に、再利用可能なコンポーネントとパッケージを Test Cloud (プライベート) に移動します。

• キュー、資格情報、ストレージ バケットなどのアセットのインベントリを作成します。
• 移行から除外する非推奨または未使用のアセットを特定します。
• 移行元の Orchestrator インスタンスからパッケージとアセットをエクスポートします。
• 移行ツールまたは手動の手順を使用して Test Cloud にインポートします。
• 移行後にアセットの値、型、参照を検証します。
• パッケージを移行先の環境に再パブリッシュして相互運用性を確認します。

テスト ケースと成果物の移行

この部分では、テスト ケースおよび関連する Orchestrator 成果物を移行します。

• プロジェクトの エクスポート および インポート 機能を使用して、Test Manager プロジェクトを転送します。
• インポート後にプロジェクトの設定 (連携やロールなど) を再構成します。
• 必要に応じて、テスト ケースを新しい構造で再編成します。
• 該当する場合、テスト ケースが ALM のテスト オブジェクトにリンクされていることを確認します。
• テスト セットを検証し、正常に実行できることを確認します。
• 必要なすべての成果物が移行先の環境で利用できることを確認します。

環境の設定と接続

これらの手順は、ロボットとテスト環境が期待どおりに機能することを確認するために必要な作業の概要です。

• Unattended Testing ロボットを新しい環境にデプロイします。
• ユーザーとロボットを適切なフォルダーに割り当てます。
• 仮想マシンまたはオンプレミスのリソース経由でテスト マシンにアクセスできることを検証します。
• ネットワーク接続を確認し、資格情報へのアクセスをテストします。
• サンプル ワークフローを実行して、ロボットの実行動作を検証します。

検証とテスト実行

次に、テスト実行によって移行を検証する必要があります。

• スモーク テストを実行して、システムの全体的な動作を検証します。
• 移行したテストの期待される結果と実際の結果を比較します。
• 欠落している変数、アセット、または破損した依存関係に対処します。
• 必要に応じて、テスト データのソースと環境の参照を再マップします。
• テスト結果と検証の証拠をレポートに文書化します。
• 結果の概要を共有し、検証が完了したことを確認します。

CI/CD との連携

必要に応じて、以下の手順を実行してテスト オートメーションをパイプラインに統合します。

• CI/CD との連携 (Jenkins や Azure DevOps など) を適宜調整します。
• デプロイ段階でテスト セットをトリガーするようにパイプラインを設定します。
• デプロイ後のテスト検証手順を CI/CD パイプラインに追加します。
• 結果が ALM または不具合追跡システムに同期されることを確認します。
• 再利用のために YAML ファイルまたは構成ファイルのサンプルを提供します。

レポートとテストに関するインサイト

以下の手順は、ダッシュボードとテスト可視化ツールを構築する方法の概要です。

• カバレッジ、合格率、傾向などのレポートのニーズを定義します。
• UiPath Insights またはその他のレポート ソリューションを有効化して構成します。
• テスト アクティビティと結果を可視化するためのダッシュボードを作成します。
• レポートの自動生成と配信の周期のスケジュールを設定します。
• ダッシュボードとインサイトを主要な関係者と定期的に共有します。

引き継ぎと文書化

最後に、移行を確定して長期的に所有できるようにします。そのために、ドキュメントを完成させ、知識の移転を完了し、所有権を引き継ぎます。