みなさま、こんにちは。清水勇弥です。

前回の記事「デバッグ方法」では、主としてデバッグの際に効率的に作業できるようデバッグモードの機能や操作方法を紹介しました。

今回はテストの前段階で考えるべきことについて書いていきたいと思います。

---

1. はじめに
2. テストの基礎知識
   　テストの目的
   　完璧はあり得ない
   　終わらせるもの
   　完了基準の決め方
3. Botのテスト
   　視認しやすい開発画面
   　動きが見える
   　業務特性との相性
   　RPA特有の観点　他のPCでも同じテストをする
4. Botの構成で考えるべきこと
   　固定値は変数に保有する
   　共通化して別のBotにする
5. おわりに

---

1. はじめに

テストの実施方法はソフトウェア開発の一般的な知識としてフレームワーク化されています。それらの一端を紹介することがメインになりますが、ここでは「Automation Anywhere A2019の特殊な点は？」という視点を加えていきます。

---

2. テストの基礎知識

テストの目的

突然大きな話になりますが、まずはテストの目的について確認したいと思います。テストをする目的は「作ったものが想定通りに動くかの動作確認」に尽きるのですが、裏を返せば「作ったものが想定通りに動かない不具合を検出するため」でもあります。テスト対象を様々な条件で動作させ、この目的を達成していきます。

作っている本人（作成者）にしてみれば一通り作った時点で達成感が湧き出てきますが、どれだけ注意深く作っても実際に動かすと思わぬ動作をすることの方が圧倒的に多いものです。実際に動かすテストで不具合を検出して、修正して、再度テストで想定通り動くことを確認して...と繰り返していくことで完成に近づけ（品質を高め）ます。

完璧はあり得ない

期待を外してしまうようですが、人が作ったものである以上「完璧はあり得ない」と考えるのが原則です。

どれだけ入念にテストをしても、完璧に近づくだけで完璧にはなりません。なぜなら「想像の範囲外の条件がある」という前提に立ち、実際の「ある」「なし」に関わらず発見できない不具合が常に潜んでいると考えるためです。

私が担当していたシステムは全世界で30年の稼働実績がありましたが、初めから潜んでいた不具合が顕在化したという経験があります。長い間、問題がなくても不具合はゼロにはならないものです。

終わらせるもの

「完璧はあり得ない」のですが、テストもどこかの時点で終わりにしなければなりません。仕事であれば勤務時間も有限ですし、成果も求められてしまいます。

ただし理論上は完璧はあり得ないので、疑い出したらキリがありません。テスト前にあらかじめ「ここまでテストをして確認したら充分」という線引きをして完了基準と期限を明確にしておき、それに従ってテストを終わらせる必要があります。

完了基準の決め方

あらゆるテストをし続けると、より多くの不具合を検出して完璧に近づきます。

ただし右のグラフのように初めのうちは勢いよく不具合を検出できますが、繰り返し修正されていくうちに潜む不具合が少なくなるため、同じだけの時間かけても検出される不具合の数が減少していきます。

時間をかけるということは、つまりコストをかけることですので、採算性の観点からいつまでもテストは続けられません。取捨選択して重要度の高いテストから優先的にテスト範囲に加えていくことになります。

テストの重要度は、右図のようにその条件の「発生頻度の高低」と誤った場合の「影響度の大小」の2つで判定した4パターンで分類して考えます。

影響度が大きく頻度が高い、①に分類される条件のテストを最優先にし、影響度が大きく頻度が低い、②に分類される条件のテストを2番目に優先します。

もし早期実現させたいときや期限が差し迫った状況では、最も優先度が低くなる④に分類される条件では思い切ってテストをしないこともあります。解は1つではありませんので、組織の基準やプロジェクトの状況と照らし合わせての判断となります。

---

3. Botのテスト

これまではどちらかというとプロジェクトといった単位で考慮する点について述べてきましたが、以降は1つのBotを対象にした場合にどうテストを進めていくのかを述べていきます。

Automation Anywhere A2019ではホワイトボックステストでの確認が定石です。ホワイトボックステストとは処理フローにあるアクションや判定条件を全て網羅させるようにテストを実行していく手法です。

ホワイトボックステストで確認していく理由は3つあります。以下でそれぞれ述べていきます。

視認しやすい開発画面

第1に開発画面が視覚的にBotの処理を理解しやすい構造となっているためです。フロー表示によってBotの全体像が把握しやすいだけでなく、リスト表示で詳細もよくわかります。

右図の例では1組のIf-ElseIfがあります。その場合は①と②の2種類の経路でそれぞれのアクションの動きが正しいことを確認していきます。ご覧の通り、ワークベンチにあるフローやリストの表示により経路や条件の確認に抜け漏れが生じにくいと言えます。

動きが見える

第2にデバッグモードのステップオーバーを使って1つ1つアクションの動きを確認できるためです。

条件分岐がある場合に、その判定の直前で止めて、ステップオーバーで1つずつアクションを実行させれば、狙い通りに判定がされて処理が進むのかがすぐに捉えられます。もし意図しない判定結果になった場合は、判定条件と対象の変数の値を比較すれば原因がすぐにわかります。

条件分岐による経路の判定だけでなく、基本的なアクションはクライアント（PC）の画面上で操作の動きが見え、仮にBotが意図と違う動きをしたら発見が容易です。アクションの設定自体の間違いも見つけやすいのです。

業務特性との相性

最後に業務特性との相性がよいためです。Bot化する業務を選定する際、業務効率化が目的であれば、繰り返す回数が多く判断の回数が少ない単純な業務であるほど適しています。

ホワイトボックステストの欠点は設計自体の誤りを発見できないという点にありますが、Bot化したい業務は単純な業務で条件が複雑でないため、設計の誤りが発生しにくいと言えます。

RPA特有の観点　他のPCでも同じテストをする

RPAが人によるPCの操作を代行するソフトウェアであるという性質上、個々のPCの状態によって正常に動いたり、途中で止まってしまったりと挙動が安定しないことがあります。

そのため、開発用PCと実行PCが異なるなど環境を分離している場合や、Botを動かす実行用PCが複数台存在している場合は、それぞれの実行用PCで可能な限り同じテストを実施した方がよいと思います。

しかし、その分の手間暇が多く発生してしまいます。妥協案として最低限の動作確認だけでも複数台で実施しておくことをお勧めします。

---

4. Botの構成で考えるべきこと

Automation Anywhereの利点の1つとして簡単に複数システムを横断した自動化を行えるという点が挙げられます。このことは逆に各システムの変更に影響を受けやすいという欠点も同時に持ちます。以下ではその欠点を踏まえたBotを構成する上での工夫をについて述べていきます。

固定値は変数に保有する

ついつい面倒になって各アクションで与えるオプション項目の入力値を直接記入してしまいがちですが、その後のテストやメンテナンスのしやすさという面で考えると悪手です。Botを作成するときにはひと手間必要ですが、変数を作ってデフォルト値に保有させるようにしましょう。そのメリットは3つあります。

1つめは用途に応じた名称を付けることができることです。作成者以外がBotを編集する場合にも探すのが比較的容易になると考えられます。

2つめは様々なアクションで同じ値を再利用が可能になることです。間違いが減るだけでなく、値を一括で変更できるため変更漏れもなくなります。

3つめはデバッグモード中は変数の値を表示させることができることです。誤りについても発見が少し容易になることが想像できます。

共通化して別のBotにする

RPAは繰り返し行う業務を共通化して自動化するものですが、業務を少し分解した作業の中にも同じことをしているものがあり、共通化可能なことを発見できます。その処理を共通化して別のBotにすることでBotのメンテナンスが容易になるメリットがあります。

例えば、Bot作成する中で、あるシステム（Aシステムとします）にログインさせるとします。具体的にはAシステムのログイン画面にアクセスし、ユーザー名とパスワードを入力して、ログインボタンを押下するといった一連のフローとなります。

ここで考えていただきたいのはAシステムを操作するBotを作る場合は全てこの一連のフローを辿ることになるということです。もしAシステムのログイン画面に対して、URLが変化する、入力項目が増える、ログインボタンの位置が変わる...のような変更が入った場合にはBotを修正しなければなりませんが、あらゆるBotにAシステムのログインのフローを独自が設定されていると、それら全てに修正を与えなければなりません。Botを作る際には常に処理が共通化できないか考えましょう。

他にも既に共通化されて稼働実績のあるBotを再利用する場合、そのBotの動作確認は不要となるメリットがあります。

Aシステムへのログインの例でいえば、共通化されているBotでは既にログイン可能なことは保証されているので「ログインできるか？」については確認する必要がありません。ログインした結果、「意図したユーザーであること」の観点でだけ確認すればよくなります。

システムへのログインといった単純な処理の例ではあまりメリットがないように思われますが、複雑な処理であれば誤っている箇所を探すのにも苦労するので共通化することで誤りの発見効率が向上します。

共通化を突き詰めていくと1つ1つのBotがシンプルになってステップ数が小さくなります。すると作るのに時間が掛からなくなる、確認ポイントが明確になる、複雑なBotを作るのにも複数人で作業分担できるといったようなメリットも生まれてきます。大きくなりすぎたBotに対して共通化できる部分がないか見直す機会を設けることも大事になってきます。

---

5. おわりに

いかがでしたしょうか。今回はテストの進め方について基本に立ち返りながら、Botの構成についても考えてみました。

単純なBotでしたら、あまり深く考えることなく思い当たる限りの稼働確認をするだけで問題ないことも多いです。

しかし複雑なBotを作るようになってくるとこれらのことを念頭においてテストを進めなければ、Automation Anywhere A2019の利点の1つである俊敏性が損なわれてしまう恐れがあります。一歩進んだBot開発のためは是非見直す機会を設けてみてください。