アプリケーションの機能テスト自動化が、なぜ進んでいないのか？ Part 3

同じテーマで、連日のブログを書くことがほとんどないのですが、

2009/10/05 アプリケーションの機能テスト自動化が、なぜ進んでいないのか？

2009/10/06 アプリケーションの機能テスト自動化が、なぜ進んでいないのか？ Part 2

ということで、3日連続の投稿となります。
（だらだらと引っ張っているだけという気もしますが。。。）

さておき、昨日の積み残し

「どのようなケースが機能テストの自動化に向いていて、
　どのようなケースが向いていないのか？
　という考察がどれだけなされているのでしょうか？」

について、書かせて頂きます。

--

まずは、「どのような」をどこに視点を置くかというポイントがあるかと思います。

開発フェーズ毎の適用性という視点で考えた場合ですが、当社では、機能テストに向いているケースについて、以下のようなお話をさせて頂いております。

--

一方で、画面レイアウトやオブジェクト（リンク、メニュー、フォームの項目など）の変更が頻繁になされる場合は、上記のような適用性があると思われる各フェーズにおいても、向いていないことになります。

テストスクリプトの再利用など、テスト資産を有効活用することで、ROIは更に向上していくわけですが、1ショットの開発をして、継続的な保守を行わないようなアプリケーションでは、十分な投資効果が得られない場合もあるかと思います。

そのような場合においても、正常系のテストを一定時間ごとに実施することで、エンドユーザ目線でのサービス稼働状況監視として、正常稼働しているか？、レスポンスに問題がないか？、きちんと表示されているか？ということを自動的に検査して、異常時のみアラートメールを管理者・担当者に送るといった運用に、十分な価値を見いだせるかもしれません。

従来、あまり行われていないかもしれませんが、単なるROIではなく、ダウンタイム最小化や、ユーザが気づく前に早期の対応を行うことなどを含めて、徐々に広がりを見せるものと想定しています。

--

次に、別な視点として、システムで『採用するテクノロジーによる向き不向き』ついて考えた場合、フルにRIA（Rich Internet Applications）/リッチクライアントを採用したアプリケーションでは、ツール側が十分に対応できていない場合も多く、あるいは採用するRIA/リッチクライアント（テクノロジー）に対応したテストツール製品を導入するか、導入したテストツール製品が適用可能なRIAを採用していくか、という判断が必要になります。

フリーのツールも含めて、RIA/リッチクライアントに対応していない、あるいは得意としていないテストツールが多いことからも、選択肢が少なくなり、機能テストの自動化採用の判断において、二の足を踏む、あるいは導入を見送る可能性が高くなるものと思われます。

機能テスト重視ということであれば、RIA／リッチクライアントの見送りということもあるかと思いますが、C/S（クライアント・サーバ）系アプリケーションなどで親しんだキーボード操作（入力インターフェイス）を継続したいなど、業務効率・品質を重視ということであれば Curl・Biz/Browzer・SilverlightなどのRIA/リッチクライアントを中心としたアプリケーションを開発することでしょう。

コンシューマ系においては、更に、Flash/Flex/Air・Ajax... といったアプリケーションが広く採用されている現実もあります。

一方で、フルにRIAとなっているかというと、限定的な採用に留まっている場合も多いので、機能テストツールの導入も、十分な適用可能性が出てくるものと思われます。

--

以上、突っ込みどころ満載かもしれませんし、説明不足もあるかと思いますが、それらを是非とも、コメントに残して下さい。