軟件測試是一種以觀察和實驗為依據的調查過程，該過程以測試為手段，為干系人提供產品或服務的質量信息。然而，這個定義并沒有提到人類智慧的應用，而人類的智慧使得測試和檢查之間產生微妙區別。Michael Bolton談了兩者的區別及其產生原因。

　　Michael認為：

　　檢查是指為了證實已經存在的理念而去做的事情。檢查是一個證實、驗證和確認的過程。當我們已經相信某些東西是正確的，我們會通過檢查來核實這一點。當我們修改了代碼又想確保一切功能照常運行，我們需要檢查。

　　測試是指我們為了發現新信息而去做的事情。測試是一個探索、發現、調查和學習的過程。當我們想通過配置、操作或者觀察來評估一個產品時，或者當我們試圖去識別一個沒有預計到的問題時，我們是在測試。

　　Michael認為：檢查要依賴機器完成，因為它們可以給出非此即彼的兩個答案：通過或者失敗。測試卻需要智慧。測試是了解系統和解答問題的探索之旅：“這里有問題嗎？”這也引出了測試人員和檢查人員的區別。

　　需要有新的、清晰、完整而且沒有歧義的規范說明才能工作的人是檢查人員，不是測試人員。同樣，需要有測試腳本才能工作的只是檢查人員，而不是測試人員。而僅僅根據參考文檔來比較當前程序的人也是檢查人員，不是測試人員。

　　George Dinwiddie認為檢查和測試都是需要智慧的。他覺得雖然Michael認為“運行和觀察結果”是檢查，但是這僅僅是腳本測試的一部分。一旦測試失敗了，需要測試人員的智慧來弄明白到底發生了什么。這可能包括通過查看日志文檔來獲得信息，讓其他人去看看別的系統是不是工作正常，以及很多其他探究性工作。所以這跟探索性測試沒有區別，除了發生的時間有點延時而已。

　　Michael一定程度上也同意這個觀點，他認為僅僅檢查點本身是很微不足道的。往往檢查之前或者檢查之后，人類的智慧起到了很大作用。這也是一個檢查點和檢查的區別。

　　所以核心問題在于我們認為哪一個更有價值，是檢查點（我們有50000個自動化測試）還是檢查。只有檢查點是不重要的，但是檢查??涉及到構建、維護和分析每個檢查點??卻是很重要的。參照艾森豪威爾那句話（譯者注：艾森豪威爾，二戰歐洲盟軍總司令，美國34任總統。他在諾曼底登陸以后有句名言：Plan is nothing， but planning is everything），檢查而言，檢查點什么都不是，與之相比，檢查這一系列過程才是王道 （with respect to checking， the checks are nothing； the checking is everything）。然而檢查也不是的，測試也是如此。

　　Johanna Rothman 也發表了類似的看法，她認為測試需要技能和智慧并存。

　　敏捷項目需要真正的多面手來擔當測試人員：擁有能讀懂需求、設計和代碼的技能的人。沒有這些技能，他們不能足夠深入地去思考開發中的產品，他們也有可能無法識別出足夠多的各類測試用例。如果他們能夠理解需求、設計和代碼，他們可以根據他們的理解設計出巧妙的測試用例。其中的一些測試是探索性的，甚至有些探索性的測試需要以自動化方式實現，以便以后重復運行。我曾經在敏捷項目中見過一些出色的測試人員，他們能夠很快地編寫出自動測試腳本來做一些探索。

　　Cem Kaner則不同意敏捷測試人員需要是多面手一說。他認為既然探索性測試既需要測試又需要探索，那么為了能探索得當，還是很有必要運用些特定技能的。他說道：

　　程序員理解項目中很多的風險。相比非程序員出身的人，他們可能能更好地寫出深入的測試來探測那些風險。而其他人可以更加專注于當前環境下的軟件集成。相類似地，我們熟知的一些系統性能或者安全評估方面的專家，也能在他們的領域更好地表現。他們中的一些人是程序員，一些則不是。所有這些人和系統級別的軟件測試人員一起，才能做好自動腳本測試或者探索性測試。

　　George認為這兩種模型都有各自的利弊。檢查和測試都能滿足Cem Kaner關于測試的定義。關鍵不在于是不是測試腳本化，而是你做事的流程和方式。

　　兩個都是測試，都在尋找新信息，都需要智慧。如果你不這么想，那么你的測試方式錯了。