テストツールのセミナーやった後に、こんなアンケート回答を見つけました。
『アプリケーションの操作を行った後正しく動作するかのテストは
開発会社の責任として任せていて、
テストツールは開発会社が使うものであり
ユーザー企業が使うものではないと考えている』
日本の開発現場のほとんどがこんな感じなんでしょうね。
作業自体は開発会社丸投げ、できたものに対するクレームも
「瑕疵」の一言で全て開発会社へ。
ユーザ企業は実装が意識できない、漠然とした仕様書を作成するだけ。
もちろん、開発側がテストをしないことは言語道断ですが
システムに対する品質の責任は開発側だけに押し付けていいものか疑問が残ります。
（そのシステムを使うのはユーザー企業ですよね？）
回答に対しては
「社内向けでも公開系でもシステムの品質が悪かった時
『この品質が悪いシステムの開発はXXXがやっていて、ウチの問題じゃないんだよ』
と言った時にそのシステムを使用する人が納得するか、ということです。
品質は開発側だけの責任というのは誤っているのではないでしょうか？
受け入れとは、開発側が作ったものに対して、
責任を負うに足りるかを判断する為に行うものでなければなりません。
（リリース前の最後の防波堤となるべきです）
検収時に開発側から上がってきたテスト仕様書、
エビデンスを見ることでも良いですが、
実際に動作することを確認することが本来の検収であると思われます。
動作確認をいちいち手作業で行っていると、
かかる時間は開発時のテストと同じかそれ以上かかることでしょう。
そこで、ツールで生成したスクリプトを使用することで
自動的に実施できるテストケース分の時間を短縮することができるのです。
また、ミドルウェアのパッチ等のバージョンアップの際には
デグレが発生しないか確認する為に、全てのテストを実施すべきです。
流れとしては、
テストケースを実施する⇒問題が出た場所の調査⇒
改修⇒デグレってないかテスト・・・
となりますが、
テストツールを使用していて、回帰テストが容易に実現可能な環境があれば、
全て手動でテストを実施することに比べて、工数を少なくすることができます。
余った分をさらに品質を上げる為に使うか、そのまま利益とするかは思いのままです。
余裕ができるのは間違いありません。
テストツールを使うことが目的ではなく
・発注元の責任を全うする
・保守しやすいシステムにする
といった目的を達成しやすくする為にテストツールを使うように考えると、
テストツールは開発会社だけのものだけではないと思えませんか？」
と返したい。
# もちろん実現するためには、ユーザ企業だけでなく
# 開発会社がツールを使って開発効率を上げたり
# 保守しやすいシステムにしなければならないのですが。
# そういった意味では、「ユーザ企業が使うものではない」というのは
# 合っている気がします。
# また、どちらが費用を負担するか、という点は非常に難しいです。
# テストツールは高価なので、プロジェクト１つだけでライセンス料を
# ペイできるものではありませんし、
# 従量課金制のモデルならまだいけそうですけど。
