NECの浦口宗也氏は、2015年10月に開催されたテスト自動化ツールの紹介セミナーに登壇。同社のUIテスト自動化ツール導入に関する取り組みを講演した。
テクマトリックスは2015年10月にテスト自動化ツールの紹介セミナーを開催。その一セッションにNECの浦口宗也氏(プラットフォームソリューション推進本部 マネージャー)が登壇した。
NECは、全社向けSI施策として「テスト効率化ツールの貸出制度」を取り入れている。その活用の一環として、一度はテスト自動化に失敗し「自動化アレルギー」に陥っていた開発プロジェクトの現場にUIテスト自動化ツールを導入した。
失敗の原因は何か、そして再挑戦のポイントはどこだったのかを見ていこう。
浦口氏は「テスト自動化に一回失敗した」と率直に語る。自動化を試みたのは、ある生産管理パッケージ開発プロジェクトの機能更改や保守作業に伴う検証作業である。テスト自動化ツールを導入したものの、自動化対象と見込んでいたケースの4%しか自動化できなかったのだ。テスト自動化を導入する工数が増えたのに、効果は一向に上がらない。開発現場では「自動化アレルギー」、つまりテスト自動化に対するマイナスのイメージが定着してしまった。
だが、それは自動化に関してよく言われる「テストケースがグズだったら、自動化はそのグズを加速させるだけだ」という「べき論」の部分でつまずいたのではない、と浦口氏は語る。同社にとって最も重要だったのは「UIオブジェクトを自動化ツールが認識してくれるか」という点だった。具体的には、「グレープシティ製GUIコンポーネントを、当初採用したツールではテスト対象にできなかった」点が大きな課題となり、テスト自動化の対象範囲がなかなか広がらなかった。
「テスト自動化に関する今までの議論では、UIオブジェクト認識に関する話題はあまり取り上げられていなかった」と浦口氏は指摘する。開発プロジェクトの現場に密着しなければ分からない「ツールがUIオブジェクトを認識するか否か」が、テスト自動化の成否を左右していたのだ。
このプロジェクトが大変だった理由の一つは、テスト項目数が「積み上げで10万件以上」と非常に多いことだ。搭載機能が多く、さらにパッケージの歴史が長くバージョンを重ねるごとに継続して保守を続ける項目が多いこと、Webとデスクトップのクロスプラットフォーム対応などの要因によるものだ。バージョンアップや保守に伴う既存機能の確認の分量も多い。
浦口氏は、プロジェクトでの失敗原因として次の4点を挙げる。
前述したように、このプロジェクトにとって、4の要因は大きかった。デスクトップのWindowsアプリケーションとWebアプリが混在したクロスプラットフォーム環境で、Windowsアプリケーションで活用していたグレープシティ製のGUIコンポーネントがテスト対象とならず、自動化の効果が非常に薄い結果となっていたのである。
この失敗から5年が経過した。ある日、テスト自動化ツールを貸し出す施策の窓口だった浦口氏の部署に声がかかった。その内容は、「自部門で買ったテストツールが維持できないが、自動化できたところだけは使い続けたい。施策窓口のライセンスを貸してもらえないだろうか?」というものだった。
ここで浦口氏らは考えた。「効果が薄いテスト自動化の仕組みを使い続ける状態を良しとしていいものだろうか?」浦口氏らは「自動化の立て直しをさせてもらえませんか?」とプロジェクト側を説得。その結果、テスト自動化の再構築を一緒になって推進することで合意したのである。
再度のテスト自動化導入は、【1】課題整理、【2】ツール再評価、【3】導入計画(スケジュール線引き、メンバーの役割と体制作りなど)、【4】導入前準備(利用ガイド、サンプルスクリプトの作成など)の4ステップに分けて進め、およそ半年で導入にこぎ着けた。
ツールの評価では、日本国内に代理店がない海外製ツールも含めて評価した。その中でオーストリアの新興ベンダーRanorex社のツール「Ranorex」に白羽の矢が立った。評価したツール群の中で、グレープシティが販売するコンポーネントをテスト自動化対象として認識ができるのはRanorexだけだった点が大きい。
まだ日本に代理店がない段階だったが、同社はRanorexの採用を決めた。その後、テクマトリックスがRanorexの日本語化と国内販売を進めている。
Copyright © ITmedia, Inc. All Rights Reserved.