ソフトウェア開発でのテストとは何かを単純に言うと、成果物が期待通りであるかを検証する作業といえる。こう動作してほしいという期待を入力に、成果物がその通りに動作するかを検証するのがテストである。

となると、成果物とは何で、期待とは何かが問題になるのだけれど、これが一筋縄ではない。というのも、システムは十分に複雑なので、ある部分を複数の部分に分けることもできるし、その部分をより大きな部分のパーツにすぎないとみなすこともできるからだ。

だからといって、一番大きな単位でもって期待通りにあるかどうかを検証すれば済む話かというとそういうわけでもない。というのも、大きな単位には大きな単位なりの期待が、小さな単位には小さな単位なりの期待というものが存在するからだ。

システム開発は、ひとつのものさしではかることができない。システムをつかって業務を遂行できるかという検証と、その部品であるクラスの検証では、成果物も期待も違うからだ。

いわゆるV字モデルは、このことを表現している。システム要件、基本設計、詳細設計、プログラム設計、それぞれの水準ごとに成果物と期待を踏まえたうえで、要求されるテストの粒度をモデル化している。システムが期待通りであるかを検証するためには、システム要件に従って動作するかを受け入れテストとしてテストすればよい。システム全体の機能・非機能を満たすかどうかなら基本設計をもとにシステムテストを行なえばよい。ある機能が期待通りに動作するかは詳細設計で結合テスト、ある部品が期待通りに動作するかは単体テストだ。

テストには階層があって、それぞれの階層ごとにテストする対象とテストする内容が違ってくる。各フェーズにどのようなタスクを含めるかという問題（極めて政治的な問題だ！）はさておき、各テストにはそれぞれ対象とする成果物と期待とがある。このことをテスト観点といったりもする。

さて、ここまで話をしたところで、この話は「ウォーターフォール」の話であって私がやっている開発方法にはそぐわないという人もあるかもしれない。たしかに、現代的な開発では顧客の要求は明らかではないし、開発のサイクルの中で基本設計書や詳細設計書は作成する前に陳腐化してしまう。だから、基本設計書や詳細設計書にもとづくテストを計画することはできない。その話はその通りなのだけれど、あなたがある粒度で成果物をつくることには違いないことに注意してほしい。

たとえば、ユーザーストーリーに従って実装するときに、実装がユーザーストーリーの期待通りに動作するか、それを検証するためのテスト観点が必要になってくる。また、ユーザーストーリーを実現するためには、いくつかのコンポーネントを組み合わせて実装をおこなっているはずだ。そのコンポーネントのテストとコンポーネントを組み合わせたときに、きちんと動作するというテストが必要になってくる。これらは、それぞれのテスト観点を持つ。

テストは成果物が期待通りであるかを検証する作業だ。システムは複数の部品の組み合わせから構成されているので、それぞれの部品にどのように動作すべきかという期待があるし、それを組み合わせたときにどのように動作すべきかという期待もある。これらの期待は、システムが総体としてどのようにふるまうべきかという期待とは違った水準にある。

だから、テストをするときには、今のテストがどの水準なのかを見失わないようにしよう。これが、テストでは何をテストすべきかという話だ。