測試敏捷化 vs 敏捷測試

測試敏捷化 vs 敏捷測試

本文首發(fā)于網(wǎng)站【 林子的空間 】

大家可能關注到雙態(tài)IT聯(lián)盟前一陣發(fā)布了一個 測試敏捷化成熟度評估模型，不斷有小伙伴問到我關于這個成熟度評估的問題，我發(fā)現(xiàn)大家很自然地把這個跟敏捷測試成熟度畫上了等號，不過這不是Thoughtworks開發(fā)的，我也不是很清楚。為此，我特地進行了一番調(diào)研，希望我這篇文章的解讀能解答大伙大部分的疑問。

我們先嘗試從字面意思來理解一下，對于以下兩個術語大家都比較熟悉：

這兩個例子，相信大家都能理解沒有問題。關于測試敏捷化，類似地，從字面意思可以這樣理解：

那么，“敏捷的測試”是否等同于“敏捷測試”呢？從字面意思來看，似乎是等同的。但事實如何，需要對兩者有深入的理解才可以下定論。

為了更好地解釋，有必要先介紹什么是敏態(tài)與穩(wěn)態(tài)。

在數(shù)字化轉型時代，企業(yè)一方面需要適應數(shù)字化時代快速變化的市場需求，另一方面需要保持關鍵業(yè)務的安全可靠和穩(wěn)定性，傳統(tǒng)的IT需要同時適應這兩種業(yè)務形態(tài)，面臨很大的挑戰(zhàn)。為了應對這種挑戰(zhàn)，Gartner公司提出 雙模IT（Bimodal IT） 的理念：

傳統(tǒng)企業(yè)數(shù)字化轉型的常規(guī)做法是可預見性的業(yè)務使用傳統(tǒng)瀑布式開發(fā)，稱之為 穩(wěn)態(tài) ；探索性的業(yè)務使用敏捷開發(fā)，稱之為 敏態(tài)。Thoughtworks洞見安輝的文章 《敏捷轉型中的敏態(tài)與穩(wěn)態(tài)》 對此有比較詳細的介紹。

當然，穩(wěn)態(tài)和敏態(tài)的這種做法在業(yè)界也存在爭議。Thoughtworks數(shù)字化專家肖然在文章 《數(shù)字化時代的科技雙模，雙模IT成為過去式》 中指出：

盡管如此，傳統(tǒng)企業(yè)轉型過程中，基本都會長期經(jīng)歷敏態(tài)和穩(wěn)態(tài)共存的階段，對轉型有著積極的意義。從長遠來看，最終還是需要轉型到組織級的敏捷，實現(xiàn)真正的全流程端到端敏捷的。

關于敏捷測試，引用Wikipedia的兩段話：

從Wikipedia的定義可以看到：

同時，Thoughtworks的資深QA們基于多年敏捷團隊開發(fā)實踐經(jīng)驗提煉出的 敏捷測試宣言，非常清晰的表述了敏捷測試的價值觀：

敏捷測試是 基于敏捷價值觀“快速高效地交付更大的價值”這個目標，所開展的所有質(zhì)量相關活動，是從團隊的角度去思考如何實現(xiàn)這個目標，而不再是以測試這個活動/角色的角度出發(fā)，不能簡單地理解為“敏捷的測試”或“敏捷地測試”。

關于敏捷測試的更多詳細內(nèi)容，歡迎參考劉冉老師的 《Thoughtworks的敏捷測試》 文章和我的 《敏捷測試》系列 文章。

測試敏捷化這個概念來自于雙態(tài)IT聯(lián)盟發(fā)布的 《測試敏捷化白皮書》 （以下簡稱“白皮書”），這里直接引用該白皮書中的內(nèi)容來解釋測試敏捷化。

從前面引用的內(nèi)容來看，測試敏捷化是將測試作為 獨立主體，從測試的角度出發(fā)來考慮優(yōu)化和改進。

基于白皮書的內(nèi)容，雙態(tài)IT聯(lián)盟還發(fā)布了相應的成熟度評估模型，這個成熟度評估也是 基于測試的幾個維度 進行的：

到此，我們可以比較清晰地看到測試敏捷化是圍繞測試在解決問題，考慮的更多是測試價值的體現(xiàn)。

了解了概念，再來從背景、目標、主體、關注點和適用范圍這幾個維度集中對比一下測試敏捷化與敏捷測試：

從上表我們不難看出測試敏捷化與敏捷測試具備較大差異：

敏捷測試是產(chǎn)生于敏捷軟件開發(fā)模式，在這種新型開發(fā)模式下需要考慮如何滿足質(zhì)量保障的需求，自然而然產(chǎn)生了敏捷測試。敏捷測試是遵循敏捷價值觀的，其目標也是跟敏捷開發(fā)一致，那就是快速高效地交付更大的價值。

測試敏捷化則是在數(shù)字化轉型過程中敏穩(wěn)兩態(tài)共存的情形下，傳統(tǒng)IT穩(wěn)態(tài)模式的測試團隊面臨轉型挑戰(zhàn)，旨在幫助測試團隊實現(xiàn)轉型。因此，測試敏捷化的目標主要是為了體現(xiàn)測試的價值，提升測試團隊的敏捷能力。

為了實現(xiàn)目標，敏捷測試以全功能的敏捷開發(fā)團隊為主體，關注軟件開發(fā)全生命周期的質(zhì)量相關活動。敏捷測試不再是以測試這個檢驗環(huán)節(jié)/活動為主，不會強調(diào)某個獨立角色，而是要求團隊整體為質(zhì)量負責，實現(xiàn)測試左移、持續(xù)測試和測試右移，快速獲取反饋，從而真正實現(xiàn)軟件產(chǎn)品的質(zhì)量內(nèi)建。

而測試敏捷化是以測試作為獨立主體，以測試的角度出發(fā)考慮優(yōu)化改進，主要關注點包括測試需求、測試計劃、測試設計、測試執(zhí)行等測試過程，以及環(huán)境、數(shù)據(jù)、技術、工具等測試的支撐。

如上面數(shù)字化轉型示意圖所示：

敏捷測試產(chǎn)生于敏捷開發(fā)模式，必然適用于純敏態(tài)的開發(fā)團隊。同時，敏捷測試的一些方法和實踐，也可以被穩(wěn)態(tài)團隊所借鑒并適當采用。

測試敏捷化由于背景、目標、主體和關注點都不同于敏捷測試，是不宜用于敏態(tài)開發(fā)環(huán)境的，只適用于穩(wěn)態(tài)環(huán)境。

數(shù)字化轉型的確給傳統(tǒng)測試團隊帶來很大的挑戰(zhàn)，一方面要配合敏態(tài)團隊實現(xiàn)測試開發(fā)融合，另一方面還要面臨穩(wěn)態(tài)測試如何優(yōu)化改進的問題。

測試敏捷化雖然在一定程度上幫助轉型中的穩(wěn)態(tài)測試團隊，但是不能從根本上幫助轉型的實現(xiàn)。另外，前面提到敏穩(wěn)雙態(tài)共存模式不過是轉型中的一個過渡階段，是否要為這種過渡時期的穩(wěn)態(tài)模式投入較多精力，請深思而前行。

測試要實現(xiàn)轉型以適應敏捷開發(fā)模式，不能只是測試人員的轉型、也不能只是測試工作方式的轉型，只有改變文化理念和認知方式、調(diào)整組織架構和溝通方式、優(yōu)化流程和策略、采用有利于快速反饋的工具與實踐，按照由內(nèi)而外的“道”->“法”->“術”->“器”方向?qū)崿F(xiàn)徹底的轉型，才有可能實現(xiàn)真正的敏捷測試。這個內(nèi)容我在文章 《數(shù)字化轉型背景下的測試轉型》 里有非常詳細的介紹，請移步閱讀。

敏捷測試不是“敏捷的測試”，也不是“敏捷地測試”，而測試敏捷化是“敏捷地測試”，兩者不等同。

由于測試敏捷化的背景、目標、主體和關注點都不同于敏捷測試，是不宜用于敏捷開發(fā)模式的，只適用于傳統(tǒng)企業(yè)的穩(wěn)態(tài)模式，也不能幫助穩(wěn)態(tài)團隊實現(xiàn)敏捷轉型。而敏態(tài)、穩(wěn)態(tài)共存本身就是數(shù)字化轉型的過渡階段的產(chǎn)物，因此在穩(wěn)態(tài)測試團隊采用也需要謹慎前行。

傳統(tǒng)測試的真正敏捷轉型需要遵循“道”->“法”->“術”->“器”方向、實現(xiàn)由內(nèi)而外的轉變才能實現(xiàn)。

敏捷測試與傳統(tǒng)測試的區(qū)別

首先敏捷測試(Agile testing)是測試的一種，敏捷測試的理念是，和編碼一樣，測試是開發(fā)的一個關鍵部分。在敏捷中，測試被直接集成到軟件開發(fā)過程中，以便盡早、頻繁地發(fā)現(xiàn)bug。因此，測試人員可以在開發(fā)過程的每一個節(jié)點上發(fā)現(xiàn)問題，從而使產(chǎn)品快速走向發(fā)布。

敏捷測試的特點有以下幾點：

傳統(tǒng)測試即基于瀑布模型開發(fā)的測試，瀑布模型將軟件生命周期劃分為 制定計劃、需求分析、軟件設計、程序編寫、軟件測試 和 運行維護 六項基本活動，其過程是將上一項活動接收的工作對象作為輸入，當該項活動完成后會輸出該項活動的工作成果，并將該項成果作為下一項活動的輸入。該模型規(guī)定這六項基本活動自上而下、固定相互銜接的次序，如同瀑布流水，逐級下落。從本質(zhì)上講，它是一個軟件開發(fā)架構，開發(fā)過程是通過一系列階段順序展開的，從需求分析直到產(chǎn)品發(fā)布和維護。如果在其中某個階段有信息未被覆蓋或有問題，那么就得返回到上一個階段，并對這些階段進行適當?shù)男薷牟拍苓M入下一個階段，這樣每個階段都會產(chǎn)生循環(huán)反饋，開發(fā)過程從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。

瀑布模型的優(yōu)點如下：

增量迭代應用于瀑布模型，迭代1 解決最大的問題，每次迭代產(chǎn)生一個可運行的版本，同時增加更多的功能，但每次迭代必須經(jīng)過嚴格的質(zhì)量和集成測試。

瀑布模型有以下缺點：

搞清楚了什么是敏捷測試，什么是傳統(tǒng)測試，最后我們來對比一下他們之間的區(qū)別，整理如下：

敏捷測試0：開發(fā)和測試打架，怎么辦？

開發(fā)和測試是怎么打架的？

線上出了 Bug 召集會議復盤，開發(fā)指責測試沒測出來，沒把好質(zhì)量關；測試抱怨開發(fā)不做單元測試，要不早發(fā)現(xiàn)了。

結果往往是大家寫個改進報告，測試保證添加相關測試用例并補充到回歸測試集，開發(fā)承諾以后做好自測，提交了事。
這就是我工作中經(jīng)常遇到的事情，怎么破？

用敏捷測試的方法來解決。具體怎么解決，我們以后說。

什么是敏捷測試？

究竟什么是“敏捷測試”？敏捷測試是指敏捷開發(fā)模式下的一套完整的軟件測試解決方案。它強調(diào)“與開發(fā)協(xié)作”、“自動化測試”、“客戶思維”和“動態(tài)的測試策略調(diào)整”。

不變的是它的價值觀、理念以及思維方式；變的是持續(xù)改進的敏捷測試方法、技術和工具。

敏捷測試課程主要內(nèi)容有哪些？

一、什么是敏捷測試

二、如何管理敏捷測試中的人

三、如何搭建敏捷測試框架

四、如何逐步實施敏捷測試

從今天開始記錄敏捷測試課程學習筆記，用輸出倒逼輸入。

現(xiàn)實世界中出現(xiàn)問題了，我這里有個解決方法，我將從四個方面為你講述這個方法。
如果你也遇到這種問題了，那過來一起學習吧！

什么是敏捷軟件測試

【編者按】敏捷的理念已經(jīng)深入人心，開發(fā)過程已經(jīng)漸入佳境，測試的處境卻稍顯尷尬。測試從業(yè)者應該何去何從，怎樣才能擁抱敏捷，體現(xiàn)出自己新的價值呢？InfoQ特地邀請了來自Google的敏捷測試專家段念，為讀者答疑解惑，希望所有測試從業(yè)者可以從中得到自己的答案。更多關于敏捷測試的內(nèi)容，請訪問InfoQ中文站敏捷測試相關內(nèi)容。在與不少測試從業(yè)人員討論到敏捷的時候，被問得最多的大約是兩個問題：到底？，敏捷軟件開發(fā)還需要測試工程師嗎？。前一個問題是對于敏捷測試本身定義的疑問，第二個問題則是對敏捷開發(fā)將測試工程師排除在外的擔心。其實，在探尋這兩個問題答案的過程中，我們可以更清晰的了解敏捷軟件開發(fā)中測試的工作定義，測試價值觀，以及敏捷開發(fā)中開發(fā)與測試工程師的配合。鑒于這兩個問題的意義，在本敏捷測試專欄的第一篇文章中，本人嘗試從自己的實踐出發(fā)，盡可能清楚的回答這兩個問題。確實，相對于敏捷開發(fā)紅遍大江南北的狀況而言，對敏捷測試的討論則低調(diào)得多。敏捷聯(lián)盟定義了敏捷的4個價值聲明，以及伴隨的12條支持原則，這12條原則中沒有一條單獨提到測試。這是不是意味著測試在敏捷開發(fā)中并不重要呢？實際上，如果仔細研讀敏捷的12個原則，以及各種不同的敏捷實踐，就會發(fā)現(xiàn)，測試在敏捷開發(fā)中占有非常重要的地位。無論是原則中的頻繁交付，還是對可工作的軟件的度量，或是敏捷開發(fā)實踐中的測試驅(qū)動開發(fā)，行為驅(qū)動開發(fā)，都離不開測試的支持。在本人看來，敏捷開發(fā)中不把測試單獨拿出來描述的原因，恰恰是因為在敏捷開發(fā)中，測試不再是一個單獨的、和開發(fā)獨立的過程，而是變成了驅(qū)動開發(fā)、衡量產(chǎn)出的主要的手段，成為了敏捷開發(fā)中所有工程師在工作時必須時刻考慮和實踐的一個部分。簡而言之，敏捷軟件測試更多的是一種理念，而非過程。既然是這樣，為什么我們還要在這個專欄中專門來討論敏捷軟件測試？本人接觸過不少軟件開發(fā)和測試工程師，他們所處的組織有的正在努力向敏捷開發(fā)轉型，有的已經(jīng)實踐了一段實踐的敏捷開發(fā)，但由于由來已久的工作習慣，他們中的絕大多數(shù)并不能自覺的認識到測試在敏捷開發(fā)中的關鍵作用，而是有意無意的將測試仍然看作是與開發(fā)截然分開的下一個階段，導致在實踐敏捷開發(fā)的過程中遇到種種問題：要么是忽略了代碼質(zhì)量，導致在頻繁的迭代過程中，每一個迭代的問題層出不窮；或是沿用原有的方法安排對系統(tǒng)的系統(tǒng)測試，導致測試團隊疲于奔命，卻總也趕不上開發(fā)所要求的進度。在這種情況下，專門來討論敏捷軟件開發(fā)中的測試，也就是敏捷軟件測試的話題，對這些工程師應該會有一些幫助。那么，到底？很難給敏捷測試下一個精確、完善的定義，在本人看來，接納了敏捷的核心價值觀（溝通，簡單，反饋，勇氣，尊重），在敏捷軟件開發(fā)過程中開展的測試就可以被稱作是敏捷軟件測試。因此，敏捷軟件測試并不是一個與敏捷軟件開發(fā)同一層次的劃分，而是敏捷軟件開發(fā)中的一部分，與傳統(tǒng)的測試不同，敏捷軟件測試并不是一個獨立的過程，相反，它與整個敏捷開發(fā)中的其他活動交織在一起，處處都能看到它的影子。由于敏捷軟件測試并不傾向于一個單獨的過程定義，本人擬從敏捷軟件測試與傳統(tǒng)測試觀點的比較、敏捷軟件測試中采用的方法、測試工程師在敏捷軟件測試過程中的工作等方面來闡述之。在這篇文章中，我們主要從宏觀的角度來描述敏捷軟件測試，而在本專欄的后續(xù)文章中，我們將對敏捷軟件測試中采用的方法、工程師在敏捷軟件測試中的工作內(nèi)容等進行進一步的描述。使用Dashboard、燃盡圖等方式展示當前工作與可交付產(chǎn)品之間的距離建立單元測試覆蓋率等度量指標共享質(zhì)量目標意味著質(zhì)量責任由所有工程師共同承擔開發(fā)測試應該建立一定的測試覆蓋率標準，例如，在單元測試這個級別上，建立60%或80%的覆蓋率要求通過使用TDD、BDD等技術，保證產(chǎn)品和代碼的可測試性建立足夠多的自動化測試，保證測試能夠滿足快速迭代的要求檢查表提到了團隊、反饋、質(zhì)量文化和開發(fā)測試四個方面的內(nèi)容，在本人看來，這四個方面體現(xiàn)的就是敏捷軟件測試與傳統(tǒng)軟件測試的最大的不同。傳統(tǒng)軟件測試關注的是通過盡可能完備的覆蓋去發(fā)現(xiàn)盡可能多的問題，把測試和開發(fā)當成是兩個獨立的過程，測試是對開發(fā)階段產(chǎn)生成果的驗證。而敏捷軟件測試則建立了一種不同的質(zhì)量文化：測試的目的是為了保證產(chǎn)品快速發(fā)布，也就是對生產(chǎn)率本身的提高。基于驗證的出發(fā)點必然會要求測試與開發(fā)的獨立，以及盡可能客觀和完備的度量產(chǎn)品質(zhì)量；而基于生產(chǎn)率的出發(fā)點則要求建立敏捷的團隊，要求測試與開發(fā)盡可能緊密，要求建立具有高度可測試性的軟件，以及基于這些的高度自動化測試。在檢查表列出的所有項目中，質(zhì)量文化是基礎，團隊是敏捷軟件測試得以實施的條件，反饋和開發(fā)測試則是敏捷軟件測試的具體方法。當然，你可以可以從敏捷的核心價值觀來階段這些項目：團隊關注的是溝通與尊重；反饋直接對應于反饋；質(zhì)量文化基于勇氣（承擔質(zhì)量責任的勇氣）與尊重；而開發(fā)測試則是反饋與簡單的具體體現(xiàn)。另一個在本文最初提出來的問題是：敏捷軟件開發(fā)還需要測試工程師嗎？，對這個問題，業(yè)界有不同的觀點。有人認為需要，因為總有一些是需要測試工程師的技能完成的工作；當然，也有人認為不需要，因為敏捷開發(fā)中的測試注重開發(fā)測試與自動化測試，開發(fā)工程師就可以自己搞定與測試相關的工作。在實踐中，那些大規(guī)模實踐敏捷開發(fā)的公司（例如Google），傾向于在組織中設置數(shù)量較少的測試工程師，在項目中分配較少的測試資源，甚至對某些項目，完全不使用測試工程師。就我的個人實踐經(jīng)驗，對大部分的項目，尤其是為明確的客戶開發(fā)的項目，需要在敏捷開發(fā)團隊中設置專職的測試工程師，因為：測試與開發(fā)具有不同的思維方式：測試更注重全面的驗證和檢查一個系統(tǒng)，而開發(fā)工程師往往很難在大的范圍內(nèi)建立這樣的思維方式。因此，無論是從系統(tǒng)的層面驗證產(chǎn)品，或是從應用系統(tǒng)的角度發(fā)現(xiàn)值得測試和驗證的點（access point），專職的測試工程師都更有效。專職的測試工程師能夠更關注于測試基礎，建立測試需要的基礎架構：由于測試工程師具有更好的對測試的理解，通常他們能夠更多的考慮測試的需求而開發(fā)適合項目的測試基礎架構（自動化測試框架），而開發(fā)工程師可以使用這些框架來建立面向功能或代碼的測試。但是，不得不說的是，敏捷開發(fā)對開發(fā)和測試工程師都提出了更要的要求，尤其是對測試工程師而言，傳統(tǒng)的只能精確模擬用戶操作的測試工程師，因為不能為產(chǎn)品帶來生產(chǎn)率的提升，在敏捷開發(fā)的團隊中，很難有所作為。在本專欄的后續(xù)文章中，我們會進一步討論測試工程師在敏捷軟件開發(fā)中的工作和任務。關于作者段念：Google中國高級測試經(jīng)理，畢業(yè)于華中科技大學，先后在通訊、嵌入式軟件、互聯(lián)網(wǎng)等多個行業(yè)的國內(nèi)外知名公司中從事軟件開發(fā)與測試工作。對軟件測試中的技術和管理工作有獨到見解，對軟件測試團隊管理、自動化測試、性能測試與開發(fā)測試有較多研究。

敏捷團隊中的測試策略

這篇文章主要總結了我對于敏捷項目中總體測試策略的理解，主要來自于工作上的實踐和思考。

先看下維基百科上關于 test strategy 的定義

歸納上面的定義，我們可以得出測試策略的最終目的是通過定義項目會采用的測試活動，盡可能得暴露和消除產(chǎn)品缺陷，減輕產(chǎn)品風險。除此之外，由于軟件開發(fā)時常伴有交付壓力，測試的時間和資源都是無法保證甚至可能被壓縮的，所以測試策略還會從最低成本揭露產(chǎn)品質(zhì)量風險出發(fā)，選擇出最合理的測試方法和測試過程。

基于上面的定義，可見測試策略解決了兩個大問題：

在詳細點就是：

要說不同，先看定義上的不同。

由上可見，其實測試策略的內(nèi)容已經(jīng)被包含在測試計劃里面了。測試策略定義應該做什么樣的測試而測試計劃包含所有關于測試策略該如何執(zhí)行的信息，這些信息在測試計劃里面被很好的組織起來。

一個公式可以進一步說明他們的關系 test plan = test strategy + test logistics。所以test strategy可以被看做是test plan的一部分。Test logistics 是指測試環(huán)境設置以及人力資源等等。

在James Bach的博客 A Question about Test Strategy 中，他把三者描述如下

讓我們先來看下QA在敏捷項目中的主要工作，如下圖所示

那你可能問“咦，怎么沒有測試策略相關內(nèi)容呢”。其實，整個開發(fā)測試流程就體現(xiàn)了測試策略的內(nèi)容。上圖所示的迭代開發(fā)流程里面包含了"Automated Acceptance Tests" & “Story Testing” & “System Testing”這些測試活動，那么為什么項目需要這些測試活動？這些活動如何具體如何開展？分別在哪一個項目階段進行？這些問題都屬于測試策略的范疇，是由測試策略定義和落地的。

敏捷開發(fā)模型下，迭代式的開發(fā)具有周期短和交付壓力大的特點，對于如何快速響應新需求，保障新需求的質(zhì)量以及已實現(xiàn)需求的回歸測試都將是測試的挑戰(zhàn)。如果沒有一個匹配項目上下文，合理規(guī)劃了測試活動的測試策略，這些挑戰(zhàn)就會持續(xù)困擾著團隊，所以標題的答案是當然需要。測試策略在敏捷開發(fā)模型下，通過詳細定義項目的測試活動，能夠更加合理地利用測試資源和統(tǒng)一項目對測試的認知。

此外，測試策略也是敏捷項目質(zhì)量保障體系中重要的一節(jié)。

在傳統(tǒng)瀑布開發(fā)模式下，測試計劃test plan被認為是項目測試流程的關鍵部分，因為它指導著整個測試活動的開展，既然被認為是項目中的一個must have，于是有人會花很多時間很多精力去把測試計劃給寫好寫完整。那么我們真的在敏捷開發(fā)模式的項目里需要一份測試計劃嗎？這真的能給項目質(zhì)量帶來價值嗎？

敏捷宣言說過：

在敏捷項目中，產(chǎn)品范圍也就是發(fā)布內(nèi)容在spring進行之前就被討論，所以QA們對于測試對象和測試范圍一直都是清楚的，不需要特別地花時間去寫一個詳細的文檔來闡述。同樣地，agile ceremony會讓QA們清楚地知道測試對象是什么，范圍是什么，重點是什么，測試環(huán)境是什么而不需要一個單獨的文檔來進行詳細的描述。甚至，所有關于測試的信息還可以被記錄被故事卡中。在開發(fā)進行編碼實現(xiàn)功能的時候，QA們會進行測試用例設計以及自動化測試編寫，因為時間的緊迫，QA除了這兩項測試活動，再去寫一個詳細測試計劃是不經(jīng)濟的且價值不大，這兩項測試活動才是敏捷項目中價值最高的，況且隨著迭代的進行，測試計劃的維護還需要時間精力。

綜上所述，在敏捷項目中因為時間緊迫和避免重復勞動，價值不高的測試計劃不是一個must have，個人甚至認為也不是一個nice to have。但是這并不是代表我們不需要"planning"，而是不是需要"document planning"，"planning"的實施發(fā)生在迭代中的各類活動。

最終我們還是需要一個“計劃”來指導迭代中的測試流程和方法，這就是測試策略是一個must have的原因。在敏捷項目中，“小而精”的測試策略比起“大而全”的測試計劃而言，最大的優(yōu)勢就是測試策略定義的內(nèi)容(“怎么測”)是不會輕易受影響改變的，并且在迭代中沒有類似的重復活動。

具體到項目里，測試策略推薦在項目剛啟動的時候制定。測試策略需要在項目早期就制定下來，用來指導項目的測試活動和方法，從而確定需要的測試資源和保證質(zhì)量體系的建立。但也不能在產(chǎn)品和技術都還沒有確定的時候就制定，因為只有在產(chǎn)品需求范圍，技術架構和交付計劃大致確認的情況，測試策略才能更加準確，從而減少維護成本。

因為測試策略會涉及到很多具體的測試技術和方法，也會要求制定人員具有對質(zhì)量和測試非常深的理解，所以QA在敏捷團隊中應該承擔制定測試策略的主要責任，但是這并不意味“只有”QA來編寫制定測試策略，測試策略的制定是一個團隊活動，QA需要從不同角色收集到不同的信息

從多方收集信息能夠保證業(yè)務、技術和質(zhì)量三者對齊，避免誤解和沖突，共同發(fā)揮最大的作用。

當測試策略制定完成以后，還需要給項目團隊進行講解，確保團隊所有相關人員對項目中的測試活動和測試方法有著一致的理解,這樣才能保證實施階段的順利。

接下來會涉及到QA制定測試策略的具體活動及流程?？偟膩碚f，大體流程可以如下

上面提到了QA可以從不同角色收集到不同的信息，除此之外，使用啟發(fā)式測試計劃語境模型 Heuristic Test Planning Context Model和啟發(fā)式測試策略模型 Heuristic Test Strategy Model也是一個有效的渠道。具體如何使用這兩個模型，請參考 htsm 和 htcpm。

通過分析 htsm 中“項目環(huán)境”和“產(chǎn)品元素”的關鍵詞和啟發(fā)式問題，QA可以了解關于產(chǎn)品和項目的各類信息來幫助制定測試策略。htcpm 也提供了大量的關鍵詞來啟發(fā)QA去分析了解產(chǎn)品需求、項目環(huán)境、測試小組和測試資源。

可以收集的信息大致可分類如下

只有從不同的維度收集到足夠的項目信息并且很好的理解這些信息對項目質(zhì)量和測試活動的影響，才能幫助我們少走彎路，制定出適合項目和團隊的測試策略。

在具體思考“怎么測”之前，我們需要確定項目的質(zhì)量目標。這個質(zhì)量目標會對齊項目所有相關人員對于項目質(zhì)量的理解和期望，明確質(zhì)量范圍也就是測試策略會覆蓋的范圍。同時，質(zhì)量目標也要與產(chǎn)品目標對齊，因為質(zhì)量的最終目的也是保證產(chǎn)品的成功。根據(jù)產(chǎn)品在不同階段都有不一樣的目標，質(zhì)量目標有會隨之變化。

那質(zhì)量目標如何設定？主要是參考軟件質(zhì)量特征列表和軟件質(zhì)量模型，建立符合項目上下文的產(chǎn)品質(zhì)量模型，從而確定項目質(zhì)量目標

要建立項目產(chǎn)品的質(zhì)量模型首先就需要先知道一個軟件產(chǎn)品的質(zhì)量屬性或特征分別有什么，對應的質(zhì)量模型是什么樣的。幸運的是現(xiàn)在已經(jīng)有很多可以參考的模型了

ISO/IEC_25010的質(zhì)量模型大致如下：

從上面的質(zhì)量特征列表或是模型可以看出，一個軟件產(chǎn)品的質(zhì)量由多個質(zhì)量特征或標準組成，每個質(zhì)量特征又可以進一步分解為子特征。通過這些已有的質(zhì)量模型來啟發(fā)哪些質(zhì)量特征是對項目產(chǎn)品重要的，哪些質(zhì)量標準適用于本項目產(chǎn)品，最后得出符合項目上下文的產(chǎn)品質(zhì)量模型。

比如 我們創(chuàng)建的產(chǎn)品質(zhì)量模型可以包含以下粗粒度特征：

上面的質(zhì)量模型定義了產(chǎn)品質(zhì)量特征和標準，而這些特征和標準就是我們應該完成的目標！除了上面說到的質(zhì)量模型，一些具體的metrics也可以被引入來保證項目質(zhì)量，成為項目質(zhì)量目標的一部分。舉個例子

上面提到的標準都是可以通過集成到持續(xù)集成流水線的質(zhì)量工具或測試框架來實現(xiàn)。

此外，還有團隊也會使用測試策略目標宣言來打造團隊文化。

有了質(zhì)量目標，接下來我們要考慮要怎么達成這個目標了！也就是說，我們應該有哪些測試類型來覆蓋每一個質(zhì)量目標？

測試類型按照不同維度可以有很多種分類，比如說

當然，上面只是列出了一部分。

此外，HTSM中的 Test Techniques 提供了九種通用的九種測試技術來啟發(fā)對可應用的測試類型的思考。敏捷測試四象限也提供了敏捷項目可以參考的測試類型,這個測試技術分類系統(tǒng)可以幫助我們快速定位某測試類型在軟件開發(fā)中的位置，根據(jù)項目產(chǎn)品情況選擇合適的測試類型。
就以我們上面假設的質(zhì)量目標為例，我們來看看可以應用哪些測試類型

值得注意的是，并不是每一個項目都需要覆蓋上面所列出的測試類型。我們應該根據(jù)產(chǎn)品的目標和特點以及其他實際情況選擇與之對應的測試覆蓋類型，也就是說，不同項目根據(jù)測試類型的不同，測試廣度是不一樣的。同事，根據(jù)測試的難點和重點，測試深度也是不同的。所以，一切都要基于項目的上下文來思考和制定。

自動化測試金字塔用來指導敏捷項目中自動化測試的策略。

根據(jù)金字塔理論，項目應該在底層的單元測試和集成測試(API測試)投入更多的精力。

自動化測試項目會被集成在持續(xù)集成流水線里面，由上游項目自動觸發(fā)。為了減少持續(xù)集成的反饋時間，一個普遍的做法是把龐大的自動化測試套件集依據(jù)重要性優(yōu)先級放在不同的流水線里面，可以被上游項目觸發(fā)也可以定時觸發(fā)，下面描述了一個比較好的實踐：

確定測試類型之后，我們就知道了整個項目的測試活動會有哪些。對于某些測試類型，特別是自動化相關的測試，我們需要對應的測試工具或是框架來支撐我們的測試。所以我們需要對每一個測試類型都去思考下如何進行測試，是否需要相應的測試工具和框架的支持。

拿一個web程序來舉例

這個環(huán)節(jié)我們需要確定在項目開發(fā)生命周期的每個階段做什么樣的測試，使得測試類型與項目的開發(fā)流程充分結合，這樣就能最大發(fā)揮所有測試活動的效果來達到我們的質(zhì)量目標。因此，我們可以做出類似下面這樣的表格來表現(xiàn)每個階段的測試類型及其實施方法。

至此，測試策略解決的兩個問題“測什么”和“怎么測”都可以找到大致答案了。

那如何衡量測試策略的有效性呢？質(zhì)量度量可以告訴我們產(chǎn)品的質(zhì)量情況和用戶滿意度，從而反應出測試策略是否有效和高效。

軟件質(zhì)量的度量沒有什么最佳實踐，也沒有最準確和科學的度量，有的只是項目上積累的成功經(jīng)驗；但是這些成功經(jīng)驗又由于項目差異化太大而變得復用性很差。所以根據(jù)項目的上下文，我們需要制定出自己的質(zhì)量度量標準。結合本文敏捷項目的背景，我們可以大致使用下面常用的度量：

同時，實例化的質(zhì)量目標也是很好的項目質(zhì)量的工具。對于質(zhì)量模型，我們可以看下每一個質(zhì)量元素我們是否做到；對于具體的指標metrics，要隨時監(jiān)控反饋。

一旦測試策略被確定，一般來講不會經(jīng)常變化，因為測試策略設置了一些測試標準。如果測試標準頻繁地變動，這會讓具體計劃的執(zhí)行變得困難，同時帶來更多的資源浪費，最終影響了項目的質(zhì)量。

在項目中我們會經(jīng)常遇到“變化”：比如說

這些變化對測試的影響是被測對象的范圍以及項目資源的調(diào)配。對于項目的質(zhì)量目標、測試類型、測試階段影響不大。所以，測試策略一旦被制定出來，變化不會太大。

不過這不代表測試策略的一成不變和缺乏改進，QA需要在每個迭代中觀察測試策略實施的效果來決定當前的測試類型和實施手段是否滿足項目需求。比如當項目集成測試(API Testing)經(jīng)常fail，且協(xié)調(diào)工作耗時費力，QA可以考慮采用契約測試來代替現(xiàn)有的集成測試，提高整個項目組的生產(chǎn)率和質(zhì)量；比如發(fā)現(xiàn)Internet Edge突然用戶量增多且有關于Internet Edge的production bug被raise，QA需要把Internet Edge加到兼容性測試中，并且設置相關的測試環(huán)境；比如測試進度落后，交付壓力增大，QA需要及時調(diào)整測試范圍和測試重點，進行風險分析。

在實際項目中，往往會出現(xiàn)各種各樣的問題來阻礙測試策略的順利落地和執(zhí)行。這些問題有些是測試策略自身的問題，但也有項目帶來的問題。這時候，風險分析顯得格外重要。

對于測試策略的風險分析，這個是應該貫穿整個測試策略制定周期里面的，我們需要通過項目風險清單提前識別項目中可能阻塞測試的風險，并通過風險優(yōu)先級(風險暴露的概率*風險暴露的損失)來評估風險，最終基于風險調(diào)整測試策略，把測試重點放到風險高優(yōu)先級高的地方。

測試策略是影響質(zhì)量的重要因素，但不是全部，下面列出了部分會影響質(zhì)量的因素作為參考，在此文中不會展開來講

上面詳細闡述了我如何理解敏捷項目中的測試策略以及制定測試策略的具體步驟。由于IT項目的多樣性和復雜性，這個總結不可能適用于有著不同上下文的項目，因地制宜地制定測試策略才能保證測試策略在項目中的可用性和合理性。

敏捷測試的指導性原則

? ? ? ? ?1） 產(chǎn)品的質(zhì)量不是測試出來的，是軟件生產(chǎn)出來就是這樣的。

? ? ? ? ? 2）但現(xiàn)實很殘酷，上線前最緊張的還是QA，我們也很無奈...
1.QA就是一個角色。

團隊中任何一個人被賦予這個角色就要承擔QA的職責，承擔QA要做的事情，eg:BA 也可以被賦予這個角色。

2.能力要求
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -----學習自《ThoughtWorks》

怎么做敏捷測試人員？

1、敏捷測試人員的定義
我們這樣定義敏捷測試人員：專業(yè)的測試人員，適應變化，與技術人員和業(yè)務人員展開良好協(xié)作，并理解利用測試記錄需求和驅(qū)動開發(fā)的思想。敏捷測試人員往往具有優(yōu)秀的技術能力，知道如何與他人合作以實現(xiàn)自動化測試，同時也擅長探索性測試。他們希望了解客戶在做什么，以此更好地理解客戶的軟件需求。
誰是敏捷測試人員？她是驅(qū)動敏捷測試的團隊成員。我們知道許多敏捷測試人員剛開始的時候在從事其他工作。開發(fā)人員可能會愛上測試而超越單元測試的范疇。習慣以敏捷方式工作的探索型測試人員也會被敏捷團隊吸引。其他角色的專業(yè)人士，比如業(yè)務或者功能分析師，也可能具有同樣的特質(zhì)并做同樣的工作。
技能很重要，但態(tài)度更值得關注。Janet總是說：“如果態(tài)度不好，那么技能則一無是處”。既然我們要為敏捷團隊招募大量的測試人員，那么必須慎重考慮這一點，并與敏捷社區(qū)的其他朋友進行相關討論。測試人員往往可以總覽全局。他們更多時候是以客戶的角度看待應用程序，這意味著他們一般以客戶為中心。
2、敏捷測試思想
如何使一個團隊變得“敏捷”？對我們而言，敏捷團隊持續(xù)關注如何最出色地工作并發(fā)布最優(yōu)秀的產(chǎn)品。根據(jù)我們的經(jīng)驗，這需要大量的訓練、學習、時間、實驗和協(xié)同工作。這并不適合所有人，但是對那些希望自己團隊充滿活力并關注持續(xù)改進的人來說非常適合。
成功的項目總是因為優(yōu)秀的人才完成了出色的工作。在敏捷團隊中做一名成功的測試人員所需要的特質(zhì)可能與在任何團隊做一名高水平的測試人員所需要的相同。
敏捷測試人員不會把自己看作是質(zhì)量管理辦公室的主管以保護客戶避免受到缺陷代碼的傷害。她會樂于收集和分享信息，與客戶或者產(chǎn)品負責人協(xié)作以幫助他們充分展示自己的需求，從而得到他們需要的功能，同時向所有人提供項目進展的反饋。

（來源：培訓啦 http://m.trustlankalog.com）文章共14190字