敏捷軟件測試的七個關鍵成功要素(3)

　　如果團隊成員喜歡一次開發一大塊功能，鼓勵他們采用步驟式的方法。提出問題：“這個故事的核心業務價值是什么?這塊代碼的最基本路徑是什么?下一步干什么?”建議大家編寫任務卡片以編碼和測試小增量，記錄設計概念和確認測試和測試自動化策略。

　　編碼和測試是同一個過程的組成部分

　　對敏捷思想不熟悉的人經常會問敏捷測試人員：“在所有故事完成并且可以測試的時候你會怎么做?”經驗豐富的敏捷實踐者會說：“測試人員必須貫穿整個迭代，整個開發過策劃那個。否則就會失敗”。

　　測試人員基于客戶提供的例子編寫測試，以幫助開發人員理解故事并開始編程。測試和例子提供了一種通用語言使所有人都參與到軟件理解中。測試人員和開發人員在編碼時緊密合作，他們也會與客戶緊密合作。開發人員向測試人員展示他們編寫的功能，測試人員向開發人員展示他們發現的異常行為。測試人員隨著編碼進展編寫更多測試，開發人員是其通過測試，測試人員進行更多探索性測試以了解是否生產了正確的價值。每一個敏捷迭代包含了若干持續、快速、增量的測試——代碼 —— 測試——代碼——測試迭代。

　　當這種合作和反饋周期被打斷，并且測試與開發分離時，糟糕的事情會發生。如果故事是在編碼之后的迭代中被發現的，開發人員不得不停止新的故事，回憶代碼是如何實現上個迭代的故事的，修補它，并且等待其他人測試。在軟件開發中沒有什么幾個事實，但是我們確定缺陷發現的越早，修補的成本越低。

　　當編碼一直由測試指導，編碼的同時進行測試，我們更有可能達到客戶預期的行為，提供客戶所需的價值。測試是團隊的職責。如果團隊沒有這種觀念，讓所有人想一想對質量的關注、對發布優秀產品的期待和采取哪些措施來確保團隊實現目標。

　　實踐之間的協作

　　單個敏捷開發實踐如持續集成能夠發揮作用，但是多個敏捷實踐的組合比各個部分相加要大。測試驅動設計、共有代碼所有權和持續集成一起促進快速反饋、持續改進代碼設計和快速產生業務價值。自動化測試很好，但是使用自動化測試驅動開發，隨后是探索性測試以發現缺陷或者弱點，分多層次更好。

　　某些實踐單獨操作并不好。沒有自動化測試，重構是不可能的。通過迷你瀑布型的方式發布小版本會丟失敏捷開發的所有優勢。如果你的現場客戶沒有做決定的授權，那么他對團隊的價值有限。

　　敏捷實踐是互補的?；〞r間理解各個實踐的目的，想想如何利用全部優勢，針對什么對團隊有用做出深思熟慮的決定。

　　與客戶合作

　　測試人員對敏捷團隊的最大貢獻之一是幫助客戶理清需求并設定優先級，通過預期行為和用戶場景的具體例子描繪需求，并把這些例子轉換為可執行的測試。測試人員使用業務的領域語言和開發團隊的技術語言。我們擔任優秀的輔助者和翻譯。

　　千萬不要阻礙開發人員和客戶之間的直接溝通。鼓勵盡可能多地直接交流。使用“三方協作”方法。當需求丟失或者被誤解，客戶、開發人員和測試人員需要一起解決問題。請客戶經常在白板或者其他虛擬工具前討論問題。如果客戶發布于不用的地區、國家，那就使用任何能找到的工具來加強溝通和協作。電視會議、即時消息和 wiki不能完美的替代面對面的交流，但是也比發郵件或者什么都不做要好。

　　保持大局觀

　　我們發現測試人員有大局觀，通常從客戶的角度看問題。開發人員通常關注于實現當前的故事，雖然他們使用測試來指導，但是不得不關注于需求的技術實現。

　　大局觀對團隊貢獻巨大。測試驅動開發，如果完成得很好，單獨的代碼沒有缺陷。如果新的功能導致一些應用明顯不相關的部分崩潰怎么辦?一些人不得不考慮這種對較大系統的影響并引起團隊注意。如果我們忽略了一些可能惹惱客戶的細節怎么辦?新的UI可能沒什么缺陷，但是如果背景顏色使文本難以閱讀怎么辦?這都是最終用戶會注意到的問題。

　　使用敏捷測試象限作為綱領來幫助規劃測試覆蓋所有范圍。使用測試金字塔思想確保測試自動化的良好投資回報率。通過測試指導開發有助于確保你沒有丟失重要的事情，但并不完美。使用探索性測試了解系統應該如何工作，測試應該指向哪個方向。讓你的測試環境盡可能與生產環境類似，使用反映現實世界的數據。勤于重新構建一個生產環境類似的場景，如負載測試所需。

原文轉自：http://www.anti-gravitydesign.com