【測試員必備】敏捷下的質量保證實踐

對於目前的開發架構來說，一個用戶故事，涉及這四個點，可以從這四個點入手來進行質量保證。

如何做呢？單元測試就開發人員處理了；代碼審查，測試人員可以參與和監督，其實就是要保證：將開發任務與提交到Git的代碼進行關聯。

這樣一來，當測試人員檢查開發任務的時候，就可以找到改變過的代碼。我曾經試過從這些代碼裡面查看邏輯，找到分支場景，補充到測試用例裡面。

Scrum中測試人員價值應當體現在：

預防缺陷的手段，提高洞察力，增強業務知識。

缺陷在需求、開發前期就已經存在了，關鍵是用什麼手段去挖掘出來預防。在sprint前獲取到的需求，測試人員可以站在客戶角度上來闡述自己的觀點，與開發人員進行充分交流和討論，使自己在用戶體驗、業務邏輯等等方面的經驗充分體現出來。

在開發過程中，測試人員除了站在客戶的角度進行測試，還應當提供更全面的質量反饋，包括代碼質量的檢查，這個可以通過redmine與git雙向關聯來做檢查依據。

目前整個過程測試人員尚未參與代碼編寫，應當參與並推進代碼評審，將代碼問題及時反饋出來；

並且參與或者推進單元測試，檢查單元測試狀態（確保單元測試達到80%以上覆蓋率，幫助開發人員開發出具有良好可測試性的代碼），自始至終將質量問題及時反饋出來，保證在sprint的整個過程中質量受到足夠的關注，提高質量改進的持續性和可視性。

隨著版本任務的增加，每個版本回歸測試的成本增加，可以適當考慮部分穩定功能進行自動化測試。當然，這是遠景。

持續改進、反饋，充分發揮每個版本統計報告的作用，對缺陷進行分析，總結出一些規律，幫助開發人員建立良好的習慣，改進代碼的質量。

敏捷中的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也提出了更高的要求，需要做到：

• 具有豐富的產品知識和對用戶業務目標的準確了解
• 對不同系統和資料庫所用到的技術知識的了解
• 和不同角色以及客戶進行有效溝通
• 主動驗證質量目標並及時說出自己的想法
• 編寫測試計劃，列出需要執行的活動並進行估算
• 自動化測試的能力和對測試工具的基本了解
• 在團隊內部進行知識分享，協助整個團隊參與到測試活動中來
• 持續提供並獲取反饋

推薦閱讀：