ソフトウェアテストにRPAを活用する戦略的アプローチ

非効果的なソフトウェアテスト自動化は、リリースを遅延させながら信じられないほどのリソースを消費することで悪名高い。

時折、ニュースフィードに「トップ10ライフハック」といった記事が流れてくる。日常用品を意外な方法で使って生活を改善するヒントとトリックだ——「7番目は衝撃的！！！」

認めよう、私はこのクリックベイトに釣られたことがある。正直、時には心地よい驚きもある。例えば、缶切りで厄介なプラスチックブリスターパックを切れたり、トイレットペーパーの芯で包装紙の巻き戻りを防げたりすることを誰が知っていただろう？

上記2つの「ハック」を試してみた。結果？ 「まあまあ」機能した……しばらくは。缶切りはプラスチックが融着した継ぎ目は切れたが、パッケージの長さ方向は切れなかった。トイレットペーパーの芯はしばらく包装紙を保持したが、最終的に段ボールが弱まり包装紙がほどけた。驚くべきことに、ハサミでブリスターパックを、小さなテープで包装紙を留める方が、はるかにうまくいった。

非常に似たベインで、多くの組織が今、ソフトウェアテストの自動化にRPAを使うことを検討している——ソフトウェアテスト向けの「テックハック」のようなものだ。しかし、トイレットペーパーの芯が包装紙の巻き戻り防止の持続可能な解決策にならなかったのと同様、RPAはソフトウェアテスト自動化の持続可能な解決策ではない……RPAツールをソフトウェアテスト自動化というタスクに持続可能にするために必要な改修は、まあ、ハックだ。

すでに組織にRPAツールがあり、テスト自動化を始めたい場合、RPAツールは論理的な選択に見える。基本的なテストシナリオ（新規ユーザー作成とトランザクション完了など）を自動化し、検証を追加し、テスト自動化への道を歩み始めたと信じるのは通常比較的容易だ。

しかし、成功し持続可能なテスト自動化には、アプリケーションパスをクリックする能力以上のものが必要だということを認識することが重要だ。業界平均のテスト自動化率20%未満を超えるには、チームは効果的な自動テストスイートを構築し安定化させる能力も必要だ。RPAツールは通常、これを可能にするよう設計されていない。その結果、必要なテストデータとテスト環境を待つ遅延、自動化イニシアチブへの信頼を損なう一貫性のない結果、多くのリソースを消費するが明確で実行可能なフィードバックを提供しない「肥大化した」テストスイートといった、テスト自動化の障壁にぶつかる。

RPAツールとテスト自動化ツールのスコープの違いを簡単に把握するため、Gartnerの以下の定義を比較してみよう：

RPAツール：「構造化データ上で『もし、なら、そうでなければ』文を実行し、通常UIインタラクションの組み合わせやAPI接続によりクライアントサーバー、メインフレーム、HTMLコードを駆動する。RPAツールは、プロセスをRPAツール言語でマッピングし、ソフトウェア『ロボット』が従うようにし、制御ダッシュボードによりランタイムを割り当ててスクリプトを実行する。」

テスト自動化ツール：「組織が自動機能テストを設計、開発、維持、管理、実行、分析できるようにする……ソフトウェア開発ライフサイクル（SDLC）全体にわたる製品と機能の幅と深さを提供する。これにはテスト設計・開発、テストケース維持・再利用、テスト管理、テストデータ管理、自動テストと統合が含まれ、継続的テストのサポートに強く焦点を当てている。」

これらの追加テスト機能の必要性は、以下の核心的違いを考えると明確になる：

• 明確に定義されたパスを通じてプロセスを正常完了させ、作業を速く完了するために、本番環境でタスクシーケンスを自動化すること、および
• アプリケーションがどこで失敗するかを見るために、現実的なビジネスプロセスをテスト環境で自動化し、アプリケーションがリリースするにはリスクが高すぎるかどうかの意思決定を可能にすること

これらの違いはソフトウェアテストに何を意味するか？

• 自動化は、通常不完全で進化し、制約のあるテスト環境で実行されなければならない
• ステートフルでセキュア、コンプライアンス準拠のテストデータ管理が大きな課題になる
• 効果的なテストケース設計が成功の必須条件だ
• 失敗はビジネスリスクへの洞察を提供する必要がある

より具体的にするため、オンライン旅行サービスのテスト例を考えてみよう。ユーザーがプリペイドホテル予約を延長する機能をチェックすると仮定する。まず、アプリケーションロジックを徹底的に検証するために何テスト必要か、各テストにどのデータ組み合わせが必要かを決定する。

次に、テストシナリオを実行できる状態にアプリケーションを設定するために必要なすべてのデータを取得・プロビジョニングする必要がある。この場合、（最低限）将来の日付で既存のプリペイド予約を持つ既存ユーザーアカウントが必要だ——実際の本番データはGDPRのようなプライバシー規制により使用できない。

次に、接続されたホテル予約システム（部屋あり/なし）、クレジットカード（承認/拒否）などから必要な範囲のレスポンスを呼び出す方法が必要だ——だが実際に部屋を予約したりカードを課金したりせずに。

もちろんプロセスを自動化する必要がある。ログイン、既存予約の取得、変更希望の表明、延長期間の指定が含まれる。

完全にプロセスを自動化したら、さまざまなチェックポイントで多数の検証を設定する必要がある。適切な詳細が適切なメッセージフォーマットでホテルに送られたか？ 予約がユーザーデータベースで更新されたか？ 支払いデータがクレジットカードプロバイダーに適切に送られたか？ アカウントクレジットは適用されたか？ 予約延長できない場合、ユーザーは適切なメッセージを受け取ったか？ クレジットカード拒否の場合は？ 拒否された場合、システムは元の予約期間に戻し、実際に支払われていない追加宿泊日を追加しないか？

ここで、会社がすべてのプリペイド予約に10ドルの変更手数料を追加することを決めたと想像しよう。この新要件を既存の自動テストに容易に組み込めるか？ それとも、このマイナーな変更に対応するために、各テストを大幅に書き直す必要があるか？

このシンプルな例でも、RPAツールが設計されていないソフトウェアテストの複雑性の多くが露見する。RPAツールはシーケンス内の特定タスクを自動化するために構築されている。ソフトウェアテスト自動化ツールは、より広範なタスクシーケンスのレジリエンスを測定するために設計されている。率直に言えば：RPAツールはプロセスを「動く」ようにするアーキテクチャだ。だがソフトウェアテストには、プロセスがどう「壊れるか」を判断するのを助けるツールが必要だ。

非効果的なソフトウェアテスト自動化は、リリースを遅延させながら信じられないほどのリソースを消費することで悪名高い。CIOがデジタルトランスフォーメーションイニシアチブにますます投資し、より速いソフトウェアデリバリーで顧客体験を改善する中、ソフトウェアテストをケチるのは逆効果だ。仕事に適したツールを選ぶことは、デリバリー加速、ビジネスリスク低減、イノベーションに割けるリソース増大の面で大きく報われる。

Wayne Ariola氏は『ITリーダーのための継続的テスト』著者で、DevOpsとアプリ開発分野の著名な基調講演者。