私は25年以上前にテスト用コンピューターソフトウェアのほとんどを書きました。それ以来、時代遅れ、または単に間違っていると考える本のいくつかの部分を指摘しました。http://www.kaner.com/pdfs/TheOngoingRevolution.pdfをご覧ください
ブラックボックスソフトウェアテストコース（ビデオおよびスライドは無料で利用可能）、www.testingeducation.org / BBSTのサイトで詳細を見ることができます（現在のビューですが、TCSへの明示的なポインターはありません）。
当時のテスト文化は主に確認的でした。
最新のテストでは、単体テストへのアプローチはほとんど確認的です。ソフトウェアが意図したとおりに動作し続けることを単純に検証する自動テストの大規模なコレクションを作成します。テストは変更検出器として機能します-コードの他の部分に何かがあり、この部分に問題が発生した場合、または現実世界では不可能だったデータ値がアプリケーションに到達した場合、変更検出器が起動して、プログラマーがメンテナンスの問題を解決します。
確認の考え方はユニットテストに適していると思いますが、システムテストのすべてが確認的である世界を想像してください（区別する人は、システムに関する私のコメントに含まれている「システム統合テスト」と「受け入れテスト」を解釈してくださいテスト。）テストのポイントは、プログラムが仕様を満たしていることを確認することであり、支配的なアプローチは、プログラムの動作に仕様の一部をマッピングする無数（または少なくとも数百）のシステムレベルの回帰テストを構築することでした。（仕様の動作確認は有用だと思いますが、それはより大きな目的の小さな部分だと思います。）
この方法で動作するテストグループはまだありますが、もはや支配的なビューではありません。当時はそうでした。この考え方で一貫して訓練されている人々を強調するために、私は強調して書き、鋭い対比を描きました。今日、いくつかのシャープなコントラスト（ここで引用したものを含む）は時代遅れです。彼らは間違った見方に対する攻撃と誤解されます。
ご覧のとおり、ソフトウェアテストは、ソフトウェア製品またはサービスに関する品質関連情報を学習するための経験的なプロセスです。
テストは、有用な情報を明らかにするように設計する必要があります。
ところで、ところで、「情報」を明らかにする方法としてテストについて話す人はいませんでした。当時、テストは（...の一部のバージョン）バグを見つけるため、または（...の一部のバージョン）仕様に対するプログラムの検証（チェック）のいずれかでした。テストは有用な情報を明らかにするためのものであるという主張は、今世紀までテスト用語に取り入れられたとは思いません。
情報価値の観点から評価テストを想像してください。ソフトウェアについて私たちが知らないことを教えてくれる可能性が非常に高いテストは、非常に高い情報価値を持ちます。私たちがすでに期待しているものを確認する可能性が非常に高く、以前に何度も実証されたテストは、情報価値が低いでしょう。テストに優先順位を付ける1つの方法は、低い情報値のテストの前に高い情報値のテストを実行することです。
ソフトウェアのテストについて無知なプログラマー、プロジェクトマネージャー、またはプロセスマネージャーの注意を引くために、この優先順位付けを単純化しすぎた場合、「バグを明らかにするように設計されていないテストは時間の無駄です」 」これは完全な翻訳ではありませんが、微妙な点や資格を理解できない、または理解できない読者にとっては、これはすぐに理解できるものです。
当時、ここでもう一度見ますが、テストを理解していない人の中には、主要な機能の主要な使用のテストと比較して、コーナーケースを見つけるように設計されたテストは時間の無駄であると答えます。彼らは2つのことを理解していません。まず、タイムテスターが境界値をチェックする時間を見つけることによって、主要な機能の主要な使用法が既に何度か実行されています。（はい、例外があり、ほとんどのテストグループはそれらの例外に注意を払います。）次に、極端な値でテストする理由は、プログラムが極端な値で失敗する可能性が高いことです。極端に失敗しない場合は、別のテストを行います。これは効率的なルールです。一方、極端な値で失敗した場合、テスターが停止してバグを報告したり、テスターがさらにトラブルシューティングを行ったり、プログラムがより正常な値で同じように失敗するかどうかを確認します。誰がそのトラブルシューティングを行うか（テスターまたはプログラマー）は、企業文化の問題です。一部の企業はこれにテスターの時間を割り当て、一部の企業はプログラマーに予算を割り当て、一部の企業は、トラブルシューティングが適切ではないように、一般化可能であるかどうかにかかわらず、プログラマがコーナーケースバグを修正することを期待しています。極端な値をテストすることでテスターが（効率を最大化するのではなく）時間を浪費しているという一般的な誤解は、「バグを明らかにするように設計されていないテストは時間の無駄です」がテスターにとって適切なメッセージである別の理由です。これは、一部のプログラマーが（実際に）プログラムに挑戦する可能性のあるテストを実行しないように奨励することへの対抗策です。メッセージは単純化されていますが、議論全体が単純化されています。
ところで、「情報価値」だけが優先順位付けシステムになることはできません。単体テストスイートを設計するとき、それは私のルールではありません。ビルド検証テスト（別名サニティチェック）を設計するとき、それは私のルールではありません。どちらの場合も、個々のテストの力よりも、カバレッジの種類に興味があります。個々のテストの力が私の設計とは無関係である他のケース（たとえば、セットアップ、実行、および監視が安価な大量の自動テスト）があります。追加の例を考えることができると確信しています。
しかし、一般的なルールとして、1つだけのルール（たとえば、複数の文を処理しようとすると頭が爆発するエグゼクティブと話す）しか言えない場合、情報価値の低いテストは通常時間の無駄です。