漫談專案質量保障 協作流程優化

2022-09-26 04:39:10 字數 1608 閱讀 3206

在本文之前,筆者曾分享過一篇關於質量保障流程的文章《漫談專案質量保障——協作流程》,文章簡述了筆者參與的專案協作流程,同時對流程中一些不同尋常的協作節點進行闡述。由於多種原因限制,之前分享的流程存在一定的不完整性,所以本文將繼續分享《漫談專案質量保障——協作流程》優化後的版本。

初版的協作流程如圖1-1所示,整個流程涉及了產品人員、ui設計人員、測試人員、開發人員和專案管理員五種角色,並設計了未開始、待內審、待評審、待ui設計、ui設計中、待開發、開發中、待產品驗收、待測試、測試中、測完待發布、待資料回顧、關閉共13個專案節點,每個節點關聯乙個角色負責人。

圖 1-1 【愛測角】軟體專案協作流程

由於協作平台功能的侷限性,部分協作流程節點無法配置多角色並行處理,初版設計存在一定的遺漏和冗餘。如果排除協作平台的侷限性,更理想的協作流程應該是怎樣的呢?如圖2-1所示,優化後的流程依然是13個專案節點,但是節點和節點內容已經有了不少的變化。那優化後的協作流程與前一版本有哪些差異呢?

圖 2-1 【愛測角】軟體專案協作流程——優化版

首先,新的協作流程裡增加了部分節點,例如ui設計及研發方案待評審節點、測試線上驗證環節。同時,設計節點也補充了待研發方案設計的狀態,開發中節點補充了測試用例設計中的狀態。

其次,流程裡完善了前置節點未通過情況下的流程指引,例如開發自測用例未通過的情況下節點可轉回開發負責人,線上環境測試未通過時進行停止發布或回滾服務(處理方案視具體情況而定)。

再次,流程將不同角色可並行的環節進行合併,例如分別將設計、評審和驗收環節合併為乙個時間節點,增加多角色並行處理環節,對整體協作流程進行了簡化。

為什麼要設定這些流程呢?優化協作流程對我們測試人員來說有什麼幫助?

(1)對於乙個專案來說,專案進度的把控對於專案風險的把控極其重要,流程的設計一方面是要關注專案應該在規定的時間進入預期的專案節點,另一方面也是為了關注在對應的專案節點是由誰跟進負責,做到專案進度清晰,專案節點責任到人,這也是為什麼筆者設計的流程圖裡各個專案節點都關聯著各自的負責人。

(2)為什麼要增加ui設計及研發方案評審的環境?當前或者說前些年測試領域都在推廣著測試左移(測試前移),其本質思想其實就是為了讓風險前置。如果沒有方案評審環節,或者說這個評審環節因質疑測試人員參與的必要性而不對測試人員開放,從而引起資訊不同步,其結果就是專案風險後置到了產品測試階段,其問題修復成本也隨之提高。

(3)為什麼要增加自測和自測不通過轉回開發環節?對於責任心比較高且質量意識比較強的研發人員來說,這個環節完全可以忽略或者是簡單地走個形式流程,但是對於責任心不高且開發能力一般的的開發人員來說,這個環節是測試人員必須重點關注的。如果沒有這個環節,沒有提測不通過資料的資料支撐,專案延期和專案質量的風險只會是測試人員獨自承擔,所以需要這個環節來暴露開發的的質量風險並進行約束。

本文主要分享了優化後的專案流程以及兩個版本流程的差異,並分享了部分流程優化的思路和優化的緣由。總結來說,專案協作已經是乙個比較複雜的過程,而專案協作管理只是專案質量管控中的一小部分。因此,對於測試工程師或者qa來說,想要把控好軟體專案的質量,只關注眼前bug的話,還遠遠不夠……

專案流程優化

專案流程優化是乙個持續過程,每個公司,每個團隊情況不一樣,總原則是 如果在專案過程中你感覺到某一點很彆扭 很不爽 痛了,那麼這就是優化點。優化的手段是多樣化的,如通過流程規範去約束 開發和利用工具去輔助等等,都是優化方式。流程優化是一件需要團隊合作才能做得更好的事情,所以任何優化都需要與團隊各角色達...

漫談專案設計 重構 效能優化

重構的好處 重構能夠改進軟體設計,隨著專案需求的變更,專案體積的變大早已與最初的設計大相徑庭,結構變得凌亂 複雜,如果不進行重構,則很難新增新的功能。1 使專案 更容易理解 很多情況下是由於專案趕進度和不注重質量導致的。那麼通過重構可以幫助 維持自己該有的形態。專案開始的時候,設計並沒有考慮到方方面...

敏捷測試驅動模式 專案質量保障體系

結合敏捷專案管理,測試驅動模式,讓測試跑起來.我給這套體系的定義就是 保障質量的同時保證專案進度 四個節點及時反饋及時溝通,有效的讓產品 研發和測試都動起來,避免任意一方的停滯。質量的四層把控 1 測試人員更早的介入需求 2 需求用例 功能用例 3 每天乙個功能秀 4 嚴控用例執行規範 指標維度 核...