公共部門のチームがUiPath戦略をモバイルテストに拡張した方法 

これは実際のお客様の事例です。お客様のプライバシー保護のため、お客様のお名前は伏せております。 

ある公共機関は、厳格な運用要件のある環境で、市民向けモバイルアプリケーションのテストを実施する準備を進めていました。UiPathは既に同機関の自動化戦略の中核を担っており、別途テスト体制を構築することなく、モバイルアプリケーションをその戦略に組み込みたいと考えていました。 

彼らは、実機上でモバイルアプリの検証を行い、自動テストをサポートし、自社の導入およびガバナンス要件に適合するアプローチを見つけたいと考えていました。これらの要素が、彼らがモバイルテストプラットフォームを評価する際の基準となりました。 

確立された自動化戦略におけるモバイルギャップ 

既存の自動化プラットフォームを利用すれば、チームは使い慣れた方法でワークフローを構築できます。しかし、モバイルでは、どのiOSおよびAndroidデバイスを使用するか、自動化をそれらにどのように接続するか、テストで問題が見つかった場合にユーザーがアプリを直接調査できるようにするにはどうすればよいかなど、追加の決定事項が生じます。 

彼らは専用のモバイルテストプラットフォームを導入しておらず、その機能を導入しようとしていた。彼らは、チームにUiPathのワークフローやスキルを放棄させることなく、テスト戦略全体の一部として活用しながら、進歩を遂げたいと考えていた。 

彼らは不足していた機能を追加しようとしており、既存のプロセスと連携できるアプローチを必要としていた。 

要件はデバイスだけでなく、適合性に関するものでした 

実機は、ユーザーが実際に使用するアプリを検証する上で重要でした。また、オンプレミス環境とプライベートクラウド環境の両方を含め、セキュリティとガバナンスに関する期待を満たす展開オプションも必要としていました。 

こうした状況から、単に電話機のリストを選ぶだけでは済まなくなった。チームは、デバイスがどこで稼働するのか、既存の自動化ツールとどのように連携できるのか、誰が環境を制御するのか、そしてそのソリューションが社内の承認プロセスに適合するのかどうかを理解する必要があった。 

導入要件は、ラボの運用者にも影響を与えた。プライベートホスティング環境では、プロバイダーがインフラストラクチャを管理し、組織は専用デバイスを利用できる。オンプレミスラボでは、物理環境は顧客自身が管理する。両方の選択肢があることで、チームは単一のホスティングモデルから逆算するのではなく、独自の制約に基づいてモバイルテストを評価できる。 

Digital.ai 検査を実施 実機アクセス (NAIST) と これらの展開の選択肢UiPathモバイルワークフローはAppiumを介してデバイスに接続できます。 Digital.ai テスト。この組み合わせにより、チームはモバイル向けに全く新しいワークフローを構築するのではなく、既存のオーサリング手法にモバイル実行機能を追加する方法を見つけることができました。 

組織が導入したもの 

同組織は、自動化戦略に専用モバイルテストを導入した。 そして、既存のUiPathワークフローをその環境に拡張しながら、手動および自動化の両方で実際のモバイルデバイス上でテストする能力を獲得しました。 

これにより、チームは使い慣れた自動化ワークフローから実機でのモバイルテストへと移行する道筋を見出した。アプリの品質向上とリリースへの信頼性向上は、この取り組みの目的のままだった。すぐに具体的な変化が現れた。モバイル検証が、既存の自動化アプローチに組み込まれたのだ。 

既存のUiPathチームにとって有用なモデル 

UiPathが既に組織内で活用されている場合、モバイル分野への展開にあたって、テストプロセス全体を最初からやり直す必要はありません。まず、重要なモバイルジャーニーと実機を特定します。次に、ワークフローがそれらのデバイスにどのように到達するか、そして環境が満たすべき展開条件とガバナンス条件を確立します。 

このチームが辿った道はこうだ。UiPathは彼らの自動化アプローチの一部であり続け、 Digital.ai 彼らが必要としていたモバイルテスト環境を提供した。  

同様の動きを検討中ですか？ お問い合わせ 既存のワークフロー、デバイスの対応状況、導入要件について話し合い、貴社チームに合わせたモバイルテスト戦略がどのようなものになるかを検討します。