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

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

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

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

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

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

　　采用敏捷測(cè)試思維

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

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

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

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

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

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

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

　　自動(dòng)化回歸測(cè)試

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

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

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

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

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

　　提供并獲取反饋

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

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

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

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

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

• 持續(xù)集成

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

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

• 測(cè)試環(huán)境

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

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

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

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

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

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

• 增量工作

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

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

• 編碼和測(cè)試是同一個(gè)過程的組成部分

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

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

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

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

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

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

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

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

　　與客戶合作

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

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

　　保持大局觀

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

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

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

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

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

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