ソフトウェアロボット＋テスト自動化に関する雑記
※ This Opinion is My own
RPAでビジネスプロセスの自動化してゆこうという試みよりも、遥かに長い歴史を有するのが、テスト自動化に対する営為であり、国内だとテスト自動化研究会の活動などを通じて洗練され続けているこの老舗で成熟しつつある領域に対して、最近、RPAが（再び）接近しているらしい。たしかに、RPA で使われている”人のアクションを摸す”ための技術は元来、フロントエンドに対するテスト自動化で活用されていた技術であり、UiPath も創業からの8年間は、DeskOver 社(UiPath の旧社名）としてはScreen SCRAPING のSKU をコツコツ開発しいて、その技術は、まさに、テストの自動化において、まさに、GUI テストの自動化において利用されていたようだ。そんななかで、テスト自動化でそのライブラリを活用していた或るお客さんから「これは、ビジネスプロセスの自動化に使えるのでは…？」といったアイディアが端緒となってRPA の開発を2013 年頃から本格化(RPAというワードが使われ始めたのが2012年にPat Geary が提言し以来*所説あり)して、現在のEnd to End Automation Plaform 至っているわけである。おそらく（歴史のIf は禁忌であるが）、DeskOver 社がUiPath 社へ昇華されずにいたら、創業者のDaniel Dines はSelenium と並ぶGUIレンダリングに関するオープンソースソフトウェアの作者として有名になっていたのかもしれない…
RPAというテクノロジーは、Gartner が発表した「日本における日本における未来志向型インフラ・テクノロジのハイプ・サイクル：2020年」によると、ハイプサイクルにおいて、幻滅期の底を打ち、幸か不幸かCOVID-19 によるパンデミックによるニューノーマル(もはやこの言葉を使うのは気恥ずかしを覚えるが）への社会的インフラの変容も相まって、待望の、普及期へ向けて離陸しようとしているようだ。そうなるてぇとぉ、Automation の数が増えてゆき、それにつれ、品質そしてそれら大量のソフトウェアロボットを維持するためのコスト管理が重要になってくる。そうなるてぇとぉ、各ソフトウェアロボットの実行ワークフローに対して、テストが関連している・且つ・パスに対するカバレッジが100％のテストケースが準備されていることが”あるべき姿”であると設定することでできよう。御多分に漏れることなくRPA にも、一般のシステム開発と同様に、テスト駆動開発（Test-Driven Development|a.k.a TDD|via 見てわかるテスト駆動開発)を定着させて、極端なはなし、テストが通らないとOrchestratorにPublish できないくらいにしてしまってもよいのではないかと個人的には考えている。(お叱りを受けないで済むほど、実地に根差した実用的な、経済（かどうかは、サンプル数が少ないため不明だが）アプローチであろう。１の労力でワークフローを書き、0.2の追加労力でテストケースを書くみたいなRPA開発方式が、UiPath Test Suite
Studio Pro 等の製品を一つの切っ掛けにして、定着されることを期待している）
各企業でのTDD(Test-Driven Development/テスト駆動開発)導入効果を具体例として挙げて、TDD導入によって実装時間が約20％増えるが、品質が70～80％程度向上するということを示していました。
またとある企業では定量的評価だけでなく被験者を対象とした定性的評価も行っており、90％近くの被験者がTDDによって要求が洗練され、デバッグ工数も削減され、品質の向上を感じており、50％の被験者は開発工数が減っていると感じたそうです。これは実装時間が約20％増える話と矛盾するように思えますが、問題が起きた時の手戻りが減ることやデバッグ工数が減るのでそう感じるのだということです。
このようにテスト自動化によって早期に品質をつくりこめることは、20％程度実装工数自体は増えるものの品質が70％以上向上し、なおかつ保守性が高くデバッグも行いやすいので実装や修正時の工数を高精度に見積もることができマネージャ層にとってもありがたい状態になります。これらの事実は説得時やエレベーターピッチにも使えるということです。
https://shiftomo.shiftinc.jp/event/2577/
RPAベンダーが、いま改めて、手動テスターの作業に対する効率向上やCI/CDツール、APIテスト、モバイルテスト等などを射程に含めたテストスイートな製品を出すということだが、当然、RPA ベンダーが開発したテスト自動化ツールであるため、RPA との親和性が高い。こちら言うは易く行うは難しであるが、IT開発、IT運用、ビジネスプロセス（従来のRPA領域）のそれぞれの自動化を、共通の製品で実装することでき、それを組織全体で再利用できる仕組みが整えば、様々なメリットがでるのではなかろうか。もちろん、Selenium やAppium といった特化型（餅は餅屋？）のツールにはそれはそれで、無料で使えることであったり（無料で使えるということはその裏で様々な潜在的なコストを肩代わりしているわけだが、その話は一旦置いておこう）、様々なメリットはあるとは思うので、敵対する関係でなくベスト・オブ・ブリードに共存することができたら、一等ベストであろう（お花畑？）
そうして、さらには、各ユーザへの浸透の仕方もこれまでのテスト自動化ツールにはなかった入り口（下記①）を切り拓く可能性も秘めていると私は考えている。メビウスの輪の表裏が知らず知らずのうちに繋がるように、テストオートメーションの歴史とビジネスオートメーションの歴史が融け合うことを（お花畑に）夢想していたりもする。
①既存、RPAユーザーからの利活用拡大のアプローチ。RPAにおけるTDD定着化・品質向上アプローチ
②RPSユーザーではないが他製品でテスト自動化を試みているユーザーへのアプローチ
③RPAユーザーではなく、テスト自動化も行っていないユーザーへのアプローチ
物の本によると、9割が失敗すると言われているテスト自動化であり、先陣たちも叡智を傾けてきた領域であり、”銀の弾丸などない”のは揺るぎないないbut,枯れた技術の水平思考”よろしくユニークなアプローチを仕掛けているUiPath Test Suite によって何等かの働きかけ（保守容易性やテスト自動化の作り手の間口が広がること、テストコードの安定性など）ができることもまた、確かで、あろう。破壊的なイノベーションといった花火をぶち上げる必要はなくともとも、この領域における、新機軸・新しい最適解を、定着させることができればよいと筆者個人は、考えている。
