說到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能夠更好的從終端用戶的角度理解系統，從而定義或者增加更多的端到端的測試用例；一旦QA理解了領域知識和終端用戶的觀點，其業務價值分析能力會有所提高，在團隊需要的時候可以承擔業務分析角色；在用戶驗收測試（UAT）階段，QA通過與客戶結對，幫助客戶熟悉使用系統，在必要時可以幫助客戶解決一些系統問題。
敏捷QA與傳統測試人員有何不同
前面介紹的敏捷QA日常活動，就能反映出敏捷QA的日常工作內容和方式都跟傳統開發模式下的測試人員有很多不同。下面為大家來詳細介紹一下兩者的不同，以及敏捷測試對QA的要求有哪些。
敏捷開發與傳統開發模式的對比
傳統開發模式一般要經歷分析、設計、編碼與測試這四個主要階段，每個階段相對獨立，測試是發布前集中的較長時間完成的事情，最后交付大塊的功能。敏捷開發是將業務需求拆分成更小的用戶故事，采用迭代式增量開發方式，由不同角色組成全功能團隊，把原來的每個階段的事情揉到每個用戶故事生命周期里，測試不再是獨立的階段。
敏捷QA與傳統測試人員的對比
鑒于敏捷開發模式與傳統模式的顯著區別，敏捷QA與傳統測試人員的工作方式和工作內容上也有很大的不同。下表分別從團隊構成、測試階段、工作方式、關注點、業務知識來源以及發布計劃制定幾個方面進行對比：
| 傳統測試人員 | 敏捷QA |
|---|---|
| 單獨的測試團隊 | 多角色開發團隊中的一員 |
| 在開發流程后期才開始測試 | 測試貫穿于整個開發流程中 |
| 通常是獨立地工作 | QA和不同角色進行結對 |
| 被當做最后也是唯一的質量保障 | 關注并強調風險 |
| 缺乏與業務人員的直接溝通 | 和業務人員直接溝通 |
| 沒有機會參與發布計劃制定 | 參與發布計劃的制定 |
團隊構成
傳統模式下測試團隊通常屬于獨立的部門，相應的開發也有自己獨立的部門，兩者交互較少。敏捷開發提倡多個不同角色（包括項目經理、需求分析人員、開發人員、架構師、QA等）組成開發團隊，QA屬于開發團隊中的一員。
測試階段
傳統模式下通常是開發部門完成整塊功能的開發再移交給測試部門集中進行測試，測試是處于上線發布前非常重要的一個獨立階段。敏捷模式提倡盡早測試、持續測試，測試從需求階段就開始介入，一直延伸到上線，貫穿于整個開發生命周期，不再是上線前的獨立階段。
工作方式
傳統模式下，測試人員根據需求規范文檔獨立完成測試階段的測試工作，跟別的角色溝通較少。敏捷模式下，測試人員跟其他角色一樣屬于開發團隊，在工作中會跟不同角色進行結對，在多個環節跟不同角色有大量的溝通和確認。
關注點
傳統模式下的測試人員在上線前對質量把關，被當做質量看門人，是最后唯一的質量保障。而敏捷強調團隊全員對質量負責，QA不再是質量把關者，而是作為質量分析師，更多地關注并強調質量風險，協調團隊交付高質量的軟件。
業務知識來源
傳統模式下開發和測試都是基于業務需求規范文檔來開展工作，業務知識基本都來自這份需求規范，較少與業務人員的直接溝通。敏捷模式下，測試從需求階段就開始介入，會跟業務人員結對或者通過評審需求的方式直接參與需求分析，盡早獲取足夠的業務知識。
發布計劃制定
傳統模式角色之間的職責劃分比較清晰，測試一般都是后期測試階段才能介入，沒有機會參與發布計劃的制定。敏捷開發強調團隊成員的合作，測試從團隊組建初期就會加入，可以參與發布計劃制定，根據對系統的了解以及業務的理解，對發布計劃可能需要考慮的因素提供測試視角獨特的輸入。
敏捷QA不再是質量把關者
從上表的對比可以看到，敏捷QA是特殊的，主要體現在：
- 敏捷QA是提出建議者而非看門人，需要在參與的每個階段提出自己的建議，而不是等到開發流程最后來對系統進行驗證；不僅要驗證開發設計是否滿足需求，還要發現需求是否能真正體現業務價值，分析是否有不恰當或缺失的需求。比如說，敏捷QA在跟業務人員結對編寫驗收標準的時候發現故事分析過程中漏掉的需求，在跟開發人員結對過程中跟開發人員討論某個測試放在哪層實現比較合理等。
- 發現風險，并將風險與團隊及客戶溝通。QA參與整個開發流程，對系統整體的認識和把握可以說是團隊里邊最全面的，因此也更容易看到系統存在的風險。
- 及時向團隊提供關于產品質量的反饋，便于調整。在每個迭代結束時候，QA需要分析統計該迭代的缺陷，并結合自己通過測試對系統質量的了解，及時跟團隊反饋，討論分析質量下降的原因以盡快作出改進，或總結質量上升的經驗，鼓勵團隊再接再厲。
- 在制定產品和版本的發布計劃的時候，QA可以根據自己對產品質量的了解，從測試人員獨有的視角提出一些關鍵的建議。
- QA通過參與開發流程的每個階段，能夠協助團隊從內部提升質量，讓質量融入到產品開發中來。比如：在故事驗收階段對測試覆蓋率的確認。
這些特殊性對敏捷QA也提出了更高的要求，需要做到：
- 具有豐富的產品知識和對用戶業務目標的準確了解
- 對不同系統和數據庫所用到的技術知識的了解
- 和不同角色以及客戶進行有效溝通
- 主動驗證質量目標并及時說出自己的想法
- 編寫測試計劃，列出需要執行的活動并進行估算
-自動化測試的能力和對測試工具的基本了解 - 在團隊內部進行知識分享，協助整個團隊參與到測試活動中來
- 持續提供并獲取反饋
