QA，通常指的是質量保證(Quality Assurance)工程師，但我更喜歡定義敏捷中的QA為質量分析師(Quality Analyst)，主要基於以下幾個方面的原因：

　　質量保證更偏向於工業說法，稱參與軟體測試的人員為質量分析師感覺更恰當;

　　質量保證師更多的還是把測試當作軟體質量的最後把關著、看門人，而敏捷中的QA更多的是建議提供者而非看門人，把QA稱為質量分析師更能體現敏捷中團隊對質量負責的原則;

　　質量分析師更重視業務價值，關注業務價值的分析。

　　QA，質量分析師，顯然與測試有關。敏捷中的QA，也就是與敏捷測試有關。敏捷測試就是在敏捷開發模式下對軟體進行的測試，要求儘早測試、頻繁測試，以及時提供反饋。敏捷測試要求團隊對軟體產品的質量負責，而不是某個帶有QA頭銜的特殊人員。敏捷中的QA可以是參與敏捷測試的所有團隊人員，而並不一定是特定的專職的測試人員

　　這聽起來是不是有點特別?跟傳統開發模式下的測試人員是不是有些不一樣?別急，我們先來看看敏捷中的QA是如何進行日常工作的。

　　敏捷QA的日常活動

　　從迭代到釋出，敏捷測試的生命週期各個階段QA的活動主要有：測試分析，測試自動化策略分析、框架構建等，故事測試，迭代計劃會議和客戶演示，測試自動化的維護和執行等。如下圖示：

　　QA通常不是僅僅工作在某個迭代，而是並行的同時工作在多個迭代：要對當前迭代的故事進行驗收測試、探索性測試，和開發人員結對實現測試自動化;還要和業務人員結對分析下一個迭代的故事，編寫驗收標準和測試用例。

　　在單個迭代內部，伴隨著故事生命週期，QA的活動有哪些呢?使用者故事生命週期包括以下幾個階段：故事分析、故事計劃、故事開發、故事驗收、故事測試/探索性測試、系統測試

　　故事分析階段：需求澄清，業務場景和驗收測試的確認

　　故事計劃階段：拆分測試任務，在每個故事開發估算基礎上考慮測試的時間和估算

　　故事開發階段：和開發人員結對實現自動化測試，和團隊溝通發現的問題和缺陷

　　故事驗收階段：開發人員開發完故事後，QA和業務分析人員要在開發機器上進行驗收，以提供快速的反饋;同時還要對測試覆蓋率(單元測試、元件整合測試、功能測試)進行確認和提出反饋

　　故事測試/探索性測試階段：執行自動化驗收測試，執行探索性測試，強調會阻礙故事發布的因素，和團隊就測試覆蓋率進行溝通，為發現的缺陷新增自動化測試

　　系統測試和客戶演示階段：執行端到端的系統測試，執行業務或整合的使用者測試場景，和團隊及客戶就功能特性的質量和穩定性進行溝通，參與給客戶演示功能和特性

　　正如前面提到的，在每個階段，QA除了要獨立進行測試，通常還需要跟不同的角色結對，包括業務分析人員、開發人員、以及客戶。

　　QA與業務分析人員結對：通常在業務分析師分析使用者故事的時候，QA要與業務分析人員結對編寫驗收標準。通過與業務分析人員結對，QA能夠更好的理解領域知識，從而有利於定義合適的測試用例;QA從測試角度新增的驗收測試用例可以幫助整個團隊對產品功能性有更好的理解。

　　QA與開發人員結對：QA和開發人員分別能給團隊帶來不同的技能集，認識到這一點很重要。作為一個團隊，最好通過平衡不同的技能集來獲得共同的目標。這對於傳統的瀑布式團隊來說是一個很重要的心態改變。通常在實現測試自動化的時候，QA與開發人員結對是比較理想的方式。這樣結對實現的自動化測試質量相對較高，有測試意識較強的QA參與能夠保證自動化測試測得是真正需要測試的部分，而開發人員的編碼能力有利於寫出簡潔可維護的自動化測試程式碼。另一方面，QA通過與開發人員結對，編碼能力也會相應有所提高，而開發人員通過與QA結對，測試意識也會增強，更有利於編寫質量較高的產品程式碼，更有利於形成全功能團隊。

　　QA與客戶結對：客戶是業務領域專家，通過與客戶結對，QA能夠更好的從終端使用者的角度理解系統，從而定義或者增加更多的端到端的測試用例;一旦QA理解了領域知識和終端使用者的觀點，其業務價值分析能力會有所提高，在團隊需要的時候可以承擔業務分析角色;在使用者驗收測試(UAT)階段，QA通過與客戶結對，幫助客戶熟悉使用系統，在必要時可以幫助客戶解決一些系統問題。

　　敏捷QA的這些日常活動，的確反映出敏捷QA的日常工作內容和方式都跟傳統開發模式下的測試人員有很多不同。下面為大家來詳細介紹一下兩者的不同，以及敏捷測試對QA的要求有哪些。

　　敏捷QA與傳統測試人員有何不同

　　我們分別從團隊構成、測試階段、工作方式、關注點、業務知識來源以及釋出計劃制定幾個方面，來看看敏捷QA與傳統測試人員有哪些不同：

從上表的對比可以看到，敏捷QA是特殊的，主要體現在：

　　敏捷QA是提出建議者而非看門人，需要在參與的每個階段提出自己的建議，而不是等到開發流程最後來對系統進行驗證;不僅要驗證開發設計是否滿足需求，還要發現需求是否能真正體現業務價值，分析是否有不恰當或缺失的需求。比如說，敏捷QA在跟業務人員結對編寫驗收標準的時候發現故事分析過程中漏掉的需求，在跟開發人員結對過程中跟開發人員討論某個測試放在哪層實現比較合理等。

　　發現風險，並將風險與團隊及客戶溝通。QA參與整個開發流程，對系統整體的認識和把握可以說是團隊裡邊最全面的，因此也更容易看到系統存在的風險。

　　及時向團隊提供關於產品質量的反饋，便於調整。在每個迭代結束時候，QA需要分析統計該迭代的缺陷，並結合自己通過測試對系統質量的瞭解，及時跟團隊反饋，討論分析質量下降的原因以儘快作出改進，或總結質量上升的經驗，鼓勵團隊再接再厲。

　　在制定產品和版本的釋出計劃的時候，QA可以根據自己對產品質量的瞭解，從測試人員獨有的視角提出一些關鍵的建議。

　　QA通過參與開發流程的每個階段，能夠協助團隊從內部提升質量，讓質量融入到產品開發中來。比如：在故事驗收階段對測試覆蓋率的確認。

　　這些特殊性對敏捷QA也提出了更高的要求，需要做到：

　　具有豐富的產品知識和對使用者業務目標的準確瞭解

　　對不同系統和資料庫所用到的技術知識的瞭解

　　和不同角色以及客戶進行有效溝通

　　主動驗證質量目標並及時說出自己的想法

　　編寫測試計劃，列出需要執行的活動並進行估算

　　自動化測試的能力和對測試工具的基本瞭解

　　在團隊內部進行知識分享，協助整個團隊參與到測試活動中來

　　持續提供並獲取反饋