GUI自動化で84%の生産性向上と統合的なテスト環境を実現

2019年9月11日から13日にかけて、ソフトウェア品質シンポジウム (以下、SQiPシンポジウム) 2019が開催されました。
主催は一般財団法人日本科学技術連盟 (以下、日科技連) で、2012年以来、8回目の開催でした。

日科技連を中心とするコミュニティ「SQiP」は、1980年に設立された「ソフトウェア生産管理研究委員会」を前身とし、いまや社会を動かす基盤ともいえる「ソフトウェア」の品質向上を目的に活動しています。
SQiPシンポジウムは、その成果発表の場であるとともに、一般参加者にまで知見を広げた議論の場として開催されています。

SQiPシンポジウム2019では、「低頻度不具合の再現テストにおけるGUIテスト自動化ツールの導入効果」と題して、NECパーソナルコンピュータ株式会社 (以下、NECPC)マネージャー森一郎様の発表がありました。
その中では、当社がNECPC様へ販売したキーサイト・テクノロジー株式会社製GUIテスト自動化ツール「Eggplant」の実地での使用感について論じられており、その内容について森様へお話を伺う機会を頂きましたので、以下レポートいたします。
森様の知見をさらに深く理解する一助となれば幸いです。

※森様の発表資料及び論文は、「ソフトウェア品質シンポジウム2019」ホームページのプログラム欄よりダウンロードできます。
・発表資料：https://www.juse.jp/sqip/symposium/timetable/files/A2-1_happyou.pdf
・論文：https://www.juse.jp/sqip/symposium/timetable/files/A2-1_ronbun.pdf

工数が約17分の1に

– 最初に、現在森様が担当されている業務についてお聞かせください。

はい。当社では、NECブランドのパソコンを製造・販売しています。現在私が担当しているのは、そのOSに係る開発まわりとなります。
たとえば、新しいモデルを出すにあたり、OSのカスタマイズが入るのであれば、その実装やテストが必要です。また、システムテストの過程においてOSの不具合が見つかれば、その原因究明を行います。
原因究明では不具合の再現テストが発生し、中には手動で行われるものもまだまだ多いです。今回の論文では、そうした作業を対象とした自動化についてまとめています。

– 有り難うございます。それでは、今回発表された論文につきまして、概要をお聞かせ頂けますでしょうか。

はい。今回自動化の対象として取り上げたのは、再現テストの中でも、特に低頻度不具合のものです。発生率が0.1％以下、という事象においても、それが致命的な不具合であれば、再現テストを行わなければなりません。単純計算でも、同じ操作を1,000回以上繰り返すわけで、非常に手間がかかります。少なくとも、手動では行いたくない作業といえます。
そうした低頻度不具合の再現テストにおいて、当社が開発したツールと、市販のGUIテスト自動化ツールとを組み合わせ、自動化を試みました。論文では、その過程と成果についてまとめています。

結果からいいますと、自動化の実装により、再現テストで費やされる全工数を約17分の1まで削減することができました。
ROI (※1) の観点からいえば、自動化実装に遣った費用を、1件の不具合で回収できた、ということになります。類似の低頻度不具合への適用等、さらなる取り組みへつながる結果だったと考えます。

※1：Return on Investiment. 投資した費用から、どのくらいの利益・成果が得られたかの指標のこと。「投資利益率」とも呼び、利益を資本で割って算出する。

Eggplantは3つの点で「面白い」

– 有り難うございます。
ここからは、GUIテスト自動化ツール＝Eggplantについて、お話を伺いたいと思います。
まず、Eggplantを選定された理由をお聞かせ頂けますでしょうか。

それでは、御社との出会いからお話しします。
2016年のSQiPシンポジウムで、ISV (※2) アプリケーションの探索的テストについて発表しました。(※3)
翌日、御社もプレゼンテーションされていましたよね？ (※4)　業務の都合で、そのときのお話は聞くことができなかったのですが、会期中、御社の出されていた展示ブースに立ち寄る機会がありました。
そこでEggplantについて説明を受け、これは面白いな、ということで、調査目的での購入を決めました。

当時、私はOSではなく、アプリケーションを担当していました。開発元から届くソフトウェアの受入テスト等を行っていました。
テストケースを洗い出し、手順をつくります。ただでさえ多項目・多環境であることに加え、ソフトウェアの修正ごとにテストを行うわけですから、これが何千何万項目ということになります。これは、自ずと人力では限界のある数字かと思います。
テストは、テスターと呼ばれる人たちによる手動で行われるものが依然多く、そこに多大な工数がかかっていました。
こうしたことが、背景としてありました。

御社のブースでお話を伺い、カタログスペックとして、Eggplantが面白かったのは、3点あります。

1点目は、GUI操作をキャプチャしてリプレイする、という点です。これは、テスターによる手作業を自動化できるツールであることを意味します。
2点目は、判定まで行える、という点です。テスターの挙動を模擬し、判定まで自動化できれば、ある程度テスト全体を自動化できるということになります。
最後に3点目は、これが重要と思いますが、Eggplantは画像認識と文字認識との両方を駆使した自動化を行う、という点です。
これにより、パソコンの機種ごとに解像度が変わる、といった環境依存が起きにくく、自動化の操作対象が幅広いという点は大きな特徴かと感じました。また、その技術を用いたキャプチャ＆リプレイ機能により、テストスクリプトが自動生成でき、操作習得が比較的容易であることから、非常に有用だと感じました。

※2：Independent Software Vendor. コンピュータメーカの系列ではない、独立系のパッケージソフトウェア開発・販売会社のこと。サードパーティとも呼ぶ。
※3：このときの論文で、森様はSQiP Best Paper Effective Awardを受賞されました。
※4：SQiPシンポジウム2016ランチセッションにて、通信業界における第三者検証についてプレゼンテーションしました。

– Eggplantを試験導入される前に、同種のテストツールとの比較などはどのようにされたのでしょうか？

いくつか、スペックを比較しました。
購入にあたっては、プロジェクトサイドとしてはテスト工数の問題がありましたし、会社としても自動化に対するモチベーションがあり、ツール導入のための予算もありましたから、スムーズに購入・調査までいけたかな、と思います。

おおむね良好だが、課題もある

– 購入されて、調査はどのように行われたのでしょうか？

実際に行っている受入テストのテスト項目をいくつかサンプルとしてスクリプト化し、走らせてみて、テスト工数を測定取得しました。
その際、スクリプト化は御社に支援頂きました。
この結果、たとえばあるアプリケーションのテストにおいては、工数を約6分の1にまで削減できることが確認できました。

一方、残存した課題も勿論あります。
たとえば、Eggplantでは、操作したい対象の画像を取得し、テストスクリプトへ埋め込みます。アイコンの変更などによる画像の取り直しは手間に感じました。対応する機能として、複数の画像を同じ対象として整理するイメージコレクションなどありますが、このあたりは今後の開発にも期待したいところですね。

また、先ほどの調査の事例では、スクリプト化を御社に支援頂いたため、ツールに精通したテスト自動化専任者のアサインが前提となっています。これを外すと、期待された削減効果が出ないという結果につながりかねません。
今回の低頻度不具合における再現テスト自動化においては、プログラミング経験のあるテスターを専任者としてアサインするとともに、御社のサポートを受けることで解決しました。御社はツールのサプライヤーとしては珍しく、自動化環境の構築やサポートといった、技術支援サービスを持たれているため、この点もEggplantを採用した理由の1つだったかと思います。

自動化に向く作業

– 調査後、今回の論文となりました低頻度不具合における再現テスト自動化を行うまでの流れについて、お聞かせ頂けますでしょうか？

はい。
調査の結果、Eggplantが動くこと、成果を出せることはわかりました。けれど、調査の中では実装に手間のかかるテスト項目もありましたから、改めて、ツール適用の対象プロジェクトを探しているといった状態にありました。
そのような中、私はOS側へ担当が移り、低頻度不具合の案件が発生した際、繰り返し作業の多さや、テスターにおける負荷の高さから、自動化には適当な作業だと目を付けました。
先ほどお話しした通り、専任者のアサインもできましたし、改めて自動化に取り組んだ、そんな流れとなります。

自動化はテストに必要な手段

– お取り組みの詳細につきましては、論文も公開されていますので、ここからは、少し話を拡げて、テスト自動化、といったことにつきまして、森様のお考えを聞かせて頂けたらと思います。
自動化にあたって、森様が大切にされている観点などありましたら、教えて頂けたらと思います。

自動化、というより、テスト、ということについて、もともと考えていたことがあります。
テストを上手く行うには、3つのことに取り組む必要があると思います。
まず、作業の自動化です。テストにはどうしても繰り返し作業が発生しますから、可能なかぎり、自動化を進めることが肝要です。
次に、探索的テストの導入。これはかねがね感じていることですが、たとえば、何万項目ものテストをクリアし、エラーがゼロだった、よかった、というのは、どうかなと思うのです。テスト項目は、様々なやり方、つくり方をして、バグを見つけにいく、こうした姿勢というか、取り組みが大切だと感じています。
最後に、高品質なテストケースの作成。探索的テストの話と重なりますが、テストケースは、バグを見つけて意味があると考えており、バグを出せないテストケースは廃止し、新しいものへ切り替えていく必要があります。2016年の論文が探索的テストを対象としており、今回自動化をテーマとしましたから、テストケースの話は、これからもっと取り組んでいきたいと考えています。

ご質問へ戻りますと、このように、自動化というものはテストに必要な手段と考えています。
そのうえで、自動化そのものに対する観点、という意味では、特に、自動化は「人が何か新しいことへ取り組む」ための手段と考えています。自動化の目的も、ROIも、それ込みで考えるべきと思います。

– 探索的テストについてお話がありました。
Eggplant AIでは、カバレッジを見ながら半無作為に操作手順を選択し続ける中で、バグの出たアクションについて学習をします。
学習されるのは、機能名やルートといったアクションそのものではなく、アクションへ付与されたパラメータです。たとえば、地図情報と連携する、とか、文字入力がある、とか、インターネットへ出る、とか。そうしたパラメータへバグのリスクが蓄積されます。
そうして算出されたリスクに基づき、テストケースを作成していく、探索的テストを自動化する、と説明されています。

探索的テスト、というのは、いろいろな人が誤解しているところもあるように感じています。
「Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design」という本があり、この本に詳しく述べられているのですが、探索的テストは、本来熟練したテストエンジニアによって行われるものです。
たとえば、開発者の癖を見抜いてバグを見つけにいく。スキルの高いテストエンジニアによるテストは、テスターによるそれよりも検出率が高い、という研究成果もありますが、目的としては、バグの検出率を効率的に上げること、カバレッジ (※5) を見るだけでは埋められない穴を埋めるための手法となります。

Eggplantなら、近いものがあるかも知れませんね。
Eggplantは、海外製品にしては、コンセプトがわかりやすいと思います。Eggplantの業務を社内で引き継ぐ際にも、あまり問題が発生しませんでした。

ところで、AIの話ですが、AIって、結果が「よい感じである」ということで、なぜその結果がよかったのかはだれも説明できない、やってみないとわからない、そういう側面があると思います。
私は以前、音声認識をやっていました。様々苦労したのですが、たとえば、認識率が95％から中々上がらない。それでさんざん悩んだ経験があります。
いまでは、Googleはその壁を乗り越えてしまいました。その差は、クラウドとビッグデータです。これからは、やっぱりAIや、クラウドやビッグデータ、そうしたもので、いろいろ課題を乗り越えていくのだろうな、と感じています。

※5：coverage. あらかじめ決められた網羅条件が、テストによってどれくらい充たされたかを割合で表したもの。網羅率とも呼ぶ。

論文を書けば、理解が深まり、意識も高まる

– エンジニアとしての森様へお伺いしたいのですが、今回のように、論文を書く、という活動について、そのメリットデメリットなど教えて頂けますでしょうか？

まず、論文には社内論文と社外への論文投稿の2つがあります。
社内論文から説明しますと、当社では論文の大会があります。社内論文のテーマは、普段の自分の業務となります。
業務中は多忙で、納期もあり、目的を達成することに注力していますが、論文を書くにあたっては、それらを整理し、再構成して、わかりやすく論理的に説明しなければなりません。すると必然的に、自分が何をしていたのかの理解が深まるということは、いちばんのメリットかと思います。
また、論文を書くことに慣れてくると、普段の業務においても、論文に書けるよう目的や手段、効果をイメージしながら行うようになるという、そうした意識も高まってくるように感じます。

次に、社外への論文投稿ですが、これは社内論文そのままでは意味が通じません。社内用語を、一般的に通用するソフトウェアエンジニアリングの用語に置き換え、リライトしなければなりません。ここは、自分のソフトウェアエンジニアリングに関する知識や興味がものをいう部分だと思います。
社外への論文投稿のメリットは、やはり有識者の査読です。社内レビューでは得られない視点でのコメントを頂けるので、大変嬉しく、また非常に勉強になります。
論文発表当日には、聴講者の皆さんからの反応や、質疑などからも、新しい視点を得ることができます。プレゼンテーションの経験値が上がるのもメリットのひとつかと思います。

– デメリットはいかがでしょう？

社内論文においては、特にデメリットを感じたことはありません。
社外への投稿にあたっては、業務時間は使えないため、週末に書き進めるしかなく、自分の時間や家族との時間が削られる点というは、デメリットといえるかも知れません。
この点については、頑張ってAwardを獲得できると少し報われます。

近年、よくいわれる働き方改革で、テレワークというものが流行っています。最近では、We Workというコンセプトが出てきて、これはいろいろな企業の人が同じシチュエーションで仕事をするかたちをとります。
そうした時代になっていくということで、積極的に社外の知見へ触れていくことは、今後益々求められてくるのではないでしょうか。
SQiPでは、カフェ・ソフトウェアクオリティという勉強会 (※6) があり、これへの参加などもお勧めできます。

※5：通常、月1回開催されており、だれでも、connpassなどから参加申し込みができます。
https://cafe-swq.connpass.com/

– 有り難うございます。
最後に、今後の展望についてお聞かせください。

海外では事例があると聞きましたが、Eggplantとロボットアームとの連携による、自動化対象の拡張など、取り組んでいきたいと思います。また、今後新しい局面で、開発や製造の現場へEggplantを導入できれば、大きな成果を期待できるのではないかな、と考えています。

– 本日はお時間を頂き、有り難うございました！

おわりに

森様のテストに対する考えや、技術に対する姿勢など、話は多岐に渡り、とても面白い時間でした。
森様、有り難うございました！

Eggplantは、アナリスト業界で最も信頼されるレポートの1つであるThe Forrester WaveにおいてLeaderと認定される等、革新的な開発に定評があります。今後も、森様の取り組みをサポートするツールとして、当社もユースケースを増やして行ければと思います。

引き続き、よろしくお願いいたします。

■ ADOC Testing Service for Eggplantの概要へ
■ ADOC Testing Service for Eggplantの資料請求へ