ソフトウェア製品の不十分なテストの重要な理由は、ほとんどの専門家がこの用語の誤った定義によって導かれていることです。 彼らは言うことができます：
-テストとは、プログラムにエラーがないことを示すプロセスです。
-テストの目的は、プログラムが正しい方法で期待されるアクションを実行することを示すことです。
-テストとは、プログラムが意図したとおりに動作するという自信を生み出すことを目的としたプロセスです。
これらの定義は正しくありません。
演ductive的推論は次のとおりです。
テストに合わせて、製品に価値（価値）を追加します-
製品の品質と信頼性を高めることにより、製品に価値を付加します-
製品の信頼性は、エラーを検索して削除することにより追加されます。
したがって、テストしないでください。 すべてが機能することを示すためにテストしないでください。 公理から始めます-プログラムにはエラーが含まれます（ちなみに、これはほとんどのプログラムに当てはまります）。そして、テストの最終日であるかのように、できるだけ多くのエラーを見つけるためにテストします。
そして、より良い定義があります：
テストとは、エラーを見つけることを強く意図してプログラムを操作するプロセスです。 そして、それはある種の微妙な意味論的問題のゲームのように聞こえるかもしれませんが、ここには本当に重要な要素があります。 テストプロセスの真の定義（彼らは言葉を言った？-およそ翻訳者）を理解することは、あなたの努力の成功に大きく影響します。
人間は特定の目標への方向付けが重要な生き物であり、それらの設定は心理的に非常に重要です。 製品にエラーがないことを示すことが目標である場合、無意識のうちにこの目標に向けて努力します。 ここから、私たちの行動は失敗の可能性を減らす行動になります。 一方、プログラムにエラーが含まれていることを実証することが目標であれば、テストは後者を見つけるのにより成功します。 このアプローチは、以前のものよりも製品に多くの価値を追加します。
このような定義には多くの側面が含まれます。 たとえば、テストの特定の破壊的でサディスティックな性質を意味します。 私たちの人生観と矛盾するもの：結局のところ、私たちのほとんどは破壊する以上のものを作りたいのです。 ほとんどの人はオブジェクトを作成する傾向がありますが、オブジェクトを破壊する傾向はありません。 この定義には、テスト設計用のインストールと、テストする必要があるユーザーとそうでないユーザー用のインストールも含まれます。
テストの定義を適切に把握する別の方法は、「成功」と「失敗」という単語の使用を分析することです。特に、テストケースの合格結果にそれらを適用します。 ほとんどのマネージャーは、エラーを「成功した」と識別しなかったテストを認識し、エラーを検出したテストは通常「失敗した」と呼ばれます。
繰り返しますが、これは変化です。 失敗とは、望ましくない、または期待はずれの何かを意味します。 私たちの見解によると、修正可能なバグを見つけるのに役立った場合、適切に実行された適切な設計のテストは成功します。 また、最終的に、検出可能なエラーがないと報告された場合、同じテストを成功と呼びます。 テストが失敗したと呼ばれる唯一のケースは、システムを適切に検査できない場合です。 そして、ほとんどの場合、エラーのないソフトウェアの概念は根本的に非現実的であるため、これはおそらく起こることです。
失敗した新しいエラーを検出したテストとは何ですか？ 結局のところ、彼は製品価値への投資を提供しました。 ただし、エラーが検出されずに正しい結果でプログラムを実行するテストは、失敗と呼ばれる場合があります。
一般的なmal怠感のために医者を訪問することの類推を考慮してください。 医師が問題を検出しない臨床検査を実施し始めても、成功とはみなされません。 患者の財布が空であり、彼はまだ病気であるため、成功しません。 医師の資格について質問があります。 逆に、潰瘍を診断し、医師が治療を開始できれば、テストは成功です。 医療専門家では、これらの言葉は正しい方法で使用されているようです。 アナロジーは、ソフトウェア製品を病気の患者であるかのように認識する必要があるということです。
「プログラムにエラーがないことを実証するプロセス」としてのテストの定義に関する別の問題は、この目標がほとんどすべての人、単純なプログラムでさえ達成できないことです。
繰り返しますが、心理学の研究の結果は、問題の解決策へのインスタレーションに不適切または不可能の前提条件が含まれている場合、その人は効果がないと言います。 たとえば、難しいパズルを15分で解決するタスクがある場合、10分間での成功は小さくなります。ほとんどの人と同じようであれば、タスクを完了することは不可能であるとすぐに結論付けるからです。 4時間以内に解決策が必要になった場合、最初の10分間でより多くの成功が期待できます。 テストプロセスを既存のエラーを識別するプロセスと見なす場合、これは実行可能なタスクであり、この心理的な問題に対処することができます。
テストを「プログラムがすべきことを実行することを実証するプロセス」と定義することの問題は、この条件を満たすプログラムにまだエラーが含まれていることです。 言い換えれば、プログラムに本来あるべきことをしないエラーがあります-それは明らかです。 しかし、プログラムにはエラーが存在し、プログラムはすべきでないことを行います。 テストプロセスを、プログラムがすべきことを示すことを目的とするプロセスとしてではなく、エラーを見つけるためのプロセスとして見ることで、よりうまくいく可能性があります。
結論として、ソフトウェアテストは、存在するはずのエラーを見つける試みで構成される破壊的なプロセスと見なすことは正しいことです。 運は、アプリケーションをクラッシュさせることであり、「死のブルースクリーン」が最高のポイントです。 はい、インストールテストプロセス中に、プログラムが作成されたものを実行し、それ以外は何もしないというある程度の信頼を達成したいと考えています。 間違いは、この目標への優れたガイドになります。
誰かが自分のプログラムが完璧である、つまりエラーが含まれていないことを主張していると想像してください。 この声明の真実性を検証する最良の方法は、それを論することです。 言い換えれば、プログラムが特定のデータセットに対して正しく動作することに同意するのではなく、大きな欲求を持つ欠陥を見つけようとする必要があります。
テストの心理学（もちろん、網羅的ではありません）。 G.マイヤーズ著の本「The Art of Testing」からの個人翻訳
All Articles