使用敏捷軟件測試方法成功的七要素(2)

實現持續集成過程應該是軟件開發團隊中優先級最高的事情。如果團隊沒有每日構建驗證的版本，停止手里的工作，開始構建。就是這么重要。一開始并不要求太高。如果你有很大的系統需要集成，肯定會更具挑戰性。通常來說沒有那么困難，市面上存在很多優秀的工具，開源的、商業的。

測試環境

沒有可控的測試環境就無法有效地測試。你需要知道部署了什么版本，使用的數據庫模式是什么，其他人是不是正在更新，其他進程是否運行在那臺機器上。

硬件總是越來越便宜，開源軟件越來越多。團隊必須投資以有效地執行自動化和手動探索性測試。如果測試環境出現問題，趕緊說出來，讓全隊一起解決。

管理技術債務

即使優秀的軟件開發團隊在感覺到時間壓力之后，也會忽視重構或者快速解決問題修補缺陷。隨著代碼越來越混亂和難以維護，更多的缺陷出現，很快團隊的速度就慢了下來，因為要解決缺陷才能添加新的功能。團隊必須不斷地評估技術債務的數量，并努力減少和避免。

大家經常說：“我們的管理層不會給我們時間做這些，沒有時間重構，日程很緊”。但是，我們可以很容易舉一個業務用例來顯示增長的技術債務如何耗費公司的成本。衡量代碼和缺陷率哪些會導致技術負債變為對底線的影響存在很多辦法。僅僅指出不斷下降的速度就足夠了。業務需要軟件開發團隊保持持續的生產力。 他們不得不減少期望功能的范圍以保證足夠的時間來進行良好的、測試規范的代碼設計和優秀實踐，如持續小規模重構。

自動化回歸測試的良好覆蓋率是最小化技術債務的關鍵。如果缺少，那就在每個迭代中拿出時間來構建自動化測試，規劃一個“重構迭代”以升級或添加必要的工具，編寫測試并進行重構。在每個迭代中花時間通過測試指導代碼，重構必要的代碼，添加丟失的自動化測試。對這件工作要重視。長期來看，團隊能夠變得更快。

增量工作

敏捷團隊能夠生產高質量代碼的一個原因是他們小規模地工作。故事代表了幾天的工作量，每個故事被分解成小增量，按步構建。測試可以針對一小塊，并且隨著功能聚集再增量測試。

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

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

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

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

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

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

實踐之間的協作

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

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

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

與客戶合作

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

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

保持大局觀

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

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

使用敏捷測試象限作為綱領幫助規劃測試覆蓋范圍。使用測試金字塔確保自動化測試的良好投資回報率。通過測試指導開發有助于確保你沒有丟失 重要的事情，但并不完美。使用探索性測試了解系統應該如何工作，測試應該指向哪個方向。讓你的測試環境盡可能與實際環境類似，使用反映現實世界的數據。勤 于重新構建一個實際環境類似的場景，如負載測試所需。團隊的每個人都很容易只關注手邊的一個任務或者故事。這是一次只做一塊功能的缺點。幫助你的團隊后退一步，評估當前的故事如何負責業務的大局

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