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