敏捷軟件開發中的QA(2)

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

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

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

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

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

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

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

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

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

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

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

　　具有豐富的產品知識和對用戶業務目標的準確了解

　　對不同系統和數據庫所用到的技術知識的了解

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

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

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

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

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

　　持續提供并獲取反饋

原文轉自：http://www.uml.org.cn/Test/201302262.asp