到底目前軟體品質的狀況如何? 軟體品質指標
這篇文章主要說明”軟體品質指標”的一些應用。
軟體開發的過程中，是不是有什麼軟體品質指標可以讓我們知道目前軟體品質的狀態?
甚至用來決定是不是可以到了出貨的品質。這也是 QA team 的挑戰。
因為程式大部分都不是 QA 完成的，但是最終需要對於軟體品質狀態提供一些專業的分析。
定性 vs 定量
要建立軟體品質指標，又分為定性與定量。
定量的資料比較客觀例如：
- Number of submitted defects
- Number of rejected defects
- Number of known issue
- Number of P1/P2 cases
- Line of Code changes
- ….
定性的資料可能有些主觀成分，例如：
- Uncertain Technology
- Cross team collaboration
- legacy code integration
- Customer requirement changes
- ….
這些都會對於整體的軟體品質直接或是間接影響。
因此如果要訂定軟體品質指標，筆者建議，依據專案要達成目標的屬性，針對該目標延伸相關的指標。
舉例來說，這次專案的主軸是 — 根據上一版客戶需求做修改。因此，這次品體品質指標可以專注在於滿足客戶需求的 cases
軟體品質並非追求零瑕疵，而是追求在當下相對穩定 & 符合客戶需求的品質。
因此出貨時，我們主要需要掌握的是 “風險”。
到底有哪些是已知的風險 (如雷達圖)或是未知的風險我們需要”共同”承擔。品質是大家一起的責任而非品管部門
到底有沒有一個計分指標，可以客觀的說明整體專案的品質? 沒有 ! 但是這邊筆者建議一種方式，可以建立起這樣品管指標的方法。
風險分析雷達圖
這邊筆者建議另外一種方式，為品管風險分析雷達圖。 也就是說在特定的時間點時，目前軟體的品質風險為何?
可以將軟體品管的風險分為五大類 (讀者可自行調整，新增或是修改)
- Code Turmoil : 程式碼修改的狀態。如果要快出貨但是還是有大量的程式碼修改，那麼品質風險就相對會提高。
- Test complete Rate: 測試個案完成率。最後一個月快要出貨時，但是有大量的測試個案未完成，也表示品質有一些未知的風險。
- Test Success Rate: 測試個案成功率。如果有大量的測試個案測試結果都是失敗，也表示品質風險提高。
- Total Open Defect: 目前尚未解決的Defects。如果有很多都是 P1/P2 的 defects，也是一個客觀的品質風險。
- Defect Found this Week: 這星期新發現的 defects。如果要出貨前夕，還是有大量新的問題被找到，那麼品質風險也相對較高。
這樣的圖如下所示。每一個類別越接近 6分，表示該項目品質風險越高。
例如這個圖表示，現階段有大量的程式碼異動，而且有許多新的問題在這個星期被找到。
如果將這五大類別分數加總，就會得到一個整體的品質指標。品質風險最高為 6 x 6 = 36
隨著時間經過，就可以追蹤整體品質指標的狀況。例如這個例子，從一開始高風險 23 一直到最後風險降低為 6。
要強調的是，我們不是為指標而工作。這只是方便整體團隊了解品質的狀態一個簡便的方式。
最終軟體的品質還是以達到客戶與市場的目標為最終目標。而非一昧地追求這個數字。
那麼要如何將這五大類產生出 0~6分的指標呢?
首先，要定義每一類別 1~5分的標準，舉例如下：讀者可以依據實際專案的狀況作調整。
RD 的工作: Code changes, Defect Found This week, Total Open defects如果這幾項 很高，表示接下來的一個星期 RD 工作量會比較大。
QA 的工作: Test success rate , test complete rate，這兩項表示 QA 接下來的工作量。如果完成度很低、測試個案失敗很多，表示專案接下來會友比較多的QA工作要完成。
小結
軟體品管有沒有一個指標可以代表品質? 沒有! 軟體品管主要在於掌握已知與未知的風險
最終出貨與否還是要客觀的評估市場與客戶對於產品品質的認知與接受度
如果真的要將品質指標量化，這篇文章建議一個雷達圖的方式，可以將軟體品質分為六大類，
根據每一類定義 1~6的品質指標，最後加總。
最後，軟體品質是大家的責任，並非一個指標或是一個功能團隊所決定!