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