NTTデータでは、カード決済インフラCAFIS®の次世代端末の開発にあたりテスト自動化が不可欠と判断。テスト自動化ツールとしてRanorexを選定、本格的に導入し活用中である。同ツールを採用した主な理由は、画面操作の記録によるテストケース生成能力が、非常に優れていたことによる。Ranorexの本格導入により、今まで不可能だった規模と頻度のテストを行う能力を得て、品質を大幅に向上させている。

デグレード防止に不可欠な回帰テストには自動化が必要

次世代のシンクライアント型クレジットカード決済端末の導入が始まろうとしている。これは、ネットワークで結ばれたセンター側で動くソフトウェアにより、決済サービスの機能を提供するタイプの端末である。NTTデータのカード決済インフラCAFIS®では、現在80万台の端末が利用されているが、今後数年をかけてこれらの端末群が、次世代端末に置き換わる。
この次世代端末では、ソフトウェア開発現場への要求も大きく変わる。端末はAndroid OS上で動作し、主要機能はセンター側で動作するソフトウェアにより提供されている。このようなアーキテクチャを採用することで、端末の機能アップデートを容易にすることが可能となる。
「従来の決済端末ではソフトウェア更新を手動で行っていた。一方、シンクライアント型の次世代端末はセンター側でソフトウェアを更新でき、より手軽にアップデートが可能となる。」NTTデータの長田武徳氏（ITサービス・ペイメント事業本部　カード＆ペイメント事業部　第一開発統括部）はこのように説明する。
アップデートが頻繁に実行できることは、決済サービスの水準を高めるうえで重要な武器となる。その反面、開発現場にはひとつの課題が浮上する。サービスの機能追加に伴うデグレードを防ぐことである。「デグレードはお客様にとって大問題」と同部門の萩野谷氏は話す。どうやってデグレードを防ぐか。その方策は、リグレッションテスト（回帰テスト）を実施することに尽きる。
しかし、ここで問題となるのがソフトウェアテストの工数である。端末の機能は膨大で、アップデートの頻度を高めるためにはテスト自動化の推進が不可欠だった。それまではオープンソースのSeleniumを検討していたが、膨大なコーディングが必要だったため、工数や効率の面で満足のいく自動化を実現することが難しいと判断した。
そこで、これらの問題を解決するような、テストケース生成の効率、画面テストの効率の両方に優れるテスト自動化ツールが是非とも必要だったのだ。

テスト自動化能力の高さを実感

同社は、2015年の秋ごろから導入を検討し、2016年に入って本格的に導入しているが、Ranorexの選定にあたっては、まず「30日間無料」の試用版を用いて評価した。ツールに求める要求の中で重要な項目は、「決済端末という特殊な環境でも、画面操作の記録だけでテストケースを作れるだけのオブジェクト認識能力を有していること」、「データベースの初期化からテスト実行までの一連の作業を自動化できること」の2点であった。前述したように、テストケースをコーディングにより作成していたのでは、コーディングができる要員をそのために大量投入しなくてはならない。一方、画面操作からテストケースを生成する能力が高いツールであれば、テスト対象のアプリケーションを操作できる要員がいればテストできる。この違いは大きい。「幅広い要員でテストできるので、大規模テストに対応しやすくなった」と長田氏は話す。さらに、記録したテストケースに対してデータのインポートやスクリプトによるカスタマイズを施す機能を利用して、今では、当初の要求にあったデータベースの初期化からテスト実行に加えて、テスト結果の比較までの作業を完全に自動化できているという。

20人日のテストが、わずか0.5人日に！40倍の生産性向上を実現

Ranorex導入によるテスト自動化の威力は、数字面から見ても明らかだった。従来は1シナリオあたり平均50分、トータルで20人日かかっていた188個のテストが、0.5人日に圧縮されたのだ。実に40倍の効率アップである。従来のやり方では、80人月と試算されていた全15,000個のテストシナリオの実施工数も、Ranorexを活用すれば、3人月程度に削減できると試算された。「今まではテスト自動化ツールがなかったため、テストの実施対象を絞って人間が打鍵してテストを行っていた」と長田氏はいう。同社は、Ranorexでテストを自動化したことにより、予定していたテスト期間内で、実施が不可能であったテストを網羅的に実現できる可能性をツールに見出すことができた。
開発現場の目線から見ても、Ranorexによるテスト自動化は魅力的だった。例えばテスト実施のエビデンスを記録するのも、手動と自動とではまったく効率が異なる。Ranorexは、事前に期待する結果を作成しておけば、テスト結果と期待する結果を比較して合致しなかった場合、スクリーンショットを自動取得する機能がある。「エビデンスの取得漏れにより再度テストをするような無駄を削減できた」と萩野谷氏は振り返る。オープンソースで提供されている他のテスト自動化ツールも試してきたが、画面操作からのテストケース作成が充分に行えなかったり、オブジェクト認識能力が弱く、テストの作成やメンテナンスの細かなところで工数がかかっていた。ところが、Ranorexはこれらの問題を解決してくれた。

今後は、CIを利用してテスト自動化を加速したい

課題だったテスト自動化はうまくいく目途がたったので、今後は、Ranorexを使ったテスト自動化を他のプロジェクトに展開することと、継続的インテグレーション(CI)で、ソフトウェアのビルドからテストまでを自動化し、開発サイクルとして定着させることを検討している。どちらも、開発の効率や品質の向上に大きく貢献すると期待が寄せられている。
このように、同社におけるRanorexの導入は、ソフトウェアアップデートのたびに必要となるリグレッションテストの工数を大幅に削減したのみならず、開発プロセス全体の効率と品質の向上にも成功した特筆すべき事例となったといえるだろう。

•  取材日：2016年6月