測驗管理之專案軟體測驗風險管理實踐

在軟體測驗活動中，作為一名測驗人員有沒有遇到過這樣的場景，在測驗一個特性或者制定一份測驗方案時，往往會想著進行簡單測驗、做簡單設計，認為

1、這個場景出現的概率太低，幾乎不可能會存在，不測了

2、實際應用時不可能會有這么大的用戶量，不用考慮

3、在這個時間段應該不可能會有這么大的業務量

4、同一時刻不可能會存在多種業務并發上來

但版本發布上線后，實際應用時之前認為的那些小概率事項，結果確往往就是會出現，這是為什么呢？管理學中有一個定律——墨菲定律；這個定律指出，當事情有變壞的可能，不管可能性有多小，他總是會發生；

在具體的研發測驗中，當測驗程序、測驗交付存在潛在風險導致出現不好的結果時，我們需要如何做好全方位的準備？積極的應對，避免不好事情造成的影響或把影響降到最低；結合當前專案運作，分享下當前專案程序中對于測驗風險控制的實踐程序，

一、認識風險

在專案活動中風險是指專案活動程序中的一種不確定的事件或條件，一旦發生會對具體的專案的單個或者多個目標產生影響，例如：

· 研發程序中，特性需求臨時變更，代碼修改，但測驗時間不足，存在質量風險

· 版本交付，存在外部依賴不滿足，交付受阻；

· 版本測驗，測驗作業量估算不合理，測驗不充分

這些交付程序中存在的動態的、靜態的、已知的、未知的不確定性因素影響測驗交付目標，無法滿足外部市場需要；那如何做呢？

二、風險管理

在專案的測驗活動程序中，我們通過一系列風險控制活動對不確定因素進行及時識別、有效評估、積極應對，以保證專案測驗活動的正常進行，從而達到價值交付；

1.風險識別：

在風險識別階段通過樹立團隊整體的風險意識，大家一起討論制定風險識別維度、在對應的研發階段、利用一定的工具方法進行風險資料收集，從而進行有效識別，

1)風險識別維度

根據專案的實際運作團隊討論，通過收集如下四個維度的資訊作為風險識別的輸入，來進行識別

專案：專案的維度主要考慮：

·專案規劃需求的計劃：在專案迭代開始初期，規劃的需求內容、提交的計劃點；如果在程序中發生需求加塞、提交計劃變更和一開始的計劃出現偏差，則作為風險進行及時上報；

·相關的制約因素：是否存在對外部依賴，比如對外圍的軟硬體版本存在依賴，需要提供后，集成完成才能滿足交付條件；

·里程碑時間點：時間點要求也是一個識別依據，臨近里程碑時間點，現狀和目標存在較大偏差；

·作業量的估算；作業量估算的合理性，有些是專案強行壓下的，存在較大的作業量偏差；

·以及隱形因素專案內各團隊之間的合作協作關系

資源：資源的維度主要考慮人力資源是否充分，設備環境資源是否能滿足相應的測驗活動；比如組網場景、容量上對資源的要求，是否具備；

技術：技術的維度主要考慮當前是否存在新領域不熟悉、所需的技能存在盲區，

質量：質量維度主要是要了解確認對任務質量的要求，是僅滿足預研穿刺基本測驗，還是需要按交付標準的DOD嚴格執行，以達到交付要求；

2)風險識別階段

風險識別活動貫穿在整個測驗活動的始終，從測驗SE參與需求分析開始、撰寫測驗策略、跟蹤特性實作程序、交付系統測驗以及其他（維護）各階段都需要識別；

3)風險識別方法

·專家判斷：了解專案和業務各領域的人員，考慮單個風險的方方面面，以及整體專案風險的各來源；

·頭腦風暴：參考一定的風險識別維度，進行相關的腦暴；

·訪談：對領域專家、資深參與者訪談；

·會議討論：團隊成員對當前所承接的任務，觀察了解到的資訊進行專門的會議討論，審查識別的風險；

·風險檢查單：各階段的風險點，用作提醒（堅持單及時審查，定期更新調整）

風險識別經驗小結：

1、團隊樹立風險意識，鼓勵所有人相關人員參與風險識別

2、除了顯性可見風險，同時也要注意隱性的團隊協作，氛圍的風險

2.風險評估

通過有效描述風險，明確風險類別后合理定義風險級別來評估風險，以確認風險影響以及為后續的風險應對措施提供依據；

1)風險描述：

風險包含起因、時間、概率及影響四要素，在了解風險4要素后，使用結構化SQCA描述方法，把風險本身與風險愿意及風險影響區分開來，描述清楚；

S(Situation):背景起因

C（Complication）:事件沖突

Q（Question）：問題影響

A（Answer）;答案

描述結構化方式：在某個背景（起因）之下，遇到了復雜（事件）情況，產生了什么樣的（問題）影響，然后我們如何去解決它（答案）

其中風險描述中風險影響和解決方案是關鍵，建議描述要領：

·Q（問題影響）：描述清楚波及的范圍、問題的重要、緊迫程度

·A（解決方案）：遵循3W原則，解決方案具體內容，包含所需要的資源等（What）、具體的責任主體（Who），由誰負責解決、期望解決的具體時間點（When）

·風險描述案例：

·技術風險描述舉例：

隨著公司業務的快速發展（S），我們的IT系統無法滿足現狀產品的需求（C），這將導致我們無法滿足我們的客戶（Q），當務之急的應對措施是需要***立刻安排升級IT系統（A）
　　·質量風險描述舉例：

臨近迭代交付（S），測驗自動化無法穩定運行（C），導致守護不完善，存在質量風險影響發布（Q），當務之急***盡快在迭代交付前完成自動化執行守護修復（A）

2)風險分類

在有效的描述清楚風險后，進行風險分類，明確風險類別；這個程序主要是便于把注意力和精力集中到風險最大的領域，或者針對一組相關的風險制定通用的風險應對措施，從而更有效的開展應對；

·按風險來源分：技術風險、管理風險、外部風險、內部風險等

·或者按受影響的專案作業分：方案設計、編碼實作、驗收測驗等

目前我們專案運作程序中，風險分類主要還是以風險的來源來分，根據分類出的風險，發現外部依賴類風險占據比例較高，針對此類風險討論通用的應對措施，比如通過一開始的協作規劃專案計劃來約束、程序中每日的日報、周報來跟蹤外部依賴提供的進展等

3)風險定級

在描述清楚風險、做好分類后，團隊根據具體的研發程序，對風險偏好和風險臨界討論制定風險影響和概率的定義，從而進行風險定級評估；

比如通過風險出現的概率情況、對測驗目標的影響程度來綜合判斷風險級別，

根據定級結果，高以上風險：立即行動 ；中風險：立即關注；低風險：定期關注

3.風險應對：

在風險評估定級完成后，進行對應的風險應對；在實際的專案運作程序中根據不同的場景，采用不同的應對措施；

·風險上報：當超出個人或團隊處理的能力時，需要進行風險上報，一般風險級別為高以上類風險；比如涉及到外部依賴類風險，需要專案協調，否則版本無法正常集成制作；通過面對面、電話溝通、或者日報周報的方式上報反饋；

·風險規避：發生的概率較高，具有嚴重負面影響的高優先級風險；比如在臨近版本發布時，某些特性由于測驗不充分，波及不明確，合入后存在對現有商用版本存在未知隱患，通過裁剪、調整特性合入周期來規避版本發布質量風險；

·風險轉移：應對風險，把責任外包給第三方；比如在研發程序中，對于新領域不熟悉，但第三方存在成熟的技術，可以通過購買服務、簽約合同；和第三方達成合作，把風險轉移第三方；

·風險減輕：降低風險出現的概率和影響；比如在臨近版本發布時，合入了故障，但該故障的波及范圍交廣，測驗又不充分；經過分析故障影響，回退合入故障，來規避影響；

·風險接受：對于低優先級的風隙訓者其他任何策略已無法加以應對；

三、經驗總結

最后的話：

1、測驗程序中，當好測驗“操盤手”，綜合進行風險控制，做好全方位準備，積極應對，避免或降低壞事出現后造成的影響；

2、加強團隊風險意識，風險管理控制需要全員參與

3、作為一名優秀的測驗人員養成風險資料收集、整理、分析習慣；

4、善于總結經驗，練就一副識別風險的“火眼金睛”

5、作為測驗人員,要“未雨綢繆”，從源頭控風險，不要當“救火隊員”

以上筆者的經歷更像一張橫向的知識網，創建了一個交流平臺 914172719 ，群內有各種技術同行交流、學習資料、面試經驗等，其中用到jenkins、docker、moutebank、python編程等，還需要花更多的精力去深入學習，當每項技能都能掌握到一定深度，才能稱為一個完整的知識體系，

最后： 可以關注公眾號：傷心的辣條 ！ 進去有許多資料共享！資料都是面試時面試官必問的知識點，也包括了很多測驗行業常見知識，其中包括了有基礎知識、Linux必備、Shell、互聯網程式原理、Mysql資料庫、抓包工具專題、介面測驗工具、測驗進階-Python編程、Web自動化測驗、APP自動化測驗、介面自動化測驗、測驗高級持續集成、測驗架構開發測驗框架、性能測驗、安全測驗等，

如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！

好文推薦

轉行面試，跳槽面試，軟體測驗人員都必須知道的這幾種面試技巧！

面試經：一線城市搬磚！又面軟體測驗崗，5000就知足了…

面試官：作業三年，還來面初級測驗？恐怕你的軟體測驗工程師的頭銜要加雙引號…

什么樣的人適合從事軟體測驗作業？

那個準點下班的人，比我先升職了…

測驗崗反復跳槽，跳著跳著就跳沒了…