使用面向業務的例子來設計產品是好的，但是假設例子是錯誤的怎么辦？誰都會犯錯誤。業務專家會忘記一些用戶真正需要的東西�；蛘邩I務專家錯誤地表達了需求，而程序員卻非常忠誠地實現了錯誤的東西。
那些錯誤，如果記起來了或注意到了，則可能會當作bug，也可能被認為是需要的功能特性。但兩者的界限很模糊。我會簡單地把它們叫做“問題”。
問題是如何引起項目組的注意的呢？
很多敏捷項目組會在一個迭代結束時向業務專家和感興趣的外部人員演示軟件系統。這時候會是激怒某個人的時候，“噢…我是那樣說過，但是我不是這個意思”。
敏捷項目喜歡頻繁地發布軟件給它的用戶（可能比用戶希望更新的頻率還要頻繁）。當用戶試用產品的時候，他們會指出存在的問題。
這些反饋循環很緊湊，比傳統的項目要緊密，因為敏捷項目喜歡短的迭代。但是它們不是最理想的。業務專家可能由于過于靠近項目而不能以新的、沒有偏見的眼光去發現問題。用戶通常不報告他們在軟件使用中發現的問題。當他們反饋問題時，報告得又不夠專業以致沒辦法執行。而反饋的周期不能像敏捷項目希望的那樣的頻繁�？赡軆H僅是針對一行代碼的改變的反饋，但是需要等上3個月才能從用戶那收集到。
因此，我們需要額外的產品批判形式 – 能注意到用戶會怎樣，而且能及時注意到。
產品批判的方式擁有前期創建的例子所不具備的資源：一個新的迭代版本的真正工作的軟件。當你描述某些目前不存在的東西的時候，你是在腦海里操作一個抽象的東西，一個你想象中的物品。當你親手操作一個產品的時候會激發不同的理解和判斷。你可能注意到，當試駕一輛汽車的時候，你不會專注于它的規格說明。操縱是與思考不一樣的。
因此，面向業務的產品批判應該專注于操作方面，嘗試逼近真正的不同用戶的體驗。就像James Bach，Cem Kaner，Elisabeth Hendrickson他們所說的探索性測試（Exploratory）的形式。
進一步的，我發現我們在嘗試至少5種類型的探索性測試：
1、 一個探索性測試員
2、 結對探索性測試員。James Bach 和Cem Kaner可能在這方面有最多的經驗。
3、 探索性測試員與一個程序員結對。Jonathan Kohl會在2004年1月的STQE雜志（http://www.stqemagazine.com/）有一篇這樣的文章。我在這方面沒有什么經驗，程序員也喜歡這樣的方式。值得注意的是，當我在RoleModel Software進行這種方式的時候，它導致了一個有趣的并且有用的關于基礎程序的討論。那樣的話，它成了一種類似回顧的方式，這進一步讓我相信它是迭代結束時很好的一種活動。
4、 讓探索性測試員與項目中的業務專家結對
5、 讓探索性測試員與感興趣的非參與者（用SCRUM的術語來說就是“chickens，小雞”），例如經理主管、新用戶等等。
對于每一種，我們應該探索關于什么時候測試員應該是項目組外的人的問題。這些外部的測試人員不會存在偏見和先入為主，但是存在缺點就是：他們需要花更多的時間來學習一些基本的東西。那也會使發現的問題存在一些偏離。
當我一年前開始在敏捷項目談論探索性測試的時候，我想它會在發現bug的同時對提出一些大膽的關于產品的新構思有啟迪作用。一個過程能發現兩類問題。有一段時間，我把它叫做“探索性學習”來強調它的擴展的角色。
后來我推斷這兩個目標不能很好地走在一起。因為找bug實在是太誘人了 – 對于功能特性的思考會在探索性測試的過程中迷失。有些時候能同時出現，但是不足夠。所以我想可能需要一個單獨的功能特性的腦力風暴活動。關于這一點，現在我還沒有什么特別好的主意�！靶枰M一步的研究”。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/