なぜNECは、10万件以上のテスト項目があるプロジェクトで、UIテスト自動化ツールを導入できたのか5年前の失敗を乗り越え再挑戦(1/2 ページ)

NECの浦口宗也氏は、2015年10月に開催されたテスト自動化ツールの紹介セミナーに登壇。同社のUIテスト自動化ツール導入に関する取り組みを講演した。

» 2015年12月21日 05時00分 公開
[星暁雄ITジャーナリスト]

 テクマトリックスは2015年10月にテスト自動化ツールの紹介セミナーを開催。その一セッションにNECの浦口宗也氏(プラットフォームソリューション推進本部 マネージャー)が登壇した。

 NECは、全社向けSI施策として「テスト効率化ツールの貸出制度」を取り入れている。その活用の一環として、一度はテスト自動化に失敗し「自動化アレルギー」に陥っていた開発プロジェクトの現場にUIテスト自動化ツールを導入した。

 失敗の原因は何か、そして再挑戦のポイントはどこだったのかを見ていこう。

一度はテスト自動化に失敗、「自動化アレルギー」に

日本電気 プラットフォームソリューション推進本部 マネージャー 浦口宗也氏

 浦口氏は「テスト自動化に一回失敗した」と率直に語る。自動化を試みたのは、ある生産管理パッケージ開発プロジェクトの機能更改や保守作業に伴う検証作業である。テスト自動化ツールを導入したものの、自動化対象と見込んでいたケースの4%しか自動化できなかったのだ。テスト自動化を導入する工数が増えたのに、効果は一向に上がらない。開発現場では「自動化アレルギー」、つまりテスト自動化に対するマイナスのイメージが定着してしまった。

 だが、それは自動化に関してよく言われる「テストケースがグズだったら、自動化はそのグズを加速させるだけだ」という「べき論」の部分でつまずいたのではない、と浦口氏は語る。同社にとって最も重要だったのは「UIオブジェクトを自動化ツールが認識してくれるか」という点だった。具体的には、「グレープシティ製GUIコンポーネントを、当初採用したツールではテスト対象にできなかった」点が大きな課題となり、テスト自動化の対象範囲がなかなか広がらなかった。

 「テスト自動化に関する今までの議論では、UIオブジェクト認識に関する話題はあまり取り上げられていなかった」と浦口氏は指摘する。開発プロジェクトの現場に密着しなければ分からない「ツールがUIオブジェクトを認識するか否か」が、テスト自動化の成否を左右していたのだ。

大規模なテスト自動化では予想外の問題も

 このプロジェクトが大変だった理由の一つは、テスト項目数が「積み上げで10万件以上」と非常に多いことだ。搭載機能が多く、さらにパッケージの歴史が長くバージョンを重ねるごとに継続して保守を続ける項目が多いこと、Webとデスクトップのクロスプラットフォーム対応などの要因によるものだ。バージョンアップや保守に伴う既存機能の確認の分量も多い。

 浦口氏は、プロジェクトでの失敗原因として次の4点を挙げる。

  1. 手作業で検証作業を行っていたのだが、「自動化できる、できない」の判断がつかない箇所が非常に多く出てきてしまった
  2. 「画面だけでは合否判定ができず、サーバー上のログや物理ファイルなどを目視で確認し、出力に応じて手順を変える」といった、いわば「現場の流れ」で確立されていた作業のスクリプト化が困難だった
  3. Web画面は自動化がやりやすかったものの、検証項目数はそれほど多くなかった
  4. メイン画面に、グレープシティが販売するGUIコンポーネントを利用していたが、テスト自動化ツールがこのコンポーネントを認識できず、自動化の対象として取り込めなかった

 前述したように、このプロジェクトにとって、4の要因は大きかった。デスクトップのWindowsアプリケーションとWebアプリが混在したクロスプラットフォーム環境で、Windowsアプリケーションで活用していたグレープシティ製のGUIコンポーネントがテスト対象とならず、自動化の効果が非常に薄い結果となっていたのである。

失敗を乗り越え、テスト自動化のカバー範囲拡大に乗り出す

 この失敗から5年が経過した。ある日、テスト自動化ツールを貸し出す施策の窓口だった浦口氏の部署に声がかかった。その内容は、「自部門で買ったテストツールが維持できないが、自動化できたところだけは使い続けたい。施策窓口のライセンスを貸してもらえないだろうか?」というものだった。

 ここで浦口氏らは考えた。「効果が薄いテスト自動化の仕組みを使い続ける状態を良しとしていいものだろうか?」浦口氏らは「自動化の立て直しをさせてもらえませんか?」とプロジェクト側を説得。その結果、テスト自動化の再構築を一緒になって推進することで合意したのである。

 再度のテスト自動化導入は、【1】課題整理、【2】ツール再評価、【3】導入計画(スケジュール線引き、メンバーの役割と体制作りなど)、【4】導入前準備(利用ガイド、サンプルスクリプトの作成など)の4ステップに分けて進め、およそ半年で導入にこぎ着けた。

 ツールの評価では、日本国内に代理店がない海外製ツールも含めて評価した。その中でオーストリアの新興ベンダーRanorex社のツール「Ranorex」に白羽の矢が立った。評価したツール群の中で、グレープシティが販売するコンポーネントをテスト自動化対象として認識ができるのはRanorexだけだった点が大きい。

 まだ日本に代理店がない段階だったが、同社はRanorexの採用を決めた。その後、テクマトリックスがRanorexの日本語化と国内販売を進めている。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。