討論來自一個社區(qū)朋友。
小A：“曉南老師，我?guī)е鴨栴}來了。通常測試報告中【缺陷率】這個指標，我們有沒有參考的指標，比如某個模塊缺陷率為多少合適，還是說這個模塊跟以往的build進行環(huán)比呢？”
曉南：“橫向對比指標絕對值沒啥太大意義，變化趨勢比較有意義，所以推薦跟這個模塊歷史數(shù)據(jù)對比。因為不同模塊業(yè)務不同，復雜度也不同。”
小A：“也就是說，第一個版本的缺陷率拿出來，跟其他項目進行比較的結果沒有實際的參考意義；我也更加認同看趨勢，做環(huán)比。”
曉南：“是的，環(huán)比更有意義，橫向對比基本沒啥意義?；蛘哌@么說吧，橫向比較只能定基線值，最差不能低于多少，至于達標后的各自高低，就沒有可比性了?！?/p>
小A：“這句話好像解決了我的疑惑?！?/p>
曉南：“嗯，不能說絕對沒意義，如果有一點意義的話，那就是定基準了?！?/p>
小A：“原來是有點動搖的想法，現(xiàn)在更加清楚了；通常來說這個基線值如何定制，是有行業(yè)的規(guī)范還是公司內部的標準？我好像查不到這方面的資料，只有CMMI的一個千行代碼標準。”
曉南：“沒有行業(yè)規(guī)范，各個公司可能不太一樣，根據(jù)自己的研發(fā)能力定基線就行了。我們可以選取研發(fā)勝任力相對平均的團隊值作為基線參考?！?/p>
小A：“聽君一席話，勝讀十年書?！?/p>
缺陷率迷思
千行代碼缺陷率被廢棄
千行代碼缺陷率 = Bug數(shù)量 / 千行代碼數(shù)
這是一個經(jīng)典指標，以前在研發(fā)側經(jīng)常用來衡量代碼質量，近年被逐漸棄用。
原因是這個指標有負面的引導，似乎不鼓勵寫高質量的簡潔代碼，而稀釋代碼或造輪子則能帶來比較好看的數(shù)據(jù)，這與指標設置的初衷“提升代碼質量”相悖。
因此，該指標不建議橫向比較，不建議作為績效指標。但可以作為代碼質量指導基線，或作為工程師的自我修養(yǎng)，用于自我評估和改進。
附上在CMMI里對千行代碼缺陷率的標準，不難看出缺陷率還是以一個滿足該等級的基線值存在的，也就是說它不能用來衡量代碼質量有多好，但可以用來衡量代碼質量最差不能低于什么水平。
缺陷率無法體現(xiàn)軟件質量
<div style="text-align:center">缺陷率 = 失敗的用例數(shù) / 執(zhí)行的用例總數(shù)
</div>
從字面意義上理解，這個指標看著像是衡量軟件質量的。但放入研發(fā)體系內思考，通常在不同版本間，執(zhí)行的用例總數(shù)是變化的，失敗的用例數(shù)也取決于用例執(zhí)行者的判斷，而失敗的用例又不一定會以缺陷的形式來跟蹤。所以這個指標很難有確定的標準，那么它還是有意義的嗎？
我認為是有意義的，意義在于它揭示了測試設計的質量，即經(jīng)過設計的測試用例能否有效發(fā)現(xiàn)缺陷。 從這個維度上講，這個指標恐怕叫“用例有效率”更恰當一點。
不管是千行代碼缺陷率，還是測試統(tǒng)計的缺陷率，統(tǒng)計時難免會陷入數(shù)據(jù)的迷思。片面追求數(shù)據(jù)好看，對團隊的副作用很大，結果可能是既不經(jīng)濟、也沒成效，平白做了很多無用功。思考質效工作如何經(jīng)濟又高效，有助于避開局部優(yōu)化的泥沼。
質效管理投資回報
不是指標的鍋，而是思路偏差
由上面的討論容易得出以下結論：
第一，從度量引導團隊改進的意義角度來看：指標數(shù)量絕對值 < 指標的環(huán)比（無任何時間間隔，連續(xù)周期內的變化），應更多關注團隊指標的變化趨勢，以及思考是什么原因引起的變化，該如何改進；
第二，團隊內的任何投資，都需要考慮投入產(chǎn)出比 ROI，為了得到結果而付出巨大的代價，本身就是一種失效。 尤其當資源被投入到“質效提升或管理”這類成本高見效慢的活動時，考慮是否經(jīng)濟尤為重要。
質效管理效率金字塔
為了獲得更高的投資回報，不得不思考團隊可能采取的投資和收益之間的關系，以及可能的影響因素：成本、反饋周期、效率等互相制約的程度。
在軟件研發(fā)活動中，有些事屬于決定做什么和怎么做的定義范疇，如需求方案、技術架構、測試策略等；而有些事情屬于落地實施范疇，如：工序拆解和研發(fā)、測試和運維。
當決定做研發(fā)治理時，在不同層次發(fā)力，所需成本、見效周期/觀察期、治理效果也不盡相同。
- 在定義階段發(fā)力，成本低、見效期長，但治理效果最好，問題根因也往往會追溯到此
- 在實施階段發(fā)力，成本高、見效期短，但治理效率偏低，數(shù)據(jù)好看但治標不治本
因此，當我們追求不同的提升或治理目標時，所采取的策略也應做不同的組合。
假設團隊處在新組建期，軟件也處在MVP或0-1階段，此時從底層思考比較好，在做前把問題定義清楚，架構和策略都想清楚，定義好后續(xù)實施階段的各種門禁和標準，會為后續(xù)研發(fā)過程的順利進行打造良好的基礎。
假設團隊較大，處于穩(wěn)定期，軟件也處在增強和維護期，軟件的質量反饋出團隊的潛在問題較多，此時比較短平快的方式是先抓實施層面，讓團隊快速看到效果，從而建立信心。通過實施層面反饋的問題，進一步根因分析，可能會發(fā)現(xiàn)在定義階段需要進行測試策略的重塑。在團隊調整的接受度和靈活性都較好時，再進行底層的改造，持續(xù)的觀察和改進，就比較容易看到效果。
質效工作本質是打造高效高響應系統(tǒng)
系統(tǒng)是有機整體
系統(tǒng)是若干部分相互聯(lián)系、相互作用，形成的具有某些功能的整體。系統(tǒng)動力學認為系統(tǒng)中的因、果回饋關系環(huán)環(huán)相扣，系統(tǒng)結構決定系統(tǒng)功能。 舉個例子，“三體”即為一個系統(tǒng)，在這個系統(tǒng)中，三個天體間的萬有引力相互影響，相互制約，對外呈現(xiàn)一個動態(tài)系統(tǒng)。
在系統(tǒng)思考中，是以開了掛的全局眼光審視整個系統(tǒng)，而不僅僅是尋求局部最優(yōu)解。雪崩時，沒有一片雪花是無辜的，也沒有一片雪花能夠幸免。系統(tǒng)整體功能不好，牽涉其中的每個人都是受害者，也都是加害者。
因此在討論系統(tǒng)時，我們既要研究系統(tǒng)中的各個組成元素，又要各元素之間相互影響的關系。
系統(tǒng)思考看待系統(tǒng)問題
為了更好的說明質效工作需要系統(tǒng)的看待問題，我們舉一個常見的例子。在質量領域，有一個老生常談的問題：自動化測試的投入產(chǎn)出比。由此衍生更多的問題：自動化測試難開展、難維護、難持續(xù)。以往在看待這個問題時，可能的思路是：測試人員的自動化能力較低，或者時間緊任務急沒資源。
在采用系統(tǒng)思考看待這個問題時，就不會只是盯著測試人員做改進，而是思考整個研發(fā)系統(tǒng)在自動化測試上的瓶頸所在，追求的也是整個研發(fā)系統(tǒng)在自動化測試上面的投資回報率。
現(xiàn)在來推演一下，當要做決策時，我們追求高投資回報。而投資回報取決于成本和收益，成本越高投資回報率越低。那么，都有哪些因素影響自動化測試的成本呢？
影響自動化測試成本的因素：
1. 軟件本身的可測性： 當軟件可測性較低時，自動化成本就會飛升，甚至根本不具備可自動化的條件。而這個因素的可控性受制于軟件的架構設計，在軟件成熟期不具備可改進的靈活性。因此建議在做架構設計時就充分考慮軟件可測性，否則后續(xù)的自動化測試會難以開展。
2. 人員能力： 這里不僅僅指自動化測試的編碼能力，更要求測試人員具備一定的測試設計能力。能夠充分理解測試分層，不同層的測試服務于什么目標，解決什么問題，以及測試的框架選型等能力。
3. 資源配置： 指團隊的研發(fā)節(jié)奏，能否有余力進行充分的自動化測試。
4. 環(huán)境依賴： 自動化測試如果不能持續(xù)運行，就會失去盡早暴露缺陷的時機，而持續(xù)運行依賴于能排除干擾的穩(wěn)定環(huán)境。
5. 工具鏈割裂： 指團隊的工具鏈體系是否支持自動化測試持續(xù)集成，或者不同層級的自動化測試工具是否具備一致性。這在一定程度上影響自動化測試的可維護性。
質效工作的本質
基于以上的討論，當思考如何提升自動化測試投資回報率時，我們就有了更多可能的改進方向。抽象一下，當思考質效工作本身時，我們需要打造的是一個高效高響應的系統(tǒng)。 系統(tǒng)中包含各種元素：干系人、策略、實踐、流程、資源、工具……各個元素之間又相互影響，相互制約。當需要作出決策時，充分分析系統(tǒng)中的各元素及其之間的關系，有助于我們得出全局優(yōu)化方案。
下圖為系統(tǒng)中涉及的元素集合：
接下來選取觀察元素，思考相互關系，有機的組建一個系統(tǒng)。一個典型的系統(tǒng)思考應用就是冰玉老師的《一頁紙測試策略》，如圖：
基于這樣一個決策系統(tǒng)，我們就很容易對齊質量領域下的預期和優(yōu)先級，從而更好的促使團隊進行改進。
而幫助團隊設計和實施一個高效的、高響應力的質效系統(tǒng)，正是質效管理者的價值體現(xiàn)。
推薦閱讀：
