RPAを導入し、業務自動化も軌道に乗り始めた頃にロボットが停止・誤作動してしまう、、、止まってしまった業務の後始末や支障を考えると恐ろしいですよね。
こういった事態を引き起こす不備に事前に気づくため、ロボット開発後にはテストを行う必要があります。円滑な稼働に欠かせないテストの方法や目的をあなたは正しく理解していますか？
本記事ではRPA開発におけるテストの進め方についてお伝えします。最後まで読むことで、テストで注意すべきポイントや開発ごとの最適なテスト方法について知ることが出来ます。
「とりあえずテストは実施しているけれど必要性がわからない」「どの範囲をテストすべき？」といった疑問をお抱えの方は必見です。
目次
テストとは
テストとは成果物の良し悪しや性能を確認するための作業のことです。この段階で成果物のバグの有無、処理終了までにかかる時間、エラー率や成功率などの項目を確認し、目標としていた品質・性能に到達しているかを精査します。
下の図はソフトウェア開発の工程を示すV字モデルの簡略バージョンで、V字の左半分の開発工程とその横にある右半分のテスト工程が呼応しています。RPAに関しては設計を行っていない場合もあるので、要件定義とテスト間を青の点線で結んでいます。
V字モデルの簡略バージョン
RPA開発におけるテストの進め方
本記事ではテストの進め方について説明していきますが、テストの中に「テスト計画」「テスト設計」「テスト実施」の3つの工程が存在します。まずはそれぞれの工程でどういったことを実施するのか説明していきます。
テスト計画
まず初めのテスト計画で最も重要な決定事項は「テスト実施の目的」です。この段階で、何を目的としてテストを実施するのかを背景を踏まえて言語化、明文化しておきます。
テスト設計
次に行うのがテスト設計です。テスト計画で決定し明文化されたテスト実施の目的に基づいて、その目的を達成するために求められる、適切なテストの手法を決めていきます。
テスト実施
テストの実施を行います。最終段階のように見えますが、ここで不具合があった場合、再度テスト計画を立て、設計、実施といった様に3つの工程を繰り返していく必要があります。
この3つの工程の中で最も重要になってくるのが「テスト計画」です。
その後に続くテスト設計はテスト計画での決定事項を元に行われるので、テスト計画で「テスト実施の目的」を明確に出来ていないままテスト設計に移ってしまうと設計の項目決めに時間がかかってしまったり、設計が妥協的になってしまいます。
後々苦労や面倒を招かないテスト計画を行うために、次はテスト計画時点で決めておきたい項目について説明していきます。
テスト計画での決定事項
テスト計画で検討すべき内容について説明していきます。これらの項目を明確にして次のテスト設計に進むことでスムーズにテストを実行できます。しかしながら項目は一例なので、状況やプロジェクトによって足りないものを付け加えたり応用を効かせてください。
テストの目的
繰り返しになりますが、最重要事項は「テスト実施の目的」です。明文化された目的がこれ以降の段階において指針となり、逆に目的がないのであればテスト自体実施する必要がなくなってしまいます。後々つまづかない様にここで明確にしておきましょう。
目的が見つからないようであれば、「RPAロボット自体が動くのであればそれでいい」としてしまうのも1つの手です。しかし、後々実務で使い慣れた頃にエラーが生じる可能性や、コストがかかる可能性を有していることを心に留めておく必要があります。
テストの対象
テストの対象もここで決めておきましょう。RPAでは共通で作っている部品もあるので、1本のロボットだけをテストするのか、共通部品もテスト対象とするか否かなどを検討します。よくある検討箇所は以下の通りです。
- ロボット全てを対象範囲に含めるのか
- 共通部品を対象は含めるのか
- UiPath Orchestratorなどの管理部分を対象範囲に含めるのか
- 外部から読み込んでいるファイルを対象範囲に含めるのか
テストの観点
テストの観点の詳細はテスト設計の段階で見ていくことになりますが、決定したテストの目的に応じてどの項目をチェックすべきかというところまではこの段階で決めておきましょう。
例えば、テストの目的を「自動化したことによって手動で行うときに比べてどれだけの業務時間が削減されるのか調べたい」とするのであれば、観点としてテスト時に「ロボットの実行時間」をチェックする必要があります。
テストのスケジュール
テストをどう進めていくのか、この時点で期間や開始時期や終了時期などのスケジュールを決めておきましょう。テストは細かく行おうとすれば際限なく突き詰めることが出来てしまいます。そうすれば期間に伴いコストも青天井になってしまいます。最初に定めた目的に応じてどれだけの工数をかけるべきテストなのか、もしくはどれだけの工数がかかってしまうテストなのか、この時点で見極めて決めておきましょう。
スケジュールの見通しを決めるのは難易度が高いものです。まだ開発の経験が浅く、開発スケジュールを決めるのが難しいようであれば、厳密に決めすぎずに「1週間程度」「1ヶ月程度」といったように大まかに決めておくのでも問題ありません。
一般的なテスト
次に一般的なテストの方法を紹介します。観点に応じてテストの方法を選択する必要があるので、やり方を覚えておきましょう。
大きな枠組みで考えるとテストは「静的テスト」と「動的テスト」の2つに分類することが出来ます。
静的テスト
静的テストとは名前の通りロボットを動かすことなく実施するテストのことです。同僚（peer）が成果物をチェックするピアレビュー（インスペクションやウォークスルーなど）やはもちろん、普段あまりテストとして意識しませんがUiPath StudioやPower Automate for desktopの機能として標準装備されている「変数が正しくない場合に表示されるエラーメッセージ」などもこれに分類されます。
複数のテストは観点に応じて選択する必要があるのでそれぞれのテスト観点をご説明します。
インスペクション
インスペクションは複数のレビュアーによって行われる静的テストです。予め用意しておいたチェックリストを用いて、制作に関わっていない第三者（インスペクター）が成果物に対して決まった形式でレビュー、チェックを行います。
ここでは「開発標準に沿っているか」「設計に沿って開発ができているか」をテストの観点とし、ルールに乗っ取っているかどうかを中心に調べていきます。
ウォークスルー
ウォークスルーではチェックリストなどを用いる代わりに同じ場所に複数人のレビュアーが集合し、成果物を見ながら検証や議論を行っていきます。ウォークスルーの観点としては、成果物の不具合を探すというよりも「成果物の開発過程でのナレッジを共有する」という意味合いが強くなっています。
イメージとしては発表会のようなものですが、ウォークスルーを実施することによって他の人の知識やアドバイスをロボットの開発に取り入れ、より良いものに改良することが可能です。
ピアデスクチェック
ピアデスクチェックの特徴はレビュアーが1人であることです。1人もしくは開発者とマンツーマンで、開発標準に沿っているか、潜在的なバグが無いかなどをチェックします。
インスペクションやウォークスルーのように複数人を動員する必要がないので、より手軽になりますが、たった1人のレビュアーの能力によってチェックの精度や品質が上下するので、注意が必要です。
動的テスト
動的テストは静的テストと対照にロボットを実際に動かして実施するテストのことです。基本的には静的テストと組み合わせて実施していきます。これらは観点や対象に応じて「単体テスト」「結合テスト」「システムテスト」「受入テスト」などに更に分類することが可能で、静的テストと同様に観点によって使い分けていく必要があります。
単体テスト
UiPathであればxaml、Power Automateであればサブフロー、他にもシーケンスやブロック単位で処理が正常に実装されているかの確認を行うのが単体テストです。
主な例として挙げられるのは以下の通りです。
- ファイルの読み込み（ファイルが存在しない場合の処理が組み込まれているかどうか）
- ログインが求められるxaml、サブフロー（IDの有無、PWの有無、ログイン結果で処理分岐など全て網羅できているか）
こういった確認を機能単位で行っていくのが単体テストの観点です。
結合テスト
結合テストでは機能要件（入力から出力を得られる）が満たされているかを確認します。
ここに至るまでに単体テストを済ませておきます。単体テストによりそれぞれの部品や処理が実装されていることは確認済みなので、それらが上手く組み合わさるか、結果としてTrueもしくはFalseが返されたときに後続の処理がどうなるかなどといった処理全体を確認するのが結合テストの観点です。
システム（運用）テスト
システムテストではロボットを最初から最後まで動かしてみて、要件通りの結果が得られるかどうか確認します。システムテストと位置づけなくとも、本番前に実行ボタンを押して最終確認をされている方も多いのではないでしょうか。
システムテストは開発側としての最終確認にあたるので、結合テストよりも大局的な視点で実際の環境に乗せてテストを実施しましょう。
受入テスト（UAT）
単体テスト、結合テスト、システムテストを開発者が行うのに対し、受入テストでは実際に業務を行う予定の非開発者（実務担当者）がロボットを動かし、不具合がないかチェックします。受入テストの観点は「開発者側の想定していない動かし方でロボットを動かすこと」です。
「Excelで半角スペースを入れない想定だけど入れてしまった」や「ファイル名を変更してしまった」などといった開発者側は想定していなかったけれど現場では十分に起こり得る事態を受入テストで経験しておくことで、その機能を新たに実装する必要があるか、もしくは手順書を作成することで補填していくのかなど、本格的な運用を前に実装していないエラーの対処策を考えておくことが出来ます。
動的テストの必要性
次に動的テストの必要性を考えていきます。4つの動的テストを紹介しましたが、全てを試す必要は無く、省略や兼任も可能です。
例えば、「単体テスト」は、テスト設計をしていなくても、テスト仕様書に残していなくても、開発中にセレクタの確認を都度行っているので敢えて単体テストとして実施しなくてもいいという考え方もあります。結合テストに関しても、「実際にシステムに入力できるか」という最重要箇所を確かめる為であればシステムテストと兼ねてチェックをしても差し支えありません。
対照的に、システム（運用）テストは省略することなく適切に行う必要があります。本番環境で実施することが理想ですが、検証環境で行うのであれば本番同等か否か、テストを実施した環境を証拠としてテスト仕様書に残しておきましょう。
受入テストに関しては、開発者と使用者が別であることを前提とした観点になっていますが、近年ではPower Automate for desktopなどの登場により開発者と使用者が同一人物である場合が増えてきており、その場合の受入テスト実施の有無は適宜検討する必要があります。
また、使用者がRPA未経験者である場合、受入テストがスムーズに進まない可能性があるので、「前々から受入テストについて伝えておく」「手順書を同時進行で作成する」などの配慮が求められます。
必要なテストは何なのか、組織の規模や状況に応じて取捨選択を行ってください。
テストの目的を考え品質の高いRPAを作りましょう
本記事ではテスト計画の立て方というテーマの下、テストの種類や目的、観点についてお伝えしてきました。
何度も繰り返しますが、テスト計画の中の最重要事項は「何の目的でテストを実施するのか」を明文化することです。テスト項目や方法などについては各状況に応じて取捨選択する必要がある旨を述べましたが、そこに関しても目的を果たすためにはどうすればいいかを考えていけば自ずと決まっていきます。次のテスト設計においてもここを意識することでスムーズに遷移できるのではないでしょうか。
最初にお伝えしましたが、テストはいくらでも詳細に行うことができ、それに伴いコストは青天井で増えていきます。今回お伝えした目的や観点を参考にしながら、適切なテストを実施してみてください。
RPA導入担当者様に伴走サービスのご紹介
テストを行うことで起こり得るトラブルを想定し未然に防ぐことは出来ますが、それにも限度があります。運用を開始した後にエラーが起こってしまった場合は、落ち着いていかに早く対処できるかが鍵になってきます。
Peaceful Morning株式会社が提供する「Robo Runner」は導入後に直面するRPAに関する想定外のトラブルをオンラインサポーターが即座に解決するサービスです。
企業におけるRPA運用でボトルネックとなりがちな引き継ぎや学習、開発やその他RPA導入準備〜本格稼働までの間に出てくる様々なトラブルを経験豊富な専任サポーターが丁寧に解決します。Robo Runnerは低コストで、全てのサービスをオンラインで利用できるため、企業の立地を問わず求めるサービスをいつでもどこでも受けることができます。
エラーやトラブルを恐れてRPA導入を躊躇っている担当者様はぜひ一度チェックしてみてください。
コメントを残す