資深敏捷專家Lisa Crispin在最近的講座和參與合著的《Agile Testing – A Practical Guide for Testers and Agile Teams》中分享了敏捷軟件測試的七個關鍵成功要素，包括?使用團隊整體參與的方法、采用敏捷測試思維、?自動化回歸測試、提供并獲取反饋、構建核心實踐的基礎、與客戶合作、保持大局觀等。

　　使用團隊整體參與的方法

　　當整個開發團隊負責測試和質量問題，你會擁有很多不同的技能集合和經驗等級來處理測試可能發生的問題。測試自動化對于技能高超的開發人員來說不是大問題。當測試置于團隊的優先權，任何人都參與測試任務，團隊才會設計可測試的代碼。

　　使測試人員真正成為開發團隊的一部分意味著向他們提供支持和訓練他們適應敏捷開發的快節奏。他們需要時間掌握新技能以便與開發和客戶團隊緊密協作。

　　如果你管理一個敏捷團隊，幫助團隊使用團隊整體參與的方法。記住質量，而不是速度，才是敏捷開發的目的。團隊需要測試人員幫助客戶理清需求，轉化為指導開發的測試，提供發布優秀產品的唯一觀點。確保測試人員能夠把技能和長處轉移到團隊其他成員身上。確保他們不是局限于一種角色，如只做手動測試。確保當他們需要幫助時（可能需要極大的勇氣），團隊成員能夠提供。反過來也是如此。測試人員應該隨時準備幫助那些需要他們幫助的隊友。

　　如果你是敏捷團隊中的測試人員，并且計劃會議和設計討論沒有邀請你，或者業務用戶正在獨自定義故事和需求，那你應該站出來和團隊的其他成員交流。和開發人員一起參與會議，并提議嘗試“三方協作”，即測試人員、開發人員和業務專家。謹慎地提供反饋并幫助客戶提供例子。讓你的問題成為團隊的問題，讓他們的問題成為你的問題。請你的同事采用團隊整體參與的方法。

　　采用敏捷測試思維

　　我們提醒敏捷測試人員丟掉一直以來的“質量警察”思維。現在你在敏捷團隊中，開發人員參與測試，測試人員可以做任何事情以幫助團隊生產最優秀的產品。敏捷測試態度是前瞻性的、創造性的、歡迎新思想、樂于承擔任何任務。敏捷測試人員不斷磨練自己的技能，隨時準備協作，相信直覺，希望幫助團隊和業務成功。

　　我們并不是說你應該披上超級測試王的斗篷，去保護世界免受缺陷的危害。在敏捷團隊中不存在狂妄自大。團隊成員分享你對質量的追求。關注團隊目標，幫助每一個更好地工作。

　　使用敏捷準則和價值觀指導你。不斷嘗試最簡單的方法來滿足測試需要。勇敢地尋求幫助和實驗新想法。關注于產生價值。盡可能多的直接交流。靈活地應對變化。記住敏捷開發以人為中心，我們應該享受工作。當對此懷疑時，回顧敏捷價值和準則來決定該怎么做。

　　敏捷測試思維的一個重要部分是不斷想辦法改進工作。成功的敏捷測試人員持續地磨練技能。讀好書、博客和文章以獲得新想法和技能。參加本地的用戶組會議。加入郵件列表討論以獲得問題或者新想法的反饋。如果你的公司沒有付錢讓你參加一個很好的會議，那么把你的經驗寫成報告在免費的會上作交換。對測試和敏捷開發社區進行反饋也會對你有益。

　　實驗新的實踐、工具和技術。鼓勵團隊嘗試新方法。短期迭代非常適合這種實驗。你可能會失敗，但是很快你可以嘗試其他的。

　　如果你管理敏捷測試人員或者敏捷團隊，給他們時間去學習并提供所需的培訓支持。移除障礙使他們更好地工作。

　　當你面對影響測試的問題時，讓團隊都知道這些問題。通過頭腦風暴的方式克服這些障礙。回顧會議可以討論這些問題并想辦法解決。維護一個阻礙事項列表，并在每個迭代中解決一到兩個。使用可視化的大圖片或者虛擬方式，確保所有人都知道發生的問題并可以跟蹤編碼和測試的進度。

　　自動化回歸測試

　　敏捷團隊沒有測試自動化會成功嗎？可能吧，但是我們所知道的成功團隊都依賴自動化回歸測試。如果你花費全部時間用在手動回歸測試上，絕沒有時間用于重要的探索性測試（會發現隱藏在代碼中的危險行為）。

　　敏捷開發利用測試來指導開發。為了編寫代碼使測試通過，你需要快速、簡單地運行測試。沒有短期反饋周期和安全的回歸測試，團隊將很快陷入技術債務，缺陷不斷增加，速度越來越慢。

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

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

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

　　提供并獲取反饋

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

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

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

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

　　構建核心實踐的基礎

• 持續集成

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

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

• 測試環境

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

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

• 管理技術債務

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

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

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

• 增量工作

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

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

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

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

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

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

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

• 實踐之間的協作

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

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

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

　　與客戶合作

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

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

　　保持大局觀

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

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

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

　　團隊的每一個人都很容易只關注手邊的一個任務或者故事。這是一次只做一塊功能的缺點。幫助你的團隊后退一步，評估當前的故事如何負責業務的大局。不斷問自己如何才能更好的產生真正的價值。

it知識庫：敏捷軟件測試的七個關鍵成功要素?，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。