テスト自動化の失敗談
次はやや時代が進んで2005年ぐらいの失敗談です。対象は社内向けのドキュメント管理システムです。サーバ本体はJava、フロントエンドとしてVisual Basic（以下、VB）クライアントを持っていました。典型的なクラサバ構成です。筆者はこのシステムの開発には関わっていませんでしたが（オフショアで開発が進んでいました）、テストに関して相談を受けました。
ちょうどシステムテストぐらいのフェーズだったと思います。テスト手順が煩雑なため、回帰テストの負荷が高くなっていました。そこで筆者のところにテストツールの相談が舞い込んだのです。
依頼の内容は、「回帰テストの手間を削減するため、VBクライアントのキャッチ＆リプレイ機能を持つツールを選択してほしい」というものでした。当時はSelenium IDEが出てきたぐらいの時期でOSSのテストツールは少なく、商用ツールを使うのが普通でした。ツールにはいくつか候補がありましたが、VBの部品をオブジェクト認識できる「QTP」（当時マーキュリーインタラクティブ、現HP）を選択しました。バージョン9だったと思います。あらかじめ渡されていたテストシナリオをスクリプト化してテスト実行し、動作を確認し、一応の評価を得てこの仕事は終了しました。
ところが、その後どうもQTPを使っているという話が聞こえてきません。どういうわけかシステム自体の開発が停まり、それに伴ってQTPも放置されてしまったようです。アプリの固有機能のために作り込んだスクリプトもあったのですが、そのまま闇に葬られました。
この話でギア本第1章から学んだ教訓
- プロジェクトが死んでしまうとツールも死ぬ
- ツールの推進役（チャンピオン）の推進力重要
これはギア本でいうと第10章以降の話になります。解説は、本連載の後の回で第10章を紹介する方にお任せします。すぐに気になる方は、『システムテスト自動化 標準ガイド』の第10章をお読みください。
以下は、この失敗ケースで得た教訓です。
- 「非現実的な期待」
-
システムテストあたりで出てきた話なので仕方ない面もありますが、オフショアを使った案件であったために、過度な期待があったのかもしれません。現状はこうで、ツールを入れた後はこう変わってほしいという、いわゆる「ギャップ分析」のようなことを全くしませんでした。「なんとなくツールを入れればいいんじゃね？」程度の安易な考えでツールを導入したように思います。
- 「組織の問題」
-
筆者のロールがテストツールの評価で終わってしまったことが、このケースでの敗因ともいえます。ツールチャンピオンとしてプロジェクトに貼り付き、オフショアに指導に行くぐらいのことをしてもよかったのかもしれません。また、これは筆者の責任ではありませんが、実案件が続かなかった点も大きいかもしれません。
