なぜCem Kanerは、バグを明らかにしないテストを時間の無駄だと考えているのですか？
肯定的なテストで機能を確認し、それが機能していることを証明するのはどうですか？それは時間の無駄だと言えるでしょうか？この見積もりの背後にあるのはどのようなコンセプトですか？
失敗したテスト、つまりエラーを検出しないテストは時間の無駄です。
私は25年以上前にテスト用コンピューターソフトウェアのほとんどを書きました。私はそれから、私が古くなった、または単に間違っていると考える本のいくつかの部分を指摘しました。参照 http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
ブラックボックスソフトウェアテストコース（ビデオとスライドは無料で利用可能）のサイトwww.testingeducation.org/BBSTで、より多く（現在のビューですが、TCSへの明示的なポインタはありません）を見ることができます。
当時のテスト文化は、主に確認的でした。
現代のテストでは、単体テストへのアプローチは主に確認的です。ソフトウェアが意図したとおりに機能し続けることを単に確認する自動テストの大規模なコレクションを作成します。テストは変更検出器として機能します。コードの他の部分でこの部分に問題が発生した場合、または現実には不可能であったデータ値がアプリケーションに到達した場合、変更検出器が起動し、プログラマがメンテナンスの問題に。
確認の考え方は単体テストに適していると思いますが、すべてのシステムテストが確認であった世界を想像してください（区別する人々のために、システムに関する私のコメントに含まれている「システム統合テスト」と「受け入れテスト」を解釈してくださいテストのポイントは、プログラムがその仕様を満たしていることを確認することであり、主要なアプローチは、仕様の一部をプログラムの動作にマッピングするジリオン（または少なくとも数百）のシステムレベルの回帰テストを構築することでした。 （仕様どおりの動作確認は役立つと思いますが、それはより大きな目的のごく一部です。）
このように動作するテストグループはまだありますが、もはや支配的な見方ではありません。当時はそうでした。私は強調して書いたり、鋭い対比を描いたりして、この考え方で一貫して訓練を受けている人々を強調しました。今日、鮮明なコントラストの一部（ここで引用したものを含む）は古くなっています。彼らは誤った見解に対する攻撃と誤解されます。
私が見ているように、ソフトウェアテストはソフトウェア製品またはサービスに関する品質関連情報を学習するための経験的なプロセスです。
テストは、有用な情報を明らかにするように設計する必要があります。
ちなみに、当時、「情報」を公開する方法としてのテストについては誰も話していませんでした。当時、テストは（一部のバージョンの...）バグを検出するため、または（一部のバージョンの...）プログラムを仕様に対して検証（チェック）するためのものでした。テストが有用な情報を明らかにするためのものであるという主張が今世紀までテスト語彙に取り入れられたとは思いません。
情報価値の観点から評価テストを想像してみてください。ソフトウェアについて私たちが知らない何かを私たちに教える可能性が非常に高いテストは、非常に高い情報価値を持っています。私たちがすでに期待していることを確認する可能性が非常に高く、以前に何度も実証されているテストは、情報価値が低くなります。テストに優先順位を付ける1つの方法は、低い情報値のテストの前に、高い情報値のテストを実行することです。
この優先順位付けを過度に単純化して、ソフトウェアテストについて無知なプログラマー、プロジェクトマネージャー、またはプロセスマネージャーの注意を引くなら、「A TEST THAT IS NOT DESIGNEDバグを明らかにするにはIS無駄な時間です。 "これは完璧な翻訳ではありませんが、微妙さや資格を理解できない、または理解できない読者にとっては、それはそれが達成するのと同じくらい近いものです。
当時、私はここでもう一度見ますが、テストを理解していない人の中には、主要な機能の主要な使用のテストと比較して、コーナーケースを見つけるために設計されたテストは時間の無駄だと答える人もいます。彼らは二つのことを理解していません。最初に、テスターが境界値をチェックする時間を見つけるまでに、主要な機能の主要な用途がすでに何度か実行されています。 （はい、例外があり、ほとんどのテストグループはそれらの例外に注意を払います。）次に、極端な値でテストする理由は、プログラムが極端な値で失敗する可能性が高いためです。それが極端に失敗しない場合は、何か他のものをテストします。これは効率的なルールです。一方、極端な値で失敗した場合は、テスターが停止してバグを報告するか、テスターがさらにトラブルシューティングを行い、プログラムがより正常な値で同じように失敗するかどうかを確認します。誰がそのトラブルシューティングを行うか（テスターまたはプログラマー）は、企業文化の問題です。テスターの時間を予算に組み入れる企業もあれば、プログラマーに予算を組み入れる企業もあり、一般化可能であるかどうかに関係なく、プログラマーがコーナーケースのバグを修正して、トラブルシューティングに関連しないと期待する企業もあります。よくある誤解-テスターが極端な値をテストすることによって（効率を最大化するのではなく）時間を浪費していることは、「バグを明らかにするように設計されていないテストは時間の浪費である」というのも、テスターにとって適切なメッセージです。これは、一部のプログラマーが（事実上）プログラムに挑戦する可能性のあるテストを実行しないように奨励することとは対照的です。メッセージは単純化しすぎていますが、全体の議論は単純化しすぎています。
ちなみに、「情報価値」だけが優先順位付けになるわけではありません。単体テストスイートを設計するとき、それは私のルールではありません。ビルド検証テスト（別名サニティチェック）を設計するときは、私のルールではありません。どちらの場合も、個々のテストの力よりもカバレッジのタイプに関心があります。他のケース（たとえば、セットアップ、実行、監視が安価な大量の自動テスト）で、個々のテストの能力が設計に無関係である場合もあります。追加の例を考えることができると思います。
ただし、原則として、1つのルールしか記述できない場合（たとえば、幹部が複数の文を処理しようとすると頭が爆発するような場合）、情報価値の低いテストは通常、時間の無駄になります。
Kaner氏によると、このアイデアは「テストケースがなくなる前に時間切れになるため、可能な限り効率的に時間を使用することが不可欠です」と述べています。
あなたが尋ねる引用の背後にある概念は、 Testing Computer Software の記事Cem Kaner、Jackによって提示され、詳細に説明されていますFalk、Hung Quoc Nguyen、「テストの目的と限界」の章：
なぜテストなのか？
すべてのバグを見つけることはできません。プログラムが正しいことを証明することはできませんし、そうしたくないのです。それは高価でイライラし、人気コンテストに勝つことはありません。では、なぜわざわざテストを行うのでしょうか。
プログラムのテストの目的IS ITで問題を見つけるには
問題を見つけることはあなたの仕事の中核です。できるだけ多くを検索する必要があります。問題が深刻であればあるほど、より良いものになります。
テストケースがなくなる前に時間がなくなるため、可能な限り効率的に時間を使用することが不可欠です。第7章、第8章、第12章、および第13章では、優先順位を詳細に検討しています。指針となる原則は簡単に言えます：
問題を明らかにするテストは成功です。 問題を明らかにしなかったテストは時間の無駄でした。
Myers（1979）による次の類推を考えてみてください。何かがおかしいとしましょう。あなたは医者に行きます。彼はテストを実行し、何が問題なのかを見つけ、修正措置を推奨することになっています。彼はテストごとにテストを実行します。すべての終わりに、彼は何も悪いことを見つけることができません。彼は素晴らしいテスターですか、それとも無能な診断医ですか？あなたが本当に病気なら、彼は無能であり、それらすべての高価なテストは時間、お金、そして努力の無駄でした。ソフトウェアでは、あなたは診断医です。プログラムは（確かに）病気の患者です...
上記のポイントは、テストを賢く優先する必要があるということです。テストには限られた時間の時間がかかることが予想され、指定された時間内にすべてをテストすることは不可能です。
テストの実行に1日（週、月）費やし、バグを発見せず、明らかにするテストを実行する時間がなかったため、いくつかのバグをすり抜けさせたとします。これが発生した場合、このミスを正当化するために、「他のテストの実行で忙しかったので、私のせいではない」とだけ言うことはできません。そうした場合でも、責任は負います。
バグを明らかにしないテストの実行に時間を浪費し、そのため、バグを見つけるテストを逃しました。
（もし疑問に思った場合、上記のようなミスはどのように試みても一般に避けられず、これらに対処する方法がありますが、それは別のトピックの詳細になります質問...そしておそらくSQA.SEにより適しています。）
さて、私はカナー氏を知りませんが、私見
潜在的エラーを検出しないテスト
時間の無駄です。これには、すでにいくつかのテストがあり（自動であるか、チェックリストにあるかは関係ありません）、本質的に同じケースを検証する新しいテストを追加する状況が含まれます。したがって、新しいテストでは、既存のテストよりも多くのエラーが検出されません。
このような状況は、たとえば、ランダムにリストを調べただけで発生する可能性があります-私は「脳みそに」と言うこともできます（Wordを許してください）-プログラムでテストケースを選択しました。入力データのクラス、またはすでに記述されているテストとの関連でコードカバレッジを増加させる場合。