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 ではリリースされません。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 にアップグレードするとは、組織をフレックス プライシング プランからユニファイド プライシング プランに切り替えることを意味します。切り替えは即時に行われ、統合ライセンスの割り当てとフレックス ライセンスの割り当て解除が同時に行われます。重複する期間はありません。両方のライセンスタイプを同じ組織で同時にアクティブにすることはできません。

注:

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

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

ライセンス マッピング

以下の表は、フレックス プライシング プランでの 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 ロボット
プラットフォーム
UiPath - フレックス - テスト管理	UiPath - Uni - アプリ テスト プラットフォーム
UiPath - フレックス - インサイト	UiPath - Uni - アプリ テスト プラットフォーム
UiPath - フレックス - Insights デザイナー	UiPath - Uni - アプリ テスト プラットフォーム
消費型
UiPath - フレックス - SAP 移送ユニット	UiPath - Uni - SAP 移送ユニット
フレックス プライシング プランには同等のものはありません	UiPath - Uni - テスト実行ユニット
UiPath - フレックス - AI ユニット	UiPath - Uni - プラットフォーム ユニット
UiPath - フレックス - エージェント ユニット	UiPath - Uni - プラットフォーム ユニット
UiPath - Cloud - ロボット ユニット	UiPath - Uni - プラットフォーム ユニット

主な考慮事項

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

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

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

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

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

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

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

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

注:

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

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

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

1. <Your Tenant>[管理] > [ ライセンス >] に移動し、[ 割り当てを編集] を選択して、そのテナントの 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 <Your Tenant>を有効化していない場合は有効化します。[管理] > [サービス を追加] > > に移動し、[ Test Manager] を選択して確定します。

4. 消費状況を再割り当てする

利用可能な消費状況は、ライセンスの注文によって異なります。表示するには、[ 管理 ] > [ライセンス ] > [ 消費状況] に移動します。

注:

SAP 移送ユニットは、常に組織全体の単一のプールで管理されます。テナントは、この集中バランスから引き出され、SAP 移送ユニットに個別のテナント割当を設定することはできません。

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

1. [ 管理<Your Tenant> ] > の [ ライセンス ] > [ 消費状況] >に移動します。
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 またはその他のレポート ソリューションを有効化して構成します。
• テスト アクティビティと結果を可視化するためのダッシュボードを作成します。
• レポートの自動生成と配信の周期のスケジュールを設定します。
• ダッシュボードとインサイトを主要な関係者と定期的に共有します。

引き継ぎと文書化

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