UiPathで自動化処理を作っているが、安定しないと嘆いている方いませんか？
使っていると、よくエラーが起きて止まってしまう場合は、テストが足りていないと思います。
RPAコンサルタントとしてプロコアラは多くの企業にRPAを導入していますが、テストが十分でない環境ではRPAを広めた後には地獄が訪れます。
元々C言語を使った組み込みエンジニアであり、プログラミングを新規に作成、修正した場合はテストが必須の環境にいたため、RPAのテストは不足していると感じています。
プログラミングをしている人なら分かると思いますが、テストを十分にしていないコードが運用されており、自動化テストも整っていない環境をイメージすれば分かりやすいと思います。
RPAの場合は、簡単に処理が作れるため、広がるときは爆発的に広まっていきます。テストが十分に考慮されていないとエラーが頻出してしまい、エラーの除去に工数がかかり、ROI（投資対効果）が上がらない要因にもなってしまいます。
RPAはプログラミングです。
プログラミングはテストによって品質を向上させることができます。
それならばRPAもテストで品質を向上させるべきですよね。
この記事を見ることによって、RPAでのテストの必要性が分かり、UiPathでどのように行えばいいか分かるようになります。
単体テストと結合テストの2つを紹介します。
単体テスト
単体テストはV字モデルでいう詳細設計に対応するテストです。
RPA、UiPathでユニットをどの単位にすべきかですが、これはXamlファイル単位のプロセスで考えるべきだと思います。
ホワイトボックステストとブラックボックステストがあります。
ホワイトボックステスト
ホワイトボックステストとは、どのような処理をやっているか分かっている人が行うテストです。
パスチェック（網羅チェック）
パスチェックとは、作成したプログラムをどの程度網羅して実行できたかを確認するテストです。作成したプログラムで一度も実行したことない場合、その部分がバグにならない保証はないですよね？ということで、一度動かしておこうぜというテストです。
他にもあるのですが、C0、C1、C2を意識しておけばいいと思います。
C0カバレッジ（命令網羅）
作成したプログラミングが1回は通ることを確認するテストです。
C1カバレッジ（判定網羅）
判定とはIF文の真偽のことを言います。判定網羅とはIF文があった場合に真偽を確認しましょうというテストです。
IF（A>0 AND B>0）というIF文があった場合、以下のように判定の真偽が確認できるパラメータであれば内部は何であっても構いません。
・A=10、
・A=-10
よって、C1カバレッジでは、Bの値はテストしなくてもよくなりません。
C2カバレッジ（条件網羅）
条件とはIF文の中のパラメータを全て確認するテストです。
IF（A>0 AND B>0）というIF文があった場合には、以下の2ケースがあればいいです。
・A =10、B=-10（判定は偽）
・A = -10、B=10（判定は偽）
C2カバレッジでは、判定は網羅する必要はありません。
UiPathでワークフロー作る場合、ワークフロー上のアクティビティは全て実行するようにします。
トライキャッチの中のアクティビティも対象となるため、エラーが発生する場合としない場合もテストすべきです。
条件網羅アクティビティで判定の真偽どちらもチェックするようにすべきです。
ブラックボックステスト
ブラックボックステストとは、どのような処理をやっているか分からなくても実行できるテストです。
プロセス（Xamlファイル）の中が何をやっているか分かっていなくても、引数を入れた場合にどんな結果が返るのかテストします。
プログラミングの開発では、詳細設計で関数設計書というものを作って引数と戻り値に何があるかという関数インターフェースを定義しておきます。
RPAもテストをやるうえで必要なので、部品となるプロセスを作成する際に引数と戻り値はドキュメントとして整理しておくべきですね。
これが無いとテストができないですから。
ブラックボックステストの例
名前を入力して、Webの社内アドレス帳から社員番号とメールアドレスを取り出すプロセスを作成する場合を例として考えます。
プロセス設計
プロセス作成時に、以下の情報は定義しておきます。
通常、業務ワークフローを明確にしていく中で、プロセスに分割してこの情報をプロセスごとに作成します。
実際に作成する前にレビューしてもらい作るという流れが一般的で手戻りが少なくなります。
引数と戻り値は以下のようになります。
| 引数 | 概要 | |
| In | Name | 検索する社員の名前 |
| Out | MailAddress | 社員のメールアドレス |
| Out | EmployeeNumber | 社員番号 |
テスト設計
プロセス設計にしたが、ワークフローを作成後はテストを行います。
今回のケースでは、引数は以下の3通りを評価しておくべきです。
(1) Nameが存在する場合（正常系）
(2) Nameが存在しない場合（正常系）
(3) Nameが空の場合（異常系）
テストケース毎に期待値を作成します。
| No. | Name 入力値 |
例外 | MailAddress 期待値 |
EmployeeNumber 期待値 |
| 1 | Tanaka Taro | 無し | Taro.Tanaka@hogehoge.com | 1205 |
| 2 | Sonzai nashio | 無し | ”” | ”” |
| 3 | 空 | 有り | — | — |
テスト実施
実際に動かしてみて、確認します。
Mainワークフローとは別に、作成したプロセスだけを呼び出すテスト用のプロセスを作成します。
Xamlを呼び出す際に、引数にテストパターンを設定します。
例外が発生したか、戻り値の期待値と実際の値が等しいかを確認します。
ReFrameworkには例外の有無を確認しやすいテストフレームワークがあるので活用しましょう。
UiPath Goには引数と戻り値を確認できる便利なテンプレートがありますので、こちらも利用可能です。
自動化テストの効果
自動化テストを作成しておくことは、工数がかかってしまいますが品質を担保するためには重要なことです。
工数の観点からも、長期的に考えると工数削減になると考えています。
RPAは、Windows、Office、使用するシステムなどと密接に関連して実行されるという性質を持っているため、Windows、Officeアップデート時に、自動化処理が動かなくなる可能性があります。
この際に、自動化テストがあれば、このアップデート作業を効率化できます。
エラー発生時にも原因究明に使えますし、全体では工数削減になるのです。
この自動化テストの仕組みを作っていないとRPAが社内で普及してしまったときにエラーが頻発したときに人海戦術しか取る道が無い悲しいことになってしまいます。
プロコアラ的ベストプラクティス
ReFrameworkなどのフレームワークを使用します。
ReFrameworkには例外の発生を確認するテストフレームワークがあります。
また、UiPath Goには、引数と戻り値を確認することができるテストフレームワークがあるので、組み込んでさらに詳細にテストができるようにした方がいいでしょう。
RPAを広げていく上では、情報システム部や外部のRPA業者グループと業務担当者グループがどちらもワークフローを作成していきます。
業務担当は業務は分かるがプログラミングは分からない。
情報システム部は、業務は分からないがプログラミングは分かる。
このために、両者が協力してRPAで効率化していく必要があるのです。
どこで線引きをすべきか、プロコアラの考えはこうです。
業務担当は、プロセスのみを作成する。
情報システム部は業務担当が作成したプロセス（Xamlファイル）をReFrameworkテンプレート、あるいは更に改良したテンプレートに組み込む。
ただし、プロセスの引数と戻り値というインターフェースについては、テストをしやすいように情報システム部が検討する。
こうすることで、業務担当はテンプレートの難しいステート遷移などを覚えずに済み、RPAが広まりやすくなります。
また、テンプレートを共通化することができるので、品質を担保できます。
RPA、UiPathについて動画形式で学べるコアワカのUdemy講座を
いつでもお得な価格で受講できるクーポンを発行しています。
研修にも使用できる書籍もこちらから購入が可能です。
動画を受講したい場合はボタンをクリックしてください。
クーポンコードが適用されたUdemyコースのリンク一覧ページに移動します。
