RPA開発におけるテストの自動化と継続的インテグレーション：テストドリブン型のRPA開発のススメ（終）

RPAの品質向上、運用コスト削減につながるテストファーストなRPAにおける開発アプローチを紹介する連載。今回は、RPA開発におけるテストの自動化と継続的インテグレーションについて解説する。

[井上秀和，UiPath]

　RPA（Robotic Process Automation）の品質向上、運用コスト削減につながるテストファーストなRPAにおける開発アプローチを紹介する本連載「テストドリブン型のRPA開発のススメ」。第1回、第2回の連載で、テストドリブン型のRPA開発の概要と、UiPathを例にしたその実践方法を理解できたと思います。

　連載最終回となる今回は、テストドリブン型RPA開発の発展系として、テストの自動化と継続的インテグレーション（CI：Continuous Integration）を紹介します。

継続的インテグレーション

　テストドリブン型の開発が軌道に乗ったとすると、その次に期待されることは継続的にそのテストが実行されることです。連載初回で述べたように、RPAは、「外的環境の変化に弱い」という弱点があります。作成したテストを、定期的に実行することでその変化を、運用者としていち早く捉えられる仕組みを考えます。

　要はCIの考えをRPAへ適用したものです。次のようなアーキテクチャが期待されます。

テストの自動化

　CIの実践の前に、前回テストドリブン型開発で作成した、Webサイトスクレイピングのサンプル向けテスト用ワークフロー全てを一括で実行し、結果を確認する方法を紹介します。

　そのためのワークフローは、「Robotic Enterprise Framework」という「UiPath Studio」にビルドインされているテンプレートに格納されています。UiPath Studioで、Robotic Enterprise Frameworkのテンプレートを選択して、適当なプロジェクトを作成します。

　エクスプローラーで、適当に作成したプロジェクトのフォルダを参照すると、「Tests」というフォルダがあります（UiPath Studioのバージョンによっては、「Test_Framework」というフォルダです）。この中に、テスト自動化のためのワークフローとテスト用ワークフロー管理用のExcelファイルが含まれています。これを、自身の開発中プロジェクトのフォルダへコピーします。

　UiPath Studioで開発中プロジェクトに追加した「Tests」を確認します。プロジェクトパネルの更新ボタンをクリックすると、コピーした「Tests」が出現します。

　このテスト自動化ツールを利用し、設定を進めていきます。「Tests.xlsx」ファイルは、テスト用のワークフローを指定するための設定ファイルです。

　「WorkflowFile」のカラムにはテスト用ワークフローのファイルパスを入力します。

　「ExpectedResult」カラムには、そのテストがどのように終わるかを選択します。例えば、「DownloadEvent_Normal_File_Test.xaml」については、正常に終了することが期待されるので、「Success」と設定します。

ExpectedResult	種類	説明
Success	正常終了	テスト用のワークフローが正常終了することを期待
BusinessException	ビジネス例外	テスト用のワークフローがビジネス例外（BusinessRuleException）で終了することを期待
SystemException	システム例外	テスト用のワークフローがシステム例外（BusinessRuleException以外の例外）で終了することを期待

　「RunAllTests.xaml」は、テスト自動化のためのワークフローファイルです。「Tests.xlsx」の「Tests」シートに基づいて、それぞれのテスト用ワークフローを実行し、実行結果がExpectedResultの通りになれば、そのテストはパス、異なればNGと仕分けられます。

　以上で事前準備は完了です。「RunAllTests.xaml」を実行してみます。UiPath Studioで「RunAllTests.xaml」を開いた状態で、「ファイルを実行」から処理を開始します。

　Excelファイル「Tests.xlsx」に記載されたテスト用のワークフローが全て実行され、実行結果のサマリーが、テキストで出力されると思います。

　作成したテスト用のワークフロー5件全てが、PASSする結果となりました。

　Excelファイル「Tests.xlsx」についても、「Result」シートにそれぞれのテストケースに対してテスト結果とステータスが記載されます。

　これで、今回の業務自動化におけるワークフロー単位での単体テストが、ワンクリックで全て実行できるようになりました。

CIの実践

　テストドリブン型の開発により、サブルーチン化した自動化処理は、全てテスト用のワークフローが作成された状態となりました。また、テスト自動化ワークフローにより、そのテストは一括で実行できる状況です。ですが、CIを実践するためには、前回作成したワークフローを少しだけ変更する必要があります。

CIに向けた改修

　まず、「Main.xaml」を以下のように構成し、外部からインプットパラメータを受け付ける作りにします。インプットパラメータでは、テストモードのフラグを受け渡しできる仕組みとし、通常時の業務自動化処理とテスト時のテスト自動化の実行をパラメータで制御可能なものとします。

　加えて、テスト件数とそのうちの成功数と失敗数をアウトプットとして出力する作りとします。成功数と失敗数は、テスト自動化ワークフローでカウントされているもので、こちらを使用します。

方向	引数名	型	既定値	説明
入力	IsTestMode	Boolean	False	OCテストモードのフラグ
出力	TotalNumberOfTests	int32	-	テストワークフロー総件数
出力	PassedNumberOfTests	int32	-	テストワークフロー成功（PASS）件数
出力	FailedNumberOfTests	int32	-	テストワークフロー失敗（FAIL）件数
出力	TestStatus	String	-	テスト結果

　「RunAllTests.xaml」についても同様の引数を追加し、ワークフローの最後におのおのの値を受け渡してもらうようワークフローを改修します。

引数の設定

ワークフローの改修箇所

　これでワークフロー側の準備は完了です。

パッケージと自動実行

　作成した全てのワークフローをパッケージ化し、これをUiPathのサーバ製品である「Orchestrator」へアップロードします。ポイントとしては、プロセスを生成する際に、入力パラメータの「IsTestMode」をTrueと設定することです。この設定により、このプロセスはテスト自動化を行うジョブとして稼働させることが可能となります。本来の自動化を行う際には、何も設定する必要はなく、「IsTestMode」は既定値のFalseとなります。

　試しにジョブとして実行すると、出力パラメータの値が適切に取得できることが分かります。

ダッシュボード

　ここまでで、定期的かつ自動で、テストを実施できるようになりました。目的の通り、特定の実行環境や、自動化対象のアプリの変化、いわゆる外的要因が発生した際には自動的に検知することが可能です。RPAにおけるCIの第一歩になるのではないかと考えます。

　下の画像は、CIなどで有名なアプリケーションの「Jenkins」風にテスト結果をダッシュボードとしてビジュアライズしたものです。テストがPASSした場合はお天気マーク、FAILでテストが幾つか失敗した場合は曇り、全て失敗した場合は雨マークとしています。

　CIを進めていくときは、このようなインテグレーションも選択肢の一つになると思います。

コラム　RPAに限らず、新しい技術にチャレンジするには

　余談ですが、RPA業界の人間として、RPAの勢いや進化は驚くべきものであると日々、肌身で感じています。しかしながら、これと同等、もしくはそれ以上にIT業界でのコンテナ技術やWebフロントエンド開発の進化もすさまじいものです。便利なものとは分かりつつ、食わず嫌いで、自分がよく知らないものにチャレンジすることは至難のことです。

　今回、私自身もチャレンジとして、あえてDockerコンテナ上でWebフロントエンド開発の手法を用いて、このダッシュボードを作成してみましたが、あらためて「新しいものに挑戦する」というのは大変だと身に染みました。おそらく、RPAにチャレンジしている方々の中にも、RPAに対して同じ思いを抱いている方が多いのではないかと思います。

　ただ、新しいものにチャレンジすることは、学びがあり楽しいものでもあります。助言とまではいきませんが、使いこなすに当たっては、「取りあえずやって見ることだ」と私は思います。

連載の終わりに

　最近、「Disrupt（ディスラプト）」という言葉をよく聞きます。ビジネスの世界においては、「破壊による変革やイノベーション」といった意味で使われるものです。代表的なものとして、自動車業界における自動運転技術が挙げられます。この技術が実用化された場合、われわれは新しい技術の恩恵を得られる一方で、運転に関わる仕事の雇用は大きく変わることが想像できます。

　その自動車においても、100年程前の馬車が交通における主役だった時代、蒸気自動車が登場し馬車に関する仕事に携わっていた職人たちの仕事を奪いました。その職人たちは自動車の整備などの仕事に従事していたようです。

　AIやRPAによって「どの仕事がなくなるのか」などとよく言われますが、RPAを使ってオフィス業務を効率化する場合、それも一つのDisruptです。場合によっては、RPAによってものすごい改善が実現できる可能性も秘めていると思います。

　われわれは現在、100年に一度の変革期に生きており、将来を作っていく側でもあります。今回の連載では、テストドリブン型開発というプリミティブな方法論ではありますが、筆者が「今後重要となるだろう」と予測した考え方の一つを紹介したまでです。読者の皆さまに少しでもお役に立てれば幸いです。

　最後に、皆さまのRPA処理が安定化することをお祈りし、本連載を終わりとさせていただきます。

筆者紹介

井上秀和

データスクレイピング、データマイニング、UIオートメーションをRuby、Python、そしてUiPathで行うことを得意とする。オブジェクト指向を好み、デスクトップOSは、昔Solaris、ちょっと前Ubuntu、最近macOSを愛用。

IT業界で、プログラマー、プロジェクトマネジャー、ビジネスアナリスト、コンサルタントといった役割で、モバイルアプリやWindowsアプリ、Webアプリ、トレーディングシステムの開発、構築、および業務改善に従事。現在は、RPA業界で業務自動化をライフワークとしている。