早在1983年，Cem Kaner提出了探索式測試的概念。
探索式測試是一種軟件測試風格，它強調獨立測試人員的個人自由和職責，爲了持續優化其工作的價值，將測試學習、測試設計、測試執行和測試結果分析作爲相互支持的活動，在整個項目實現過程中並行地執行。
很多測試人員把探索式測試理解爲“發散找缺陷”，這是不恰當的理解。探索式測試是一種軟件測試風格，或者說是一種“測試的價值觀”，希望可以邊學邊測，重視反饋，持續優化調整，其和敏捷的價值觀很貼合。
和探索式測試對應的是腳本式測試（Script Testing，ST），腳本式測試要求測試人員編寫測試腳本去記錄所有的測試用例（包括測試操作和預期），然後通過腳本來實施測試。腳本式測試有利於測試執行和測試設計的分離，這可以讓測試設計、測試執行、自動化分離等適合流水線作業。腳本式測試也有利於測試的管理、度量和評估。但是過於詳細的測試設計、測試用例本身也是一種巨大的開銷，這會讓測試變得過重。另外，腳本式測試要求測試人員嚴格按照測試用例來執行，這會使測試過程變得過於機械。
探索式測試和腳本式測試的差別（James Bach版本）
在腳本式測試中，測試人員先設計測試用例，再在一段時間後執行這些測試用例，或者測試用例被其他測試人員執行。而在探索式測試中，測試用例是在測試執行時被設計的，而且大部分測試用例不需要詳細的記錄。
探索式測試有可能帶來如下問題。
1）測試人員會有短期無法彌補的能力短板。
2）學習能力不足的測試人員不能快速抓到測試重點，上手慢。
3）探索失敗會給測試人員帶來挫敗感，會對項目交付造成影響。
4）更多的溝通，不一定是有效的溝通。
5）測試人員的獨立人格會使合作性變差。
6）經驗傳承會成爲一種瓶頸。
7）探索式測試快節奏、不斷學習和變化的特點會引發測試人員的疲憊感，這一點團隊人員不一定都可以接受。
這就需要測試人員能夠更有策略地開展探索式測試。例如以腳本式測試爲主，探索式測試作爲補充，或將探索式測試的思想運用到一些測試活動中。
摘取自劉琛梅老師的《測試架構師修煉之道：從測試工程師到測試架構師 第2版》