測試人員在敏捷團隊中扮演的角色

對於開發模式，如今大部分互聯網公司都完成了從傳統瀑布開發模式到敏捷開發模式的轉型，這種轉型相對傳統的測試人員來講，不管是在角色定位仍是在技能棧方面都提出了更大的挑戰，那麼測試人員應該如何應對呢？下面根據我平時工做的一些總結體會來講說測試人員應該發力的方向，供你們參考：

角色 1： 培訓人員

　　在轉型初期，測試人員應該針對開發人員的薄弱環節（即業務技能）進行培訓和指導。因爲工做任務的差異，開發人員對負責的模塊業務和具體實現細節很是瞭解，可是對周邊模塊或者業務並非很是清楚，主要體如今配置和使用方面。而這部分偏偏是測試人員有經驗的地方，這個時候須要測試人員儘量多的開展一些培訓和分享工做，使團隊儘量快速的彌補不足，在以後用戶故事的開發過程當中對業務有一個更好的把控。培訓開展的幾個步驟以下：

1. 收集團隊反饋，找出業務薄弱點，列出topic
2. 針對不一樣的topic分階段（sprint）的開展培訓和分享
3. 保留培訓資料以便之後查詢（文檔、視頻等等）

角色 2：測試規劃師　　

　　對於測試規劃師，我認爲主要的職能是規劃如何高效（時間、資源、質量）的推動用戶故事測試的開展。要作到這一點真的很不容易，須要從兩方面來考慮：

• 平衡測試和開發工做量

　　在敏捷團隊中測試人員和開發人員的比例懸殊的狀況下（主要是開發人員多，至少如今我還沒見過測試比開發多的團隊^_^），對於工做量來講，測試人員不可能匹配開發的速度，這時就須要開發人員給予必定的幫助，開展的幾個步驟：

1. 1. 測試人員針對用戶故事建立測試策略（測試用例、環境配置等）
   2. 相關人員評審（包括測試、PO、負責用戶故事的開發人員以及另一位將要負責測試的開發人員）
   3. 評審人員對測試策略達成一致
   4. 用戶故事開發人員編寫代碼，完成之後按照測試策略執行集成測試
   5. 代碼CheckIn以後，負責測試的開發人員按照測試策略執行最終測試
   6. 若有必要測試人員在進行簡單的功能驗證（探索性測試）

步驟比較簡單，可是操做起來並不容易，首先須要對測試人員進行簡單的測試理論培訓，包括一些測試方法，測試思想等（不可能單靠培訓有很大的提高，須要在測試中慢慢積累），而後就是開發人員是否是願意作測試工做，我想這也是轉型中遇到的一個很大的問題，不過還好，咱們團隊的開發都很nice，有些同窗還會主動要求作一些測試工做，這是出乎我意料的。這裏我仍是要說一下，開發人員作一些測試實際上是有不少好處的，主要體如今代碼質量意識、業務理解能力和我的技能棧的提高等。固然，仍是有些小夥伴們不肯意作測試的任務，那就沒辦法了，反正會作測試的開發廣泛變美變帥了~

那麼問題來了，測試人員是否是一直要負責爲用戶故事建立測試策略呢？固然不是，當開發人員對測試有進一步的瞭解以後，能夠嘗試着讓開發建立測試策略，測試人員負責評審，等到測試人員提不出來太多的改動的時候，測試人員就能夠失業了。

• 儘量多的開展結對測試

結對測試就是由兩個團隊成員共同測試同一個功能。這樣作的目的有兩個：

1. 儘量從多視角來測試功能
2. 培訓指導（主要是針對開發人員的一些測試理論和技能）　　　　

• 適當的時機開展探索性測試

　　這個階段是相對進階一些的測試方式，主要是在開發人員具有了必定的測試方法和思想以後開展的。執行探索性測試的時機是在每完成一個重要功能以後，組織多名開發和測試人員針對一條功能主線進行探索，尋求發現儘量多的潛在問題。

角色 3：產品經理

這裏寫產品經理，不是說讓測試人員去作產品經理，而是說從一個測試人員或者客戶的角度來分析用戶痛點，而且提出相應的用戶故事。這一點測試人員仍是有優點的，畢竟每一個測試人員都是產品的資深用戶。

角色 4：工具開發人員

爲了提升測試效率，工具開發是很重要的一項。工具不必定是一個龐大的系統，它能夠是一個SQL腳本、批處理文件或者是功能簡單的執行文件，只要能提升測試效率的均可以嘗試去作。

角色 5：自動化工程師

　　自動化測試在測試過程當中是重要的一環，不只能夠節省人力，時間並且能夠極大的提升測試效率。這裏主要指的是端到端的自動化測試，由於單元測試和集成測試的自動化腳本由相應的開發人員負責編寫。這時通常須要作的工做是：

1. 針對項目評估相應的測試框架和工具，找出適合的
2. 和開發討論搭建測試框架
3. 在迭代中，爲相應的用戶故事用例添加相應的腳本
4. 按期執行

角色 6：全棧工程師

　　這個就很少說了，由於距離遠着呢……

 

小結：

其實各個角色之間是沒有衝突的，並且是能夠根據敏捷團隊所處的階段有所側重點的。固然目的只有一個，提升效率，保持競爭力。

 

keep growing……