Ray Oei:我試圖圍繞一個故事、期望的產品或者任何看上去重要的東西發現盡可能多的問題。創建一個我們正在構建產品的模型,和思維圖有助于我組織測試。提出問題。如果可能的話調查研究。我發現當我聽到程序員討論事情的時候,我經常想起一些需要測試的內容。我會遍歷代碼。當有人告訴我,我不需要因為一些不明原因檢查代碼時,那么我肯定會看一眼代碼。那是一個“計劃”嗎?如果你認為計劃是開始測試前對某個時期的設想,那么它就不是的。但是我又有測試的想法,并且我在努力嘗試執行這些想法。而且說實話,事情的發展并不總是跟我預料的一樣。有時在我有時間組織它們之前,我的一些想法已經過時了。我認為我的主要指導計劃就一個問題:“現在或者未來,這重要嗎?”。
InfoQ:有沒有一些您想推薦的具體的敏捷測試實踐?
Eddy Bruin:有一大堆的敏捷測試實踐:結對編程、實例化需求(ATDD/BDD)、TDD、大量的啟發式測試等等。對我而言總是非常優秀的一個實踐是在所有測試活動中進行溝通。當規劃測試、匯報測試和解決bug,甚至是當展示我們實際意圖構建的產品和應該給公司帶來什么產品時,我總是努力盡可能地透明化。為此我最常用的策略是擁有盡可能多的信息輻射體。墻上的活動掛圖、白板和便利貼越多,開始溝通就越容易。
Ray Oei:不是具體的敏捷測試實踐。我認為關鍵是溝通:交談與傾聽?;蛘吒玫氖牵禾岢鰡栴},并花時間傾聽和理解。了解相關的領域和業務,和使用的技術。了解你共事的成員。同樣發現你自己在那的角色和行為。我們傾向著眼于別人,認為他們應該/可以/必須完成的更好——但是你自己呢?
展示你正在做什么,已經做了什么。甚至如果需要,展示你犯錯的地方。這有助于建立信任。這方面并不是航天器學,沒那么復雜。雖然,作為技術人員,我認為航天器學比人文科學更加容易。
原文轉自:http://www.infoq.com/cn/articles/agile-approaches-test-planning