軟體品管的流程 Defect Flow

軟體品管的流程 Defect Flow

這篇文章主要討論軟體品管流程Defect Flow的定義以及需要考量的因素，

軟體品管的流程主要會影響開發團隊RD/QA的工作流程

好的流程也會間接讓整個團隊運作更有效率。

什麼是 Defect Workflow

軟體開發的過程中，RD不斷的產生程式碼，完成所要開發的功能

另一方面，QA不斷地根據需求與開發的功能做品質驗證，

當發現品質的問題的時候，QA就會做品質問題的紀錄

這樣的紀錄就會被登入在系統中，通常會有 Defect Management管理系統。

QA紀錄品質問題的時候，這筆紀錄就會被傳到對應的RD，

當RD解決問題之後，就會將該問題回覆給QA，QA就會再次進行驗證，

這樣的流程就稱為 Defect work Flow

Defect Workflow有標準嗎?

Yes  and No

Yes是因為整體公司的品質政策確實需要一些基本的政策與標準。

例如，將每個品質問題嚴重性分類為 Severity A, Severity B, Severity C, Severity D

像這樣嚴重性的定義就比較需要公司一致性的認知。為什麼呢?

想想看如果公司有兩個產品。

產品A，的嚴重性分為  Severity 0, Severity 1, Severity 2

產品B嚴重性分為 Severity A, Severity B

那麼當產品要上市時的品質標準，就會產生一些混淆

上市產品一定要將所有的 Severity 0解決完 還是 Severity A/B解決完?

兩個產品的品質是否大家有一致性認知?

No 的部分是因為有些 workflow 會因為每個團隊工作的方式有些不同

例如：有的團隊有L10n團隊負責翻譯，其他團隊完全則是負責模組沒有畫面與翻譯的問題

向這樣的 Workflow 就會有些差異，甚至 Defect Type的值也會有所不同。

基本的欄位需要哪些呢？

當ＱＡ回報一個問題的時候，基本需要下列資訊

當　ＲＤ解決一個問題的時候，基本需要回填下列資訊

這樣的 Workflow Defect 的制定，一方面要有一致性的公司品質政策的認知

另一方面又要讓團隊工作有彈性，所以隨著時間的演進，這樣的workflow欄位也會越來越複雜

舉例來說，”Frequency” 問題發生頻率的這個欄位，由於每個團隊的需求不盡相同，因此最後相關的值可能會有