我在前面的文章《聊聊我對質量度量的看法》中曾談到線上缺陷逃逸率的話題。
前幾天技術羣有同學問我該如何理解線上缺陷逃逸率，羣裏有位同學是這麼如何的：
“缺陷逃逸率，Defect Escape Percentage，簡稱DEP，是指軟件產品發佈後發現的缺陷數量與該軟件產品在整個生命週期發現的所有缺陷數量的比率”。
在TMMi體系中，缺陷逃逸率是用來評估交付質量的衡量指標，如果該值低於某個閾值，則可以判斷交付質量的好壞。
我在之前的工作中曾經參與過一段時間的企業TMMi改進，這篇文章，我會結合關於TMMi的一些技術筆記，來談談質量度量和過程改進的一些話題。
什麼是TMMi？
- 定義：TMMi即Test Maturity Model Integration(測試成熟度模型集成)。
- 來源：由TMMi基金會開發的一個非商業化的、獨立於組織的測試成熟度評估模型。
- 目的：推動組織使測試過程從臨時的和未管理的狀態進化爲已管理、已定義、已測量和優化的狀態。
- 標準：TMMi是與國際標準相一致的、由業務/目標驅動的測試過程改進詳細模型，是一個過程改進的階段型架構。
- 分級：TMMi分爲5個級別，規定了成熟度級別和測試過程改進路徑。每個級別都有一組過程域，組織需要實施這些過程域來達到對應的成熟度級別。
- TMMi1級—初始
- TMMi2級—已管理
- TMMi3級—已定義
- TMMi4級—已測量
- TMMi5級—優化
什麼階段需要TMMi？
TMMi是一種測試成熟度評估模型，也是一個測試過程改進的參考階段性架構。
因此評估是否需要TMMi來推動質量度量和過程改進，需要先對企業或團隊當前的測試現狀進行梳理評估。
結合我參與TMMi落地改進的經驗和筆記，一般來說當具有如下幾個特徵的情況下，可以進行TMMi落地改進。
- 軟件產品風險無法識別或識別度不高（風險識別）；
- 測試環境未形成統一規範，管理和維護成本高（環境穩定）；
- 測試生命週期活動沒有明確的定義和裁剪規則（准入準出規則）；
- 現有測試體系過重或不適配團隊，產品交付質量不高（測試體系效率）；
- 質量度量不清晰，無法很好的評估需求/過程/交付質量（質量度量和改進）；
上述幾條現狀，是影響我們日常工作順利開展的元兇，也是大家吐槽測試背鍋的原因。
當然，在項目啓動階段，一定要注意如下幾個事項：
- 獲得高層支持（確保足夠的資源投入）；
- 設定清晰、可度量、可實現的目標（質量度量和改進本身就是成本）；
- 成立正式&專門的改進小組（確保人的投入、權利到位和明確的責任）；
TMMi如何落地實施？
確定要進行TMMi改進後，就可以項目立項進行實施了。一般來說TMMi落地可以分爲如下幾個階段：
- 項目立項啓動；
- 組建專門的TMMi過程改進團隊；
- 制定TMMi過程改進計劃並評審通過；
- 項目實施（參照TMMi的分級標準和當前所處階段）；
- 項目試點驗證（挑選試點項目，小範圍接入驗證，評估效果）；
- 根據試點驗證結果不斷改進評估（不斷擴大驗證範圍，不斷評估）；
- TMMi正式評估，得到認證（需要專門的外部機構或基金會認證，發放證書）；
在項目落地實施過程中，要注意如下幾點：
- 制定計劃要明確不同階段和里程碑；
- 每個階段目標清晰，目標一定要可度量可實現；
- 需要有專門的人員和流程&工具來協助監控&控制改進過程；
- 流程要清晰，術語要統一且做好宣講，保證各團隊達成共識；
- 改進過程和進度需要展示出來，並且要收集各團隊的有效反饋；
從哪些角度度量質量？
需求設計質量
我們談軟件質量，不可避免要從它的源頭說起，而源頭就是需求和設計階段要做的事情。
這個階段包括原型圖、PRD文檔、交互設計、技術方案、測試用例等幾項重要產出物，當然他們有一定的前後依賴關係。
在需求設計階段，我個人認爲比較重要的有如下幾點指標：
- 需求評審通過率（是否有遺漏、描述不清、存在邏輯漏洞等）；
- 設計評審通過率（設計是否滿足需求要求、是否合理美觀友好）；
- 方案評審通過率（方案實現難易程度、可測性、是否需要更多資源）；
- 用例評審通過率（場景是否儘可能覆蓋、和技術方案實現是否吻合）；
爲什麼要做大量的評審工作呢？因爲在這個階段做風險評估和控制，是投入產出最高的。
評審的價值在於從用戶使用場景角度出發，通過評審提問，把需求逐步澄清並形成驗收條件，產、研、測三方共同確認，形成共識，以保證大家對需求的認知不發生偏差，爲後續團隊正確的做事提供有價值的指導。
研發過程質量
測試的本質是驗證研發交付的產出物是否達到需求設計及預期的標準。並不能直接帶來質量的提升，只能通過種種手段多維度的去驗證是否達標，並通過流程規範、度量標準等去保障最終的交付物達標。
我們常說的各種測試技術手段，都是驗證和保障交付質量的手段，而不是構建質量的手段。在研發過程階段，我個人認爲比較重要的有如下幾點指標：
- 提測準時率（便於評估進度、資源投入和風險）；
- 構建成功率（構建成功率很大程度能反映出研發提測質量。如果經常編譯構建失敗或自動化測試通過率較低，因爲這意味着最基本的需求實現出了問題）；
- 缺陷收斂率（反映缺陷在研發過程階段的變化趨勢和缺陷修復的時效性問題。一般在測試階段的中前期即單測&集成測試階段會暴露大量缺陷，到系統測試和迴歸階段缺陷就應該有明顯下降和收斂，降低產品驗收和交付風險）；
- 缺陷reopen率（問題修復可能會帶來新的問題，reopen指標可以從一定程度上評估缺陷修復的質量。如果reopen率比較高，那麼很可能研發側出現了問題，需要引起重視和尋找原因，儘快解決）；
當然，上述的度量角度有一些基礎的前提，比如：開發&測試環境的穩定性、測試流程和體系是否標準和高效，是否有較好的工具支撐度量過程。
用戶使用質量
用戶使用質量，指的是軟件線上發佈後，我們對用戶使用過程進行追蹤並採集數據進行評估度量的過程。
常見的度量指標有：
- 線上缺陷逃逸率（線上發現的缺陷）；
- 線上問題留存率（線上發現的缺陷留存時長，可以用來評估修復的時效和對線上質量的重視程度）；
- 用戶反饋建議量（這裏僅針對的是用戶針對功能的反饋或者客訴，不包含業務活動的範圍）；
最後，所有的質量度量和改進措施，在實際應用實踐中應該“量力而爲”，因爲質量本身就是有成本的。應該在有限的資源條件下提高質量，這也是質量保障和改進應該追求的目標。