從缺陷率到質效工作的本質

來源：圓小豆的美夢工場

作者：於曉南

討論來自一個社群朋友。

一、缺陷率迷思

1.1 千行程式碼缺陷率被廢棄

千行程式碼缺陷率 = Bug數量 / 千行程式碼數

這是一個經典指標，以前在研發側經常用來衡量程式碼質量，近年被逐漸棄用。

原因是這個指標有負面的引導，似乎不鼓勵寫高質量的簡潔程式碼，而稀釋程式碼或造輪子則能帶來比較好看的資料，這與指標設定的初衷“提升程式碼質量”相悖。

因此，該指標不建議橫向比較，不建議作為績效指標。但可以作為程式碼質量指導基線，或作為工程師的自我修養，用於自我評估和改進。

附上在CMMI裡對千行程式碼缺陷率的標準，不難看出缺陷率還是以一個滿足該等級的基線值存在的，也就是說它不能用來衡量程式碼質量有多好，但可以用來衡量程式碼質量最差不能低於什麼水平。

1.2 缺陷率無法體現軟體質量

缺陷率 = 失敗的用例數 / 執行的用例總數

從字面意義上理解，這個指標看著像是衡量軟體質量的。但放入研發體系內思考，通常在不同版本間，執行的用例總數是變化的，失敗的用例數也取決於用例執行者的判斷，而失敗的用例又不一定會以缺陷的形式來跟蹤。所以這個指標很難有確定的標準，那麼它還是有意義的嗎？

我認為是有意義的，意義在於它揭示了測試設計的質量，即經過設計的測試用例能否有效發現缺陷。從這個維度上講，這個指標恐怕叫“用例有效率”更恰當一點。

不管是千行程式碼缺陷率，還是測試統計的缺陷率，統計時難免會陷入資料的迷思。片面追求資料好看，對團隊的副作用很大，結果可能是既不經濟、也沒成效，平白做了很多無用功。思考質效工作如何經濟又高效，有助於避開區域性最佳化的泥沼。

二、質效管理投資回報

2.1 不是指標的鍋，而是思路偏差

由上面的討論容易得出以下結論：

• 第一，從度量引導團隊改進的意義角度來看：指標數量絕對值 < 指標的環比（無任何時間間隔，連續週期內的變化），應更多關注團隊指標的變化趨勢，以及思考是什麼原因引起的變化，該如何改進；
• 第二，團隊內的任何投資，都需要考慮投入產出比 ROI，為了得到結果而付出巨大的代價，本身就是一種失效。尤其當資源被投入到“質效提升或管理”這類成本高見效慢的活動時，考慮是否經濟尤為重要。

2.2 質效管理效率金字塔

為了獲得更高的投資回報，不得不思考團隊可能採取的投資和收益之間的關係，以及可能的影響因素：成本、反饋週期、效率等互相制約的程度。

（質效管理效率金字塔）

在軟體研發活動中，有些事屬於決定做什麼和怎麼做的定義範疇，如需求方案、技術架構、測試策略等；而有些事情屬於落地實施範疇，如：工序拆解和研發、測試和運維。

當決定做研發治理時，在不同層次發力，所需成本、見效週期/觀察期、治理效果也不盡相同。

• 在定義階段發力，成本低、見效期長，但治理效果最好，問題根因也往往會追溯到此；
• 在實施階段發力，成本高、見效期短，但治理效率偏低，資料好看但治標不治本。

因此，當我們追求不同的提升或治理目標時，所採取的策略也不盡相同。

假設團隊處在新組建期，軟體也處在MVP或0-1階段，此時從底層思考比較好，在做前把問題定義清楚，架構和策略都想清楚，定義好後續實施階段的各種門禁和標準，會為後續研發過程的順利進行打造良好的基礎。

假設團隊較大，處於穩定期，軟體也處在增強和維護期，軟體的質量反饋出團隊的潛在問題較多，此時比較短平快的方式是先抓實施層面，讓團隊快速看到效果，從而建立信心。

透過實施層面反饋的問題，進一步根因分析，可能會發現在定義階段需要進行測試策略的重塑。在團隊調整的接受度和靈活性都較好時，再進行底層的改造，持續的觀察和改進，就比較容易看到效果。

三、質效工作本質是打造高效高響應系統

3.1 系統是有機整體

系統是若干部分相互聯絡、相互作用，形成的具有某些功能的整體。系統動力學認為系統中的因、果回饋關係環環相扣，系統結構決定系統功能。舉個例子，“三體”即為一個系統，在這個系統中，三個天體間的萬有引力相互影響，相互制約，對外呈現一個動態系統。

在系統思考中，是以開了掛的全域性眼光審視整個系統，而不僅僅是尋求區域性最優解。雪崩時，沒有一片雪花是無辜的，也沒有一片雪花能夠倖免。系統整體功能不好，牽涉其中的每個人都是受害者，也都是加害者。

因此在討論系統時，我們既要研究系統中的各個組成元素，又要各元素之間相互影響的關係。

3.2 系統思考看待系統問題

為了更好地說明質效工作需要系統的看待問題，我們舉一個常見的例子。在質量領域，有一個老生常談的問題：自動化測試的投入產出比。由此衍生更多的問題：自動化測試難開展、難維護、難持續。以往在看待這個問題時，可能的思路是：測試人員的自動化能力較低，或者時間緊任務急沒資源。

在採用系統思考看待這個問題時，就不會只是盯著測試人員做改進，而是思考整個研發系統在自動化測試上的瓶頸所在，追求的也是整個研發系統在自動化測試上面的投資回報率。

現在來推演一下，當要做決策時，我們追求高投資回報。而投資回報取決於成本和收益，成本越高投資回報率越低。那麼，都有哪些因素影響自動化測試的成本呢？ 

影響自動化測試成本的因素：

• 軟體本身的可測性：當軟體可測性較低時，自動化成本就會飛昇，甚至根本不具備可自動化的條件。而這個因素的可控性受制於軟體的架構設計，在軟體成熟期不具備可改進的靈活性。因此建議在做架構設計時就充分考慮軟體可測性，否則後續的自動化測試會難以開展。
• 人員能力：這裡不僅僅指自動化測試的編碼能力，更要求測試人員具備一定的測試設計能力。能夠充分理解測試分層，不同層的測試服務於什麼目標，解決什麼問題，以及測試的框架選型等能力。
• 資源配置：指團隊的研發節奏，能否有餘力進行充分的自動化測試。
• 環境依賴：自動化測試如果不能持續執行，就會失去儘早暴露缺陷的時機，而持續執行依賴於能排除干擾的穩定環境。
• 工具鏈割裂：指團隊的工具鏈體系是否支援自動化測試持續整合，或者不同層級的自動化測試工具是否具備一致性。這在一定程度上影響自動化測試的可維護性。

3.3 質效工作的本質

基於以上的討論，當思考如何提升自動化測試投資回報率時，我們就有了更多可能的改進方向。抽象一下，當思考質效工作本身時，我們需要打造的是一個高效高響應的系統。系統中包含各種元素：干係人、策略、實踐、流程、資源、工具……各個元素之間又相互影響，相互制約。當需要作出決策時，充分分析系統中的各元素及其之間的關係，有助於我們得出全域性最佳化方案。

下圖為系統中涉及的元素集合：

接下來選取觀察元素，思考相互關係，有機的組建一個系統。一個典型的系統思考應用就是冰玉老師的《一頁紙測試策略》，如圖：

基於這樣一個決策系統，我們就很容易對齊質量領域下的預期和優先順序，從而更好的促使團隊進行改進。

而幫助團隊設計和實施一個高效的、高響應力的質效系統，正是質效管理者的價值體現。