敏捷軟體測試的七個關鍵成功要素​

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

使用團隊整體參與的方法

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

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

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

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

採用敏捷測試思維

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

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

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

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

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

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

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

自動化迴歸測試

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

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

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

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

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

提供並獲取反饋

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

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

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

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

構建核心實踐的基礎

• 持續整合

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

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

• 測試環境

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

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

• 管理技術債務

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

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

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

• 增量工作

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

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

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

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

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

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

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

• 實踐之間的協作

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

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

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

與客戶合作

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

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

保持大局觀

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

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

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

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