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

　　自動化回歸測試是團隊的工作。整個團隊應該選擇每種測試適合的工具。提前考慮測試將幫助開發人員為了便于測試自動化來設計代碼。使用敏捷測試象限和測試自動化金字塔來幫助你自動化各種類型的測試。

　　記住從簡單入手。你會驚訝地發現一些基本的自動化冒煙測試或者自動化單元測試會發生很大作用。

　　測試自動化是團隊的工作。開始時很艱苦，需要克服很大的痛苦。如果你管理開發或者測試團隊，確保在時間、培訓和激勵上提供了足夠的支持。如果你是沒有自動化測試的團隊的測試人員，開發人員瘋狂地編寫代碼以至于不會停下來考慮測試，那么你會面臨很大的挑戰。嘗試從管理層和團隊成員中獲取支持以開始小規模的自動化工作。

　　提供并獲取反饋

　　反饋是敏捷的核心價值。敏捷的短期迭代可以提供持續的反饋以幫助團隊運轉正常。測試人員通過自動化測試結果、探索性測試的發現和系統實際用戶的觀察結果的形式幫助提供反饋。

　　敏捷方法允許團隊獲取有關構建中軟件的反饋。這是關鍵。故事代表了測試人員和分析人員向開發人員提供反饋的工作單元。迭代發布有助于團隊外部的反饋。大多數敏捷實踐都創建了反饋循環使團隊應用。

　　測試人員也需要反饋。你怎么知道從客戶手里拿到了預期行為的正確例子?你怎么知道編寫的測試用例正確地反映了這些例子?開發人員通過查看你收集的例子和你創建的測試能夠理解應該編寫什么代碼嗎?

　　一個最有價值的技能是學習如何尋求自己工作的反饋。詢問開發人員是否得到了足夠的信息以理解需求并且是否能夠指導編碼。詢問客戶是否理解質量標準?；〞r間參與迭代計劃會議和回顧會議以討論這些問題并提出改進方案。

　　構建核心實踐的基礎

　　持續集成

　　每一個開發團隊都需要代碼管理和持續集成。如果不知道自己在測什么，就無法有效地測試，如果無法配置代碼你根本無法測試。所有團隊成員需要至少每天一次導入自己的工作。每一次集成必須通過自動化構建驗證，其中包括提供軟件狀態快速反饋的測試。

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

　　測試環境

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

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

　　管理技術債務

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

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

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

　　增量工作

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

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