互聯網產品為了快速了解，滿足用戶需求和完善用戶體驗，需要不斷迭代更新版本，不斷改進。版本迭代速度越快，再激烈的競爭中越具有優(yōu)勢。
快速迭代，效率很重要。那么我們該如何評估項目團隊工作效率是好是壞，如何找出項目團隊中效率的問題能？首先，團隊主體構成由產品，開發(fā)，測試構成。每個環(huán)節(jié)在項目迭代過程中都占據重要地位，且相互影響，相互制約。雖然我們的角色是測試，但是只在測試的范疇內去討論如何提高效率顯然過于局限。因此，放眼整個項目評估各角色工作效率對項目整體效率提升意義更大。
那么該如何評估效率呢?
我們通過總結各角色經常發(fā)生的問題，并將問題轉化成可量化的指標去度量，再分析評估指標的變化趨勢來評估團隊整體效率。
開發(fā)層面常見問題：
開發(fā)提測delay嚴重，Bug來回來去修改不對，測試要多次驗證和回歸。
開發(fā)提測質量不高，Bug特別多
開發(fā)間溝通不暢，經常出現信息不同步或信息有誤導導致重構或返工情況
開發(fā)提交代碼隨意無約束經常計劃外重構
改動比較大的模塊提測晚，一輪后期發(fā)現大量Bug
建立指標：
千行bug率
用來評估開發(fā)代碼質量，bug率越低越好
bug修改輪數及比例分布
開發(fā)修改bug輪數越多，說明開發(fā)修改代碼質量不高或缺少自測
開發(fā)重構次數
一個版本內不應該有太多的代碼重構，大的重構一般控制在一個左右，同一個版本重構過多無論是質量還是時間都無法保證。
產品層面常見問題：
需求前期考慮不充分，導致后面需變較多，重復開發(fā)測試工作量巨大
需求，交互不詳細，測試過程中大量溝通確認，耗費時間
建立指標：
1.需變工作量占比
需求變更所帶來的工作量越大，項目越不可能按照既定計劃上線
2.需變時間軸
用來描述需求變更在整個項目周期內的分布情況，正常情況需變應該集中在項目前期，隨著項目的進行，越往后需變應該越少，到最終回歸階段不應該再有需變。如果需變集中在中后期，往往上線時間會delay。
有人會說，身為測試這么關注開發(fā)產品的問題干啥，你也改變不了。我想說首先大家是一個項目團隊，每個人都有義務指出配合團隊的問題，其次，團隊之間是相互影響的，只有上游團隊變好了，某些測試工作才能變輕松。在指出對方問題時如果帶著具體的實例，具體的數據，才能有說服力，對方才能夠信服和接受。
測試層面常見：
用例設計花費時間多，或者評審返工多
用例設計遺漏，后期發(fā)現導致重復回歸，延長上線時間
測試方法不足，部分Case執(zhí)行耗時較多，例如場景構造，異常數據構造
工具應用比較少，手工測試比重大。測試時間變長
不可重現的Bug，導致花費大量時間重試或驗證
二輪測試執(zhí)行時間比較長
測試范圍評估不準，臨近上線回歸發(fā)現bug，需要延長測試時間。
對需求理解有誤，報了部分無效bug，對開發(fā)和測試時間造成浪
人員能力和經驗不足，用例執(zhí)行速度偏慢
建立指標：
每人用例設計時間及條數
用來評估測試人員用例設計方面的效率
用例設計評審及返工用時和占比
用例評審及返工時間越多，說明用例設計方法或對功能了解存在問題
測試各階段時間占比
用例執(zhí)行時間或回歸執(zhí)行時間的比例應該越少越好，比例越大說明在測試方法和 手段存在問題
不可重現Bug比例
不可重現的bug比例不應該太高，測試人員需要在如何重現問題及找到重現方面下功夫
Bug驗證工時占比
bug驗證時間多可能是bug過多或者驗證手段不足，效率低下
發(fā)現晚的Bug占比
應該盡可能的降低這個比例，并逐個問題分析原因找到解決方案。
至此我們定義了各團隊效率問題層面的指標，我們可以通過不同的迭代版本持續(xù)統(tǒng)計持續(xù)觀察，相應的問題解決后通過指標的變化來驗證效率是否提升。
(本文于2016-04-22首次發(fā)布)
