在本文之前，筆者曾分享過一篇關於質量保障流程的文章《漫談專案質量保障——協作流程》，文章簡述了筆者參與的專案協作流程，同時對流程中一些不同尋常的協作節點進行闡述。由於多種原因限制，之前分享的流程存在一定的不完整性，所以本文將繼續分享《漫談專案質量保障——協作流程》優化後的版本。
初版的協作流程如圖1-1所示，整個流程涉及了產品人員、UI設計人員、測試人員、開發人員和專案管理員五種角色，並設計了未開始、待內審、待評審、待UI設計、UI設計中、待開發、開發中、待產品驗收、待測試、測試中、測完待發布、待資料回顧、關閉共13個專案節點，每個節點關聯一個角色負責人。
由於協作平臺功能的侷限性，部分協作流程節點無法配置多角色並行處理，初版設計存在一定的遺漏和冗餘。如果排除協作平臺的侷限性，更理想的協作流程應該是怎樣的呢？如圖2-1所示，優化後的流程依然是13個專案節點，但是節點和節點內容已經有了不少的變化。那優化後的協作流程與前一版本有哪些差異呢？
首先，新的協作流程裡增加了部分節點，例如UI設計及研發方案待評審節點、測試線上驗證環節。同時，設計節點也補充了待研發方案設計的狀態，開發中節點補充了測試用例設計中的狀態。
其次，流程裡完善了前置節點未通過情況下的流程指引，例如開發自測用例未通過的情況下節點可轉回開發負責人，線上環境測試未通過時進行停止釋出或回滾服務（處理方案視具體情況而定）。
再次，流程將不同角色可並行的環節進行合併，例如分別將設計、評審和驗收環節合併為一個時間節點，增加多角色並行處理環節，對整體協作流程進行了簡化。
為什麼要設定這些流程呢？優化協作流程對我們測試人員來說有什麼幫助？
（1）對於一個專案來說，專案進度的把控對於專案風險的把控極其重要，流程的設計一方面是要關注專案應該在規定的時間進入預期的專案節點，另一方面也是為了關注在對應的專案節點是由誰跟進負責，做到專案進度清晰，專案節點責任到人，這也是為什麼筆者設計的流程圖裡各個專案節點都關聯著各自的負責人。
（2）為什麼要增加UI設計及研發方案評審的環境？當前或者說前些年測試領域都在推廣著測試左移（測試前移），其本質思想其實就是為了讓風險前置。如果沒有方案評審環節，或者說這個評審環節因質疑測試人員參與的必要性而不對測試人員開放，從而引起資訊不同步，其結果就是專案風險後置到了產品測試階段，其問題修復成本也隨之提高。
（3）為什麼要增加自測和自測不通過轉回開發環節？對於責任心比較高且質量意識比較強的研發人員來說，這個環節完全可以忽略或者是簡單地走個形式流程，但是對於責任心不高且開發能力一般的的開發人員來說，這個環節是測試人員必須重點關注的。如果沒有這個環節，沒有提測不通過資料的資料支撐，專案延期和專案質量的風險只會是測試人員獨自承擔，所以需要這個環節來暴露開發的的質量風險並進行約束。
本文主要分享了優化後的專案流程以及兩個版本流程的差異，並分享了部分流程優化的思路和優化的緣由。總結來說，專案協作已經是一個比較複雜的過程，而專案協作管理只是專案質量管控中的一小部分。因此，對於測試工程師或者QA來說，想要把控好軟體專案的質量，只關注眼前bug的話，還遠遠不夠……
原文發表於【愛測角】：《漫談專案質量保障——協作流程優化》。
作者：Chaofan
北交學子，專注軟體測試和質量保障的思考和分享。