Kevin Fjelsted是一個盲人，他曾寫了一篇文章《A Brief History of the Accessibility of Computers by Blind People》，收錄在《Amplifying Your Effectiveness》一書中。文中從一個盲人的視角描述了幾十年來計算機的演進和變化。
我對Kevin所描述的一個小細節很感興趣：由于看不見，Kevin經常聽別人為他描述一些圖畫或者畫面。他發現，絕大部分人描述一幅畫的時候，實際上是在描述一些畫的特征，比如“畫里有三個人”、“這是一副關于房子的畫”。人們很少會描述畫的細節部分，這就為聽者留下了廣泛的思考和遐想空間。
當你用文字表述一件事情或一個事務的時候，不論你用多少文字、多么精雕細琢，當讓接收者親自去體驗這件事情的時候，比如親自用眼睛看這幅畫、或者親自動手去實驗一下，接收者總是會有新的感受、會發現一些文字之外的東西。這就是一副圖畫可能勝過萬語千言的道理了。
對照我們的測試，寫作測試用例的時候，不就是試圖用文字向測試執行人員傳達測試設計人員的想法嗎？從傳遞者的角度，也許你期望不同的執行人員拿到這個用例，其執行結果都是一樣的，希望測試效果受測試執行人員經驗的影響降到最低，因此你試圖準確而詳細地描述每一個步驟。然而你的測試用例是不可能寫得事無巨細的，因為不會有那么多的時間允許你這么做（假如你真的有這么多的時間，我倒建議你多做做探索性測試、多想想更有價值的測試內容）；另外一方面，即使真的給你這么多時間寫詳盡的測試用例，你仍然無法保證囊括每一個與之相關的細節。從接收者的角度，優秀的測試執行人員閱讀測試用例，就要像欣賞一幅畫一 樣，不僅僅靠聽－－這樣只能接到別人描述的表面特征，更重要的是靠看－－用你的眼睛去觀察，去想一想設計人員是怎么想的？設計這個用例的目的是什么？為什么要這樣設計用例？我怎樣測試才能保證最優的測試效果？和用例相關的部分哪些也值得我關注？哪些是我所知道的重要信息但用例卻沒有提到？我應該以怎樣的順序執行這些用例為佳？我以大概怎樣的進度執行這些用例比較合適？最重要的是靠動手－－用你的心去思考，當你拿到一份待執行的用例，如果上述問題，你通過審視用例，就基本了然于胸，那很好。如果不是這樣，比如你對被測特性還不大了解，也沒有關系，你可以在執行用例的過程中進一步思考這些問題，通過動手操作，你得到了被測對象的一些最真實的反饋，你對測試用例有了更深刻的認識，你也在隨時調整著自己的測試策略。
所以，傳統的腳本化測試（Scripted Testing）方法，即先花一段時間設計測試用例、再依據用例去執行的測試方法，不僅僅對測試設計人員有很高的要求（這里體現了大量的創造性的勞動），同時對測試執行人員也提出了相當高的要求：你得通過測試用例盡可能準確猜測出測試設計人員的心思，還得高于測試設計人員，找到測試用例文字以外的被忽略的但同時也是很重要的信息 －－除非你不想得到更好的測試效果。所以測試執行也是體現了大量的創造性思維的勞動。記得昨日在某一ISTQB-FL課程研討會上，某位講師講到了一頁膠片，膠片上赫然把測試執行等之后的環節歸為“機械式的活動”，而把之前的一系列測試設計活動歸為“創造性活動”，如果你的測試執行都是工具在自動化的做，也許這樣分類是說得通的吧。
很多組織都過分地看重測試用例，認為測試用例是測試人員最核心的資產，讓最優秀的人專職設計測試用例（他們從不或很少做測試執行了），花大量的時間去創建并維護這些用例，這些前端的活動投入非常大。而在最后一段路程，投入反而不那么大了：請一些缺乏經驗的測試人員或者干脆雇傭一些對特性不熟的外包人員，依據用例做測試執行即可。當版本發布，用戶反饋一些問題后，開始分析這些問題為什么會漏測，準確地說，應該是分析為什么會漏測試設計，因為鮮有人關注測試執行環節能力的提升。人們開始在測試設計階段運用更多、更復雜的測試設計方法，開始添加更冗長的測試設計流程，開始采用更為詳細要求的測試設計模板。。。
我時常聽到來自測試設計人員的求助，希望我告訴他們“如何才能提升測試用例的有效性？”“如何確保我設計的用例漏測率最低？” 在他們心中，很有責任感地認為：測試漏測，首先是我沒有設計好的緣故。我常常會告訴這些測試設計人員：單單依靠測試用例沒有必要也不可能發現大部分的bug，很多bug要依賴執行人員在測試執行階段發現，這是正常的測試現象－－你不可能要求盲人通過聽得來的對一副畫的理解和一個正常人通過看對一副畫的理解一致；我不建議測試設計人員長期不做測試執行，不建議測試設計和測試執行的分離，如果你的組織還沒有辦法做到這一點，請你－－測試設計人員－－一定要時常和測試執行人員溝通，向他請教對你的用例的看法，實時收到反饋信息，調整你的設計；過分重視測試設計而忽視測試執行，就如同“行百里者半九十”一樣，最終的測試效果很可能會輸在“測試的最后一公里”上。
探索性測試也許就是看中了人在測試中發揮的作用要大于文檔在測試中發揮的作用這一點吧。