ソフトウェアテスティングとは、ステークホルダにテスト中の製品やサービスの品質に関する情報を提供するために実施する、経験的調査のことだ。しかし、この定義では、テスティングとチェッキングの微妙な違いを生む「知恵」については語られていない。Michael Bolton氏は、これら2つの違いと、その違いがある理由について語った。
Michael氏によると、
チェッキング（チェックすること）とは、すでにある信念を確認するという動機から実施するものです。チェッキングは確認、検証、妥当性確認というプロセスになります。すでにそれが正しいと信じているときに、チェッキングによってその信念を確認します。コードを変更してもこれまで同じようにすべて動作することを確かめたいときに、私たちはチェックします。
テスティング（テストすること）とは、新しい情報を見つけるという動機から実施するものです。テスティングは探索、発見、究明、学習というプロセスになります。評価するつもりで、あるいは想定外の問題を見つけるつもりで、製品を設定して、動かし、観察するときに、私たちはテストします。
Michael氏は、チェックは成功か失敗かという2値の反応になるので、機械的に決定可能だと言う。これに対して、テストには知恵が必要になる。テストとは、システムについて学び、「ここに問題はありますか？」という質問に答えるという探索的な方法だ。このことがテスターとチェッカーの違いを生むことにもなる。
始めるにあたって、明確な、完成した、最新の、曖昧さのない仕様書を必要とする人はチェッカーであってテスターではありません。始めるにあたって、テストスクリプトを必要とする人はチェッカーであってテスターではありません。プログラムをリファレンスと比較する以外に何もしない人はチェッカーであってテスターではありません。
これに対してGeorge Dinwiddie氏は、チェッキングにもテスティングにも知恵が必要だと言う。彼は次のように付け加えた。Michael氏は「実行して観察する」ことはチェックだと言っているが、それはスクリプトに沿ったテスティングの一部にすぎません。テストに失敗したときに実際に何が起こっているのか理解するには、テスターの持つ知恵が必要になります。もっと情報を得るためにログファイルをチェックしたり、他のシステムが正しく動いているか確認するために誰か呼んだり、他にもいろいろな探索をすることになるでしょう。これは、アクティビティ間の遅延が長いことを除いて、探索的テストと何ら違いはありません。
Michael氏は、チェック自体は比較的やさしいことだと述べつつ、ある程度これに同意した。しかし、チェックの前後には、いろいろと知恵が必要になる。それがチェックとチェッキング（チェックすること）との違いになる。
ですから、チェック（"50,000もの自動テストがある"）とチェッキングのどちらを重視するのかという、パワープレイは終わりにしましょう。単なるチェックは重要ではありません。しかし、チェッキング、すなわちチェックを作って、管理し、分析するのに必要なアクティビティは重要です。アイゼンハワーの言葉を引用すると、大切なのはチェックではなく、チェックすることだ。しかし、それがすべてではない。そして、テスティングもまたすべてではない。ということなのです。
Johanna Rothman氏は賢くテスティングするのに必要なスキルについて、同じような意見を述べている。
アジャイルプロジェクトには、テスターとして、要件、設計、コードを理解できるスキルのある真のジェネラリストが必要になります。こうしたスキルがないと、開発中の製品について十分批判的に考えることができず、バリエーションに富んだテストを十分作ることはできないでしょう。もしテスターが要件、設計、コードを理解していれば、その理解を巧妙なテストへと変えることができます。こうしたテストには探索的なものもあるでしょう。探索的テストには繰り返し使えるよう自動化する必要があるものもあるでしょう。私はアジャイルプロジェクトで偉大なテスターたちに会ったことがあります。彼らは探索のための自動テストをすばやく作っていました。
しかし、Cem Kaner氏は、アジャイルテスターはテストするジェネラリストであるという考え方に異を唱えている。彼は、探索的テスティングにはテスティングと探索の両方が必要になるので、有効な探索をするためにはある種のスキルを活用する必要があると言う。彼によると、
プログラマはプロジェクトのリスクをよく理解しています。おそらくプログラマでない人よりも、リスクを探索するのによく考えられたテストを作る能力があるでしょう。環境におけるソフトウェアのインテグレーションに重点を置く人もいます。また、私たちはパフォーマンス評価やセキュリティ評価のスペシャリストも知っています。プログラマもいれば、そうでない人もいます。彼らはみな、システムレベルのソフトウェア検証者と一緒にスクリプトに沿った方法で、あるいは探索的な方法でテストすることができます。
George氏によると、どちらのモデルにも相対的な強みと弱みがある。チェックもテストも、Cem Kaner氏の定義によればテスティングだと見なされる。重要なのはスクリプト自体にあるわけではなく、どうやるかというプロセスにある。
どちらも（チェックもテストも）、新しい情報を見つけるという点で、また知恵を必要とする点で、テスティングです。もしこうしたことを考えていないなら、やり方を間違えています。
最近、InfoQはReasons to Love Agile Testingという記事も公開している。