ソフトウエアの開発プロジェクトを，サッカーにたとえると，テスト担当者はゴールキーパーに相当します。サッカーでは，メンバー全員が「攻め」だけではなく「守り」もできなくてはなりません。この，サッカーで言う「守り」がソフトウエア開発におけるテストに当たります。
最近，ソフトウエアの品質にまつわるトラブルが大きく報道されるようになりました。検索エンジンで「プログラムミス」「システム障害」「ソフトウエア不具合」などのキーワード検索をすると，その検索結果の件数にビックリするかもしれません。
これらのトラブルの原因がすべて，「ソフトウエア・テストの工程をおろそかにしたことにある」とは言えないでしょう。とはいえ「十分なテストをしていれば，ある程度は防げた」ということは言えるのではないでしょうか。テストは，品質を守る大切な役割を担っています。しかし開発の現場では，「ちゃんと作ればテストなどいらない」「テストまで考えてる暇はない」「テストをしっかりやりたくてもノウハウがない」などの様々な理由で，二の次にされてしまっていることが多いのです。
テスト担当者はゴールキーパーである
ソフトウエアの開発プロジェクトを，サッカーにたとえてみましょう＊１。サッカーという競技は，各メンバーが自分たちの役割を果たしながら，かつメンバー間の不足を補いながらゴールに向かって攻めていきますよね。これは，ソフトウエアを開発していくときの，プロジェクト・マネージャ，設計者，プログラマの関係とよく似ています。
サッカーでは，メンバー全員が「攻め」だけではなく「守り」もできなくてはなりません。この，サッカーで言う「守り」がソフトウエア開発におけるテストに当たります。守りの専門職であるゴールキーパーがテスト担当です。
サッカーには，完全な防御方法はありません。点を入れられてしまう可能性は常にあるわけです。これと同じで，ソフトウエア・テストにもすべてのバグを発見する方法はありません。プログラムはいくらでも複雑に作ることができますし，時間的，経済的な理由からテストをいつまでも続けることはできないからです。
ここで，「完全にできないからがんばってもしょうがない」と結論付けたらそれまでです。大事なことは，不完全だからこそ，効果的な方法でテストする腕が必要だということなのです。
得点させない仕事はみんなの仕事
無得点に抑えるには，自陣にボールを持ちこませないようにする，つまり，他のメンバーが攻めて守って，ゴールキーパーは仕事をしなくても済むという状態が理想です。ゴールキーパーが常に忙しいような試合を見たら，たとえ無得点に抑えていても，誰もが危ないと感じるはずです。得点されないように守るのはゴールキーパーだけの仕事ではないんですね。
「守り」をテストにたとえても同じことが言えます。開発の初期段階からテストを開始し，開発者自身が単体テストや結合テストをきっちり行い，テスト担当が行うシステム・テストでは，もはや細かいバグは出ない状態を作ることを目標にするべきです。
かといって，優秀なチームができたらゴールキーパーはいなくてもよい，もしくは誰でもよいとはならないですよね。試合の中では攻撃陣でうまく守れたとしても，フリーキックやPKがあります。ゴールキーパーも優秀でなければならないはずですし，そうなるように自分の技術を磨こうと日々練習に励むはずです。
ソフトウエア開発も同様です。テスト担当者はいなくてもよい，もしくは誰でもよいということはありません。テストの技術を身に付けてスキルアップしていくことが必要なのです。
試合状況を一番良い位置から見られる
ゴールキーパーは，ピッチの中の一番いい位置から冷静に試合を見て，他のプレーヤーの配置などを指示していますね。どのように攻められると守りにくいかもよくわかっているので的確な指示が出せるのでしょう。
これと同じで，テスト担当もテストするソフトウエアが来るのをただ待っているようではプロとは言えません。自ら設計まで関与することで，品質の作り込みに貢献することが大切です。
テスト担当は開発の当事者ではないので，要件定義や設計の段階で冷静に状況をチェックできます。また，テスト設計のために開発資料を読み込んでいくため，詳細な部分まで見ていくことができます。開発者が自ら品質向上を行うという意識が高まるように，テスト担当はあの手この手を使う姿勢が必要でしょう。
また，サッカーでは，ゴールでボールを取ったら攻撃陣の攻めやすい適切な場所へボールを渡することもゴールキーパーに必要な技術です。テスト担当も，バグを見つけたら開発者がデバックしやすいように現象を切り分けて，バグ・レポートを開発者に伝えます。これも重要な技術です。
以上のことをまとめてみましょう。
・完全なソフトウエア・テストはできない。だからこそテストの腕を磨こう
・テストは開発メンバー全員の仕事なので，テスト担当だけでなく全員がテストについての技術を身に付けよう
・どんなに開発者が優秀でも，テスト担当自身も技術力を磨こう
・テスト担当は受け身にならず，常に開発全体を見渡してフィードバックをかけるための技術を身に付けよう
一口にテストといってもいろいろある
サッカーからの教訓で，テストは開発メンバー全員の仕事と書きましたが，それぞれのメンバーが行わなければならないテストは一言ではくくることができないくらい，いろいろな種類があります。
では，実際にテストはどのようなことをどんな順序で行っていくのでしょうか。その疑問に答えてくれるものの一つが，開発工程とテストとの関係を表す「Vモデル」です（図1）。Vモデルでは，開発工程に対応した形でテストの種類を決めています。
テストに工程を設けるのは，テスト対象への視点を整理することでテストが混乱しないようにするためです。例えば，メソッドのパラメータの組み合わせパターンのテストと，システムとしての使い勝手を評価するためのテストでは，テスト担当も違えば，テスト環境やテスト実施方法も違います。また，工程を分けてより早期にテストを始めることで，問題の切り分けを楽にするという意味もあります。
では，図1の下の部分から各工程のテストを順番に見ていきましょう。
