敏捷開發中QA的職責之敏捷中的QA

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

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

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

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

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

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

　　敏捷QA的日?；顒?/p>

　　從迭代到發布，敏捷測試的生命周期各個階段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與傳統測試人員有哪些不同：

原文轉自：http://www.infoq.com/cn/articles/agility-of-qa