前言
寫這篇文章的初衷，是前幾天在團隊內部進行了一次缺陷和使用者反饋建議的覆盤歸因分享，略有所得。
正好昨天看到chenkl老師的一篇文章：《團隊交付質量如何評估》。其中講到的很多點如缺陷趨勢圖、交付時長、線上BUG逃逸率、使用者反饋等，給了我很多不一樣的啟發。
這篇文章，我想來聊聊，如何通過覆盤歸因，來提高交付質量。
軟體交付質量
在日常的工作流程中，比較通用的流程如下圖所示：
從質量保障和交付的角度來講，軟體交付生命週期中大體可分為如下三個階段：
需求設計質量
這個階段包括原型圖、PRD文件、互動設計、技術方案、測試用例等幾項重要產出物，當然他們有一定的前後依賴關係。
我們談軟體交付質量，不可避免的要從它的源頭說起，而源頭就是需求和設計階段要做的事情。
如上圖所示，我們為什麼需要做大量的評審工作呢？因為如果在源頭存在問題，那麼研發過程和後面的使用者使用質量，就無從談起。方向錯了，就全錯了。
評審最大的作用就是集各個角色(產品&研發&測試)從不同角度對需求設計進行解讀理解，提出疑問和建議並進行修正。
確保在最開始確定方向和需求細節方面，儘可能降低或者避免遺漏及不合理帶來的質量交付風險。
研發過程質量
有句話怎麼說來著？“軟體質量是構建出來的，不是測試出來的”。
測試的本質是驗證研發交付的產出物是否達到需求設計及預期的標準。並不能直接帶來質量的提升，只能通過種種手段多維度的去驗證是否達標，並通過流程規範、度量標準等去保障最終的交付物達標。
因此，我們常說的各種測試技術手段，都是驗證和保障交付質量的手段，而不是構建質量的手段。
使用者使用質量
使用者使用質量，指的是軟體線上釋出後，我們對使用者使用過程進行追蹤並採集資料進行評估度量的過程。
常見的評估維度有線上缺陷逃逸率、客訴工單、使用者反饋建議、資料埋點等。
具體內容可參考chenkl老師的《團隊交付質量如何評估》，這裡不做過多的贅述。
覆盤歸因的價值
為什麼要覆盤歸因
之前有人問我，軟體測試的本質是什麼？我考慮良久，給出的答覆是“質量+效率”。
先保障質量可控，再提高過程效率，通過節省下來的資源去投入到提高質量的過程中。
上面的內容提到了軟體交付生命週期以及軟體交付質量在不同階段的產出物，在每個環節都需要通過評審、檢查、度量、驗證、迴歸等手段來保障交付質量。
但這些手段只能保障在每次迭代的生命週期中，軟體交付質量處在一個可控的範圍內。長期來看，並不能達到提高交付質量以及過程效率的目的。因此，覆盤歸因的價值就體現了出來。
通過對過程和交付結果以及線上使用者使用質量進行跟蹤度量評估，找到出現問題的原因、解決方案，
並將其中可複用的進行歸納總結，通過流程規範、技術優化、文件培訓等方式融入貫穿交付過程，最終達到提高交付質量和效率的目的。
如何開展覆盤歸因
先看下面這張流程圖：
我們在談到軟體交付質量的時候，分了三個階段，每個階段都有不同的手段去測試驗證，也有各自的產出物。比如：
需求設計階段：原型圖、PRD文件、互動設計
研發過程階段：單測覆蓋率、codereview記錄、bug列表
使用者使用階段：線上問題list、使用者反饋list、資料埋點結果
整體的覆盤歸因過程，可以拆解為下列幾個步驟：
- 對不同階段的過程及產出物進行復盤評估；
- 找到做的不好的地方或者不合理的手段方式；
- 評估它的操作和背後的原因以及當時的解決方案；
- 思考問題：怎麼做才能讓過程和交付結果變得更好；
- 將更好的方式進行歸納總結並將其融入交付過程的過程；
- 推廣落地實踐並進行度量評估，驗證其是否有效，並不斷覆盤歸因；
覆盤歸因的真正目的
上面我們聊了交付過程的三個階段，也聊了為什麼要進行復盤歸因以及它的過程，那覆盤歸因的真正目的是什麼呢？
其實答案在上面已經說了，這裡我想從測試的角度加入一個新的詞：收斂。
測試的本質是什麼？我覺得在當下的應用實踐中，應該是保障質量可控→提高過程效率→確保問題收斂。
