アプリケーションの機能テスト自動化が、なぜ進んでいないのか？ Part 2
昨日のブログ
2009/10/05 アプリケーションの機能テスト自動化が、なぜ進んでいないのか？
の続編となります。
昨日のエンディングパートでは、
「日本においては、
技術・品質レベルが高い＝商用テストツール不要論
テストツールは使いたいけど使えない＝高い、難しい、手間がかかる
本当にそうなのでしょうか？
また、どのようなケースが機能テストの自動化に向いていて、
どのようなケースが向いていないのか？
という考察がどれだけなされているのでしょうか？」
という「？」で終わっていたので、その続きとなります。
--
まずは、
- 技術・品質レベルが高い＝商用テストツール不要論
- テストツールは使いたいけど使えない＝高い、難しい、手間がかかる
という2点について。
1．技術・品質レベルが高い＝商用テストツール不要論
ツールは、ツールです。
優秀かつレベルが高い人ほど、ツールを使いこなすことができ、より、パフォーマンスを高めることができたり、ツールにある部分を担ってもらうことで、より自分の高い技術を活かすべきことに、時間や頭脳を割り当てる事ができるのではないでしょうか？
あるいは、ツールは優秀なエンジニアによって活かされる（生かされる）ということかもしれません。
そこで、
- 自力で自社に合ったツールを作るという時間・コストを掛けること
- 高品質であるが故にテストに時間を掛けないこと
何れも否定はできませんが、まず、
自力で自社に合ったツールを作るという時間・コストを掛けること
について、
汎用的なツールを使えば良いパートに、優秀な能力を使うべきなのか？
一方、
「汎用的なツールは信用できない」
というエンジニア魂（いや、実際には、ツールで信用できなかった経験則であったり、ブラックボックスが故）も理解できます。
しかしながら、
「このツールは、このパートなら使えるんだ」
というプロならではの見極めも可能ではないかと思います。
これにより、自社製ツールの開発・保守（あるいは、自社製ツール自体のテスト）を行う時間もコストも抑制できる可能性があると思われます。
類似システムで、他社が一定の実績をあげていたり、導入実績があれば、
「あのツールは使わない」
ではなく、
「あのツールは、こういったところに使える」
に変わると思われるので、少しでも多くの事例が、表舞台にでてくることも重要かと思います。
-
次に、
高品質であるが故にテストに時間を掛けないこと
についてですが、対象のアプリケーションのバグなどによる影響度、業務上の重要度などにも関係するので、容易な判断はできませんが、
想定する手動テストを十分に積算し、自動テスト導入・活用に要する時間・コストと対比してROIが見込めるケースであるならば、ツール導入が適しているであろうことは、あまり否定されないところかと思いますが、それ以上に、
「手動では対応できないテスト」
「自動化することにより品質向上が見込めるテスト」
を行うことで、従来と同等以上の品質や、テストに要する時間の削減が成せる可能性があることを否定せずに、考えて頂きたいところです。
--
2．テストツールは使いたいけど使えない＝高い、難しい、手間がかかる
まさに、ここは避けて通れない道です。
- 高い
費用対効果が求められるツール導入です。
テスト工数削減効果、テスト人員不足を補えるか、バグによる手戻りをどれだけ抑制できるのか・・・
しかし、それ以前に、高額なツール導入が、大きなハザードとなります。
５００名ｘ１００万円＝５億円、年間２０～３０％の更新料やバージョンアップ費用、セルフラーニングに費やす時間コストや有償のトレーニング受講コスト、更に、オンサイトでの有償サポートコスト。５年で１０数億円の投資が必要となります。
これが、同時使用数でのFloatingタイプのライセンスや、期間ライセンス（レンタルのような）やSaaS的な利用した分だけのライセンスとの組み合わせであったり、1/5～1/10までコストを圧縮できれば、費用対効果を出しやすくなります。
- - 難しい
フリーのツールで、導入コストは0円であっても、ツールの難しさから、実際に標準化や全体での使用ができないということでは、本来のテスト自動化の目的を十分には活かすことができませんが、開発部門での導入には、一定の効果が期待できるものと思われます。 しかしながら、フリーのツールも、前述のような高級なツールも、習得に1ヶ月以上の時間を要することなどから、小規模なプロジェクトや短期のプロジェクトでの適用は困難となります。
開発部門、品質保証部門、受け入れ（情シス部門またはエンドユーザ）で共通の基盤となるツールとなるような、使い勝手の良さ、非常に短期間（ex. 1週間程度のセルフラーニング）での習得が可能であるならば、飛躍的に、機能テスト自動化の導入が進む可能性が高まると思われます。
- - 手間がかかる
短期間で習得できたとしても、実際のテスト対象アプリケーションでの適用性が無ければ、調査やテスト自動化の準備さえも無駄に終わり、手間のかかるツールとなってしまいます。
そうならないためにも、テスト自動化ツールが、どのようなアプリケーションに対応していて、どのようなアプリケーションを苦手としているかという特性を掌握する必要があります。 例えば、RIA（Rich Internet Applications）インターフェイスでの検証ポイント挿入や、操作の記録が不十分であることなど、ツール自体の制限や特性は、事前に掌握できることも多いかと思います。
しかしながら、それ以上に、最も懸念されるポイントが、画面を中心とする仕様変更・追加への追随性です。
仕様変更により、蓄積したテスト資産（テストスクリプト）が使えなくなってしまうことが最もマイナスなことであり、「手間がかかる」こととなります。
対策としては、ツールが提供するオブジェクトを追随する機能や特性を掌握し、追随性を高める為の開発時の規約整備が必要となります。
それでも、マルチOS・マルチブラウザでのテストをリリース毎、ミドルウェアなどのアプリケーション以外の変更毎に実施することを考えると、「正常系だけでも自動化する」ことで、手間がかかるテストを自動化するメリットは享受できるものと思われます。
--
「どのようなケースが機能テストの自動化に向いていて、
どのようなケースが向いていないのか？
という考察がどれだけなされているのでしょうか？」
が、積み残しとなりましたが・・・
＜＜次回に続きます＞＞