テストが単純作業だと思っているマネジャーは、今でも少なくありません。新人でも使えない奴でもいいから、とにかく人員を投入して残業をさせろ、という指示を出すタイプですね。こうしたマネジャーの興味を強く惹くのは、大きくわけて2つの誘惑です。一つは、とにかく安い外注を使うこと。パートでも、オフショアでも構いません。外注を叩いて叩いて、同じ予算でなるべく多くの人員を投入しようとします。もちろん技術力の評価など二の次で、せいぜい過去に同種のプロジェクトをこなしたかどうか程度しか確認しません。

もう一つは、テストの自動化です。テストツールを買いさえすれば、ノウハウいらずで大量のテストができるようになるのではないか、という発想ですね。皆さんの周りには、こうしたマネジャーはいらっしゃいませんか？

しかし、テストを自動化するだけでテストが楽になる、というのは幻想に過ぎません。最近はテストツールのベンダやリセラの営業さんだって、そんなヒドイ嘘はつきません（うちのツールを買えば万事オッケー、などという営業さんは追い返しましょう）。テストの自動化は、使いこなせば大きな効果を挙げられますが、何もしないと宝の持ち腐れになってしまいます。

テスト自動化の権威であるLinda Hayesは、StickyMindsのコラム"Fear of Automation"でこう語っています：スティーブン・キングがMicrosoft Wordに仕事を奪われると恐れているとは思えないわ。そう、テストの自動化を成功させるには、ツールではなく、どんなテストをしているのか、が重要なのです。

テストの自動化を成功させるには、いくつかのポイントがあります。まず、何を自動化すべきかをきちんと把握すること。次に、人手でどの程度きちんとテストできているかを判断すること。最後に、自動化できない部分や自動化による手間を評価することです。この３つを怠ると、せっかくテストツールを買っても活用できず、棚の上に眠らせることになってしまいます。残念ながら現在の技術では、買っただけで済むテストツールは存在しません。

テストにおいて自動化できるのは、大きく分けて6つあります。最も有名なのは、テストの実施ですね。人間が行うテスト作業の肩代わりと考えてもよいでしょう。e-TesterやWinRunnerなどマウスやキーボードの操作を記録し再生するツールや、xUnitなど開発環境上で関数やクラスに引数を与えて実行するツールを用いて自動化することになります。特に区別せずにテストの自動化という時は、テスト実施の自動化を指すことが多いようです。

自動化という言葉のイメージとは異なりますが、負荷テストツールもテストの実施の自動化にあたります。ただしテストの実施そのものを自動化するというよりも、実施の支援を行うという表現の方が的確でしょう。1000人同時アクセスが必要となる場合、人手を1000人分集めるのは大変ですから、負荷テストツールのようなテスト実施支援ツールを用いることとなります。

テストを実施したら、テスト結果を観測することが必要でしょう。誤字脱字やフリーズのようにテスト結果が簡単に分かる場合はともかく、バッファオーバーフローやメモリリークといったマシン内部の状態はツールを使わないと分からないことがほとんどです。またホワイトボックステストのカバレッジも人手ではなかなか測定できません。そこでPurifyやBoundsCheckerなどメモリの状態を観測するツールや、CodeTESTなどパスカバレッジを測定するツールを用いることになります。テスト技術者だけでなく、開発者が使うことも多いですね。

そもそもテスト項目を自動で設計してくれるツールはあるのでしょうか。少ないながら、特定のテスト技法（アルゴリズム）にしたがってテスト設計を行ってくれるツールが存在します。Jtestなどパステストを設計してくれるツールが良く知られていますね。また直交配列表や全ペア法にしたがって組み合わせテストを設計してくれるツールもあるようです。もちろん万能のツールではありませんが、出来ることと出来ないことをきちんと理解して使えば便利でしょう。

テストマネジャーやプロジェクトマネジャーには、テスト管理支援ツールやバグ管理支援ツールが有用でしょう。TestDirectorなどテスト項目の進捗を一元管理するツールや、ClearQuestやBugzillaなどバグ修正の状況を管理するツールを用いることになります。内製のツールを使っている場合もありますね。開発全体で使っているツールと不整合が生じないようにしないと、かえって手間がかかってしまったりします。

忘れてはならないのが、テスト環境の構築を自動化してくれるツールです。ハードディスクやデータベースを初期状態に戻すツールや、環境の自動配布を行ってくれるツールなど多岐に渡ります。何か特定のベンダのツールを用いるというよりは、知恵を絞ってフリーウェアのツールを活用する場合も多いようです。

このように何を自動化すべきかを把握したら、人手でどの程度きちんとテストできているかを判断し、自動化できない部分や自動化による手間を評価することが必要になります。特に重要なのは前者です。行き当たりばったりのテストをしている現場では、自動化の効果は極めて薄いでしょう。抜けが多くてバグがちっとも見つからないテスト項目を自動化しても、OKの結果が積み上がるばかりで、カバレッジも広がらなければ不具合検出率も向上しません。自分たちのテスト組織の実力を把握し、自動化をすることで何をしたいのかをよく考えないと、自動化という果実の旨みは味わえません。

こう聞くと、うちの組織はテストのレベルがイマイチなのでツールを買っても損をするだけなのか、と思われるかもしれません。皆さんの組織がずっとイマイチであるならば、答えはYesです。しかしツールを買っても買わなくても、こうした組織はズルズルと効果の低いテストを続け、残業ばかりなのにバグを見逃し、いつか破綻してしまいます。

ツールを買うメリットは、組織が現在行っている作業をツールに肩代わりしてもらうことではありません。ツールを買い使いこなそうとすることによって、組織のテストのレベルが向上することなのです。例えば、テスト設計もせず行き当たりばったりでテストをしている組織が、GUI自動操作ツールを買ってテスト実施を自動化したとしましょう。始めは、人手で行っていたテスト操作を記録して再生するだけしかできません。しかし似たようなテストを自動化していることに気付くと、まずは自分たちが行っているテストを紙に書いて整理するようになります。次に似ているテスト項目と似ていないテスト項目を分類するようになるでしょう。似ているテスト項目を眺めていると、なぜ似たようなテスト項目を何度も実施しなくてはならないのか、という点に疑問を持つはずです。ここまで来れば、重複したテストケースの優先順位を下げ、異なる狙いを持つテストケースの優先順位を上げるようになります。気が付くと、網羅的にテストを行うためにカバレッジを測定するようになっているでしょう。

テストツールは、銀の弾丸や魔法の杖ではありません。自分たちの実力をそのまま映し出す鏡なのです。鏡に映った自分たちを受け入れずにツールを投げ出すか、受け入れてテストの改善に結びつけるか、決めるのも自分たちです。ツールの導入をきっかけとして、テストの改善にぜひ乗り出しましょう。