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

　　使用團(tuán)隊整體參與的方法

　　當(dāng)整個開發(fā)團(tuán)隊負(fù)責(zé)測試和質(zhì)量問題，你會擁有很多不同的技能集合和經(jīng)驗等級來處理測試可能發(fā)生的問題。測試自動化對于技能高超的開發(fā)人員來說不是大問題。當(dāng)測試置于團(tuán)隊的優(yōu)先權(quán)，任何人都參與測試任務(wù)，團(tuán)隊才會設(shè)計可測試的代碼。

　　使測試人員真正成為開發(fā)團(tuán)隊的一部分意味著向他們提供支持和訓(xùn)練他們適應(yīng)敏捷開發(fā)的快節(jié)奏。他們需要時間掌握新技能以便與開發(fā)和客戶團(tuán)隊緊密協(xié)作。

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

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

　　采用敏捷測試思維

　　我們提醒敏捷測試人員丟掉一直以來的“質(zhì)量警察”思維?，F(xiàn)在你在敏捷團(tuán)隊中，開發(fā)人員參與測試，測試人員可以做任何事情以幫助團(tuán)隊生產(chǎn)最優(yōu)秀的產(chǎn)品。敏捷測試態(tài)度是前瞻性的、創(chuàng)造性的、歡迎新思想、樂于承擔(dān)任何任務(wù)。敏捷測試人員不斷磨練自己的技能，隨時準(zhǔn)備協(xié)作，相信直覺，希望幫助團(tuán)隊和業(yè)務(wù)成功。

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

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

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

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

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

　　當(dāng)你面對影響測試的問題時，讓團(tuán)隊都知道這些問題。通過頭腦風(fēng)暴的方式克服這些障礙?；仡檿h可以討論這些問題并想辦法解決。維護(hù)一個阻礙事項列表，并在每個迭代中解決一到兩個。使用可視化的大圖片或者虛擬方式，確保所有人都知道發(fā)生的問題并可以跟蹤編碼和測試的進(jìn)度。

　　自動化回歸測試

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

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

　　自動化回歸測試是團(tuán)隊的工作。整個團(tuán)隊?wèi)?yīng)該選擇每種測試適合的工具。提前考慮測試將幫助開發(fā)人員為了便于測試自動化來設(shè)計代碼。使用敏捷測試象限和測試自動化金字塔來幫助你自動化各種類型的測試。

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

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

　　提供并獲取反饋

　　反饋是敏捷的核心價值。敏捷的短期迭代可以提供持續(xù)的反饋以幫助團(tuán)隊運轉(zhuǎn)正常。測試人員通過自動化測試結(jié)果、探索性測試的發(fā)現(xiàn)和系統(tǒng)實際用戶的觀察結(jié)果的形式幫助提供反饋。

　　敏捷方法允許團(tuán)隊獲取有關(guān)構(gòu)建中軟件的反饋。這是關(guān)鍵。故事代表了測試人員和分析人員向開發(fā)人員提供反饋的工作單元。迭代發(fā)布有助于團(tuán)隊外部的反饋。大多數(shù)敏捷實踐都創(chuàng)建了反饋循環(huán)使團(tuán)隊應(yīng)用。

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

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

　　構(gòu)建核心實踐的基礎(chǔ)

• 持續(xù)集成

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

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

• 測試環(huán)境

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

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

• 管理技術(shù)債務(wù)

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

　　大家經(jīng)常說：“我們的管理層不會給我們時間做這些，沒有時間重構(gòu)，日程很緊”。但是，我們可以很容易舉一個業(yè)務(wù)用例來顯示增長的技術(shù)債務(wù)如何耗費公司的成本。衡量代碼和缺陷率哪些會導(dǎo)致技術(shù)負(fù)債變?yōu)閷Φ拙€的影響存在很多辦法。僅僅指出不斷下降的速度就足夠了。業(yè)務(wù)需要軟件開發(fā)團(tuán)隊保持持續(xù)的生產(chǎn)力。他們不得不減少期望功能的范圍以保證足夠的時間來進(jìn)行良好的、測試規(guī)范的代碼設(shè)計和優(yōu)秀實踐，如持續(xù)小規(guī)模重構(gòu)。

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

• 增量工作

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

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

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

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

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

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

　　當(dāng)編碼一直由測試指導(dǎo)，編碼的同時進(jìn)行測試，我們更有可能達(dá)到客戶預(yù)期的行為，提供客戶所需的價值。測試是團(tuán)隊的職責(zé)。如果團(tuán)隊沒有這種觀念，讓所有人想一想對質(zhì)量的關(guān)注、對發(fā)布優(yōu)秀產(chǎn)品的期待和采取哪些措施來確保團(tuán)隊實現(xiàn)目標(biāo)。

• 實踐之間的協(xié)作

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

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

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

　　與客戶合作

　　測試人員對敏捷團(tuán)隊的最大貢獻(xiàn)之一是幫助客戶理清需求并設(shè)定優(yōu)先級，通過預(yù)期行為和用戶場景的具體例子描繪需求，并把這些例子轉(zhuǎn)換為可執(zhí)行的測試。測試人員使用業(yè)務(wù)的領(lǐng)域語言和開發(fā)團(tuán)隊的技術(shù)語言。我們擔(dān)任優(yōu)秀的輔助者和翻譯。

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

　　保持大局觀

　　我們發(fā)現(xiàn)測試人員有大局觀，通常從客戶的角度看問題。開發(fā)人員通常關(guān)注于實現(xiàn)當(dāng)前的故事，雖然他們使用測試來指導(dǎo)，但是不得不關(guān)注于需求的技術(shù)實現(xiàn)。

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

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

　　團(tuán)隊的每一個人都很容易只關(guān)注手邊的一個任務(wù)或者故事。這是一次只做一塊功能的缺點。幫助你的團(tuán)隊后退一步，評估當(dāng)前的故事如何負(fù)責(zé)業(yè)務(wù)的大局。不斷問自己如何才能更好的產(chǎn)生真正的價值。

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

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