テスト技法に関する古典。テストにかかわるすべての人に薦めたい。理論面に偏ることなく、心理学的、経済学的な考察も貴重である。数学の証明のように、論理を追うのに少々疲れるところもあるが、結論だけにでも目を通す価値は十分ある。

参考になった部分を挙げると、

・テストとはプログラムが正しく動くことを示すことではなく、エラーを見つけるつもりでプログラムを実行する過程である。
・テストは破壊的な過程であり、建設的な考えを持った一般的な人間には難しい作業である。
・テストの原則
○結果が自分に都合のよいように見えると言う現象があるので、テスト結果をきちんと定義しておく。
○プログラマは自分の作ったプログラムをテストしてはならない。プログラミングは建設的な過程であり、一夜明けて破壊的なテストをすることは不可能である。
○テスト結果を完全に検査する
○テスト・ケースは、正しい予想できる入力条件だけでなく、誤った予想しない場合も考えて書く。
○プログラムが意図されたように動くかどうかと同時に、意図されなかった動きをするかどうかをしらべる。
○テスト・ケースも使い捨てにしてはならない。
○エラーは見つからないだろうという仮定のもとにテストの計画を立てない。
○プログラムのある部分でエラーが存在する確率は、その部分ですでに見つかったエラーの数に比例する。
・レビュー、ウォークスルーは、ターゲットを使わないテストである。
・テストケースの設計では、どの方法でも、それ単独では不十分であり、さらにほかの方法と組み合わせても完全とは保証されない。
・モジュールテストでは例えば論理網羅（ホワイトボックス・テスト）を基本として、ブラックボックス・テストの集合で補足し、次に限界条件をカバーするテストケースを追加する。
・モジュール同士の結合を、トップダウンで行う方法と、ボトムアップで行う方法のメリット、デメリットを検討し、ボトムアップが有利な点が多いと結論付けている。
・エラー位置発見の原則
○考えよ。
○いきづまったときは、明日までのばそう。
○いきづまったときは、その問題を他人に説明しよう。
○デバッグ道具は２番目の手段としてつかおう。
○ 実験を避けよう。実験は最後の手段である。

等である。