后來我在最后期限之前做了一些探索性測試，意識到我在用戶界面的“不重要的”部分編碼工作做得不夠好，但是我感覺不情愿去攻擊這些GUI，因為我實在是不希望修改bug。
因此這是個真正的問題。我希望我們可以通過一些實踐來減少它。例如，就像結對編程的程序員傾向于保持誠實地重構，那么在探索性測試時保持誠實地攻擊代碼。在進度壓力下不愿意重構 – 導致的是設計的“債”的積累 – 不是一個可以永遠擺脫的問題，但是項目組要學會處理它。也許對于情緒上的利益沖突也一樣。
跟情緒上的利益沖突相關的問題是“有用的無知”。假設是在第五次迭代。由測試員/程序員/其他人員組合在一起，從開始就工作在一起。當對產品進行探索時，他會有開發習慣。如果有兩種方法做某件事，他會選擇同一個。當他使用產品時，他不會犯很多概念上的錯誤，因為他知道產品應該是怎樣工作的。他的團隊已經寫了很多指引性的例子 – 在他們做這個的時候，已經建立了一個清晰的“理想用戶”應該是怎樣的一個模型，他們會在想象其他類型的用戶會怎樣方面碰到麻煩。
這是個很難解決的問題。角色扮演能幫助解決。Elisabeth Hendrickson教測試員在測試過程中要時不時假定極端的人物。如果Bug Bunny來使用這個產品會發生什么事情呢？他是個麻煩制造者，總是探究別人的弱點，總是愚弄權威。想象一下卓別林在摩登時代的角色：天真、毫無準備、被迫工作得更快。另外一個有用的技術是Hans Buwalda的肥皂劇測試方法（Soap Opera Testing）。
我希望這些技術能幫助解決問題，尤其是結對在一起時（互相之間會感染）。但是我不禁要想偽造的無知不能替代真實的東西。
組隊
因此，是否應該包含測試員在敏捷項目中呢？要看情況而定。但是如果我負責一個重要的產品的敏捷項目組的組隊，我會考慮以下方式作為默認的做法：
我會找一到兩個擁有豐富測試經驗的人。他們應該懂一些編程的知識。他們應該擅長于跟業務專家討論并很快地獲取一些領域知識。首先，我會依靠他們來確保面向業務的例子可以很好地工作。然后我會期待他們學習更多的編程，編寫基礎代碼，教程序員，成為程序員一樣的人。
個性非常重要。他們必須喜歡新奇的事物，他們不應該把他們的個性情緒化地包含到工作中，他們應該習慣于服務其他人。
如果這些人在探索性測試中做得很出色應該受到贊賞。但是，不管怎樣，整個項目組都會得到關于探索性測試的培訓。我會讓外部的探索性測試教練定期地來造訪。他們既會擴展培訓，還會做一些探索性測試。作為一個持續的監督，用于防止項目組過于習慣于產品而不能找到足夠的bug。
對于非功能缺陷，像可用性、安全性、性能比較看重的產品，我會購買專門的技術（定點的顧問、造訪型的顧問、或者招聘這方面的專門技術人員）。他們會對創建產品提出建議、培訓項目組、測試產品。
我會極力讓真正的用戶參與（不僅僅是代表用戶的業務專家）�？赡軙岉椖拷M成員到用戶那邊，而不是反過來。我會讓項目組成員把自己想象成人類學家來研究產品所在的領域，不僅僅是傾聽bug和功能特性的請求。
是否有測試員在項目組中？誰關心這個？- 總之會有好的測試，即使指出某個活動中有測試會日益地困難，像說“那里，就在那里。那就是測試，沒別的”一樣。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
