模板
教程
環境
性能
功能
管理
探索性測試不是終結性測試
探索性測試不是終結性測試。探索性測試能夠(而且的確可以)發生在開發或測試的任何階段。
事實上，TDD(測試驅動開發)是探索性開發的一種形式。TDD是循環進行的，在這個過程中，程序員建立了一個檢查，繼而開發代碼，以使這個檢查(以及之前的所有檢查)通過，然后修復她發現的一些問題，接著會再次循環去實現一些新的特性，并開展新的檢查。從每個循環中獲得的信息反饋到下個循環;該活動由當時參與的而不是提前設計的人來指導和構建的。檢查本身是定制的，而產生和分析結果所需的活動卻不是定制的。和代碼開發過程中所進行的探索性的、迭代的、復雜的認知活動相比，這些定制的、線性的檢查本身就不那么重要了。
需求評審也是一項探索性的活動。審查的要求(或規格，或用戶或實例)，無論它是一個長的或短的周期，往往發生在開發周期的早期。雖然檢查列表可能會指導評審的開展，但是做決定的卻是那些參與活動并經歷了設計，調查，發現問題及學習，這個整個回環過程的人。每個循環的結果往往會緊接著反饋到下一個活動。
代碼審查也可以通過照本定制的方式或探索的方式進行。當人們分析代碼的時候，是循環發生、非照本宣科的、自我導向的活動;它是探索性的。我們稱之為審查，但它收集信息的目的是告知一個決定;因此這就是測試。有一種圍繞著定制程序應用的代碼審查方法，它通過一個人們一般稱之為“靜態測試工具”的工具。當一臺機器解析代碼并產生一個報告，根據定義，它是一種形式的檢查，而且它是定制的。然而，高效的使用這些工具需要大量的探索活動。分析和解釋報告，以及對它做出反應是多形態的，因此，人的這種非照本宣科的、開放式結尾的、迭代的活動是探索性的。
如果你想這樣做或促進這個新產品或功能的發展，了解一個新產品或新功能亦是一項探索性的活動。有些人認為，測試腳本提供了一種訓練測試人員的有效的手段。對學習的研究表明，當他們的學習是基于互動和反饋的時候他們往往會學得更快更深入;這可能是因為他們是被引導著去學習而不是受控制去學習。如果你真的想了解一個產品，那就嘗試創建一個思維導圖，去證明這個程序行為的某一方面，或者創建出人們在使用或誤用這個產品時可能會產生的情況。所有這些活動都促進了你對該產品的了解，所以他們都是探索性活動。在這個過程中，有大量你可以使用、應用及發現的信息，它遠遠超過了一個腳本所能告訴你的。試想想，那這種活動的的腳本又從何而來呢?
開發測試程序---甚至是開發一個測試腳本，無論是為一臺機器還是為一個人的，或開發熟練的測試員稱之為示范的那種“測試”，這是一個探索性的活動。沒有任何一個腳本會詳述如何編寫一個為某一目的而開發的新腳本。你是不是聽說了一項新功能并思考著你可能會如何測試它?實際上從這時候你已經開始測試了;你正在做測試設計，同時你也很可能在學習。在一定程度上，你使用該產品或與它進行交互，把你的觀點反饋給其他人，或批判性的思考你的設計，這個時候你在測試，而且你是用一種隨機方式的方式去進行。有些人可能會認為，某些工具創建的腳本可以執行自動檢查。然而，這些檢查的適當性審查，解釋結果，并進行故障排除意外的結果所有這些都是探索性活動。
假設一個程序員，在她快要完成一個新模塊時候，想要獲得關于她做的這個新模塊到目前為止的一些反饋。她遞給你一些代碼來看。你可以直接通過她提供的測試工具與代碼交互，或通過比如Ruby這樣的解釋器，或者你也可以寫一些腳本代碼來運行她這個模塊中的一些功能。無論是通過這些方式的任何一個，你都會發現它的一些問題。為了調查你所發現的問題，你必須探究。您必須探究你所識別的問題由你自己與這個程序的互動引出的，還是由機械執行的腳本所引出的。你控制著整個活動;圍繞著這一問題的每一個新的測試會反饋到你所選擇的下一個活動，以及反饋到你要講的關于這個產品的具體詳情。
我上面描述的所有較大的活動都是探索性的，他們發生在你得到一個完整的有關產品的詳情或功能之前，或一個程序完成之前。探索性測試不是在你執行完其他測試技術之后你又要展開的一個測試的一個階段。探索性測試不是另一個“其他”測試技術，因為它根本不是一個技術。探索性測試不是你做的一件事情，而是你工作(思考和行為)一種方法，它的特點是人(或事物)可控制的，而且在一定程度上你的活動是一個循環的一部分，而不是直線進行的。任何測試技術都可以用固定的方法或探索性方法去執行。對于那些宣揚通過可接受性測試之后再做探索性測試的人來說，我給他們的建議就是：要仔細審視，并時刻注意你是否做到了探索性測試。
