しばしば、ソフトウェア開発者は、ソフトウェア製品を創ってしまってから、頭をかきかき、「さて、これからどうやってこれをテストしようか」と言う。テスト計画を作ることは重要な仕事であって、製品の開発と並行して行う必要があるので、テスト計画の作成と初期の（すなわち、テスト以前の）開発作業は同期して行われる。
ソフトウェア・システム・テスティングでは、テスト計画者は要求仕様書が基準文書化され、要求仕様書作成者へのフィードバックがなされる前に、ソフトウェア要求仕様書をテスト可能性の観点からレビューすべきである。テスト項目の本格的な作成は、要求仕様書が基準文書となった直後に開始すべきである。統合テスティングでは、テスト計画者は、予備的な設計書をそれが基準文書化される前にレビューすべきである。彼らはまた、（１）「正しい」コンポーネントが（テスティングの観点から）正しい順序で開発されていることを確かめるための賢明な資源の割り当て、および（２）本質的にテストを容易にするための設計変更に関して、プロジェクト管理者と設計者にフィードバックすべきである。統合テストのテスト項目の本格的な作成は、予備的な設計文書が基準文書となった直後に開始すべきである。単体テストでは、単体テスト計画の作成は、詳細設計が完了した直後に開始できる。
（２０１の鉄則：原理１０８＜テスティングの原理＝テストを行う時期よりずっと前にテストを計画せよ＞）
多くの現場では、原理１０８にあるように、「さて、どうやってテストしようか」というのが実情かもしれません。残念ながら、今のところテストは省くことができません。それは、きちんと仕様を実現しているという保証がないからです。その確信があるのなら、品質保証の観点からのテストで足りるわけです。その確信がない以上、設計者によるテストはもちろん、仕様に沿って非設計者による「評価」をも受けなければなりません。
多くの現場では、「テスト計画」というものを書いたことがないかも知れません。名前ぐらいは聞いているでしょうが、一体、どのような事を書けばいいのか、良く分からないのが現実ではないでしょうか。テスト計画が書けるためには、スケジュールを含めて、プロジェクトの計画が必要になります。その枠の中で、今回のテストはどのように対応するか、体制は？ テスト仕様は？ テストの準備や手順は？ 合否の判定は？ 結果データの収集やバグ報告のルートは？ と言ったことを決めていかなければなりません。
そしてもう一つテスト仕様を用意する上で重要なのは「要求仕様書」です。今回のシステムは、どのようなことを実現しようとしているのかを表した文書は、これしかありません。この要求仕様書が望ましい期間内に８０％以上仕上がってくることが、テスト仕様が書けることの条件にもなります。
要求仕様は「検証可能」でなければなりません。つまり、エラーのケースも含めて、そこに書かれていることが、実際に実現していることを客観的に検証できなければならないわけです。事前にそのような要求仕様書が書けていなければ、テスト仕様も作れないでしょうし、その結果、実際にそれが実現しているのかどうかはテスト者の主観で判断することになります。
したがって、要求仕様書が書き上がったら、テストの担当者（責任者）は、要求仕様がテスト可能な表現で書かれていることをチェックしなければなりません。この場合、その仕様の合理性などのチェックは他のレビューアの手に委ねることにして、とにかく、そこに表現されている状態でテストが出来るのかどうかをチェックします。
一方、「テストで品質の向上を図る」という考え方が根強く残っています。でもテストは、プログラムが（要求）仕様を実現しているかどうかを確認する行為に過ぎません。つまり、テストは仕様の確認行為であって、ここには品質を織り込む機会はないのです。品質は、あくまでも仕様策定や、その仕様を実現すべく適切なデータ構造などの設計や、実装の作業の中で「織り込まれる」ものです。実際に、データ構造の選択を間違えると品質を満たさない事が起きます。その状態を発見することがテストであって、その時点では、品質は既に織り込まれているのです。
一般には、テストには、設計者によるテストと評価者によるテストがあります。この２０１の鉄則の原理１０９には、「自分のソフトウェアを自分でテストするな」とうのがありますが、結合テストに入る前の段階では、まだまだ設計者によるテストは避けられないのが現実です。そこに居る人達が、クリーンルーム手法に取り組める程のレベルであれば別ですが、そうでない状況では、設計者テストは避けて通れません。
そのような中で、独立したテスト者がやることは、結合テストに耐えうる状態かどうかの判断と、以降の結合テストや運用テストです。
一般に、テスト者は、与えられたプログラムを評価するだけの存在になってしまいがちです。要求仕様が早く出てこない組織では、期間が圧迫され、必然的に力仕事で評価するだけに終わってしまいます。この原理１０８には、テスト者の役割として、テスト計画を立案したり、要求仕様の検証可能性をチェックしたり、テストを容易にするための設計方法などのアイデアをフィードバックすることを勧めています。その他に、ＳＱＡの役割も担うべきです。
そのためには、“プロセス”の考えを身に付け、要求仕様や設計書を読めるようにしておくことです。多くの現場では、評価部門は上流部門の作業を補う役割を担っていますが、その際、問題なのは、評価に関する技術が「技術」として確立していないため、その組織の中でしか活動できないことです。「評価」は、本来は独立した技術であり、業務知識さえ入れ替えれば、既存の組織を越えて多くの場面で活躍できるはずです。