這是《落葉》文集里第?202?片落葉，希望你能喜歡，不為別的，只為這份堅持。
【背景】
今天有同學問我，他原來在跟項目經理打交道時，經常聽說風險管理。所以想了解，在內部研發的測試項目管理里，是不是也需要單獨做風險管理呢？
【你問】
軟件測試項目里需要做風險管理嗎？
【我答】
風險管理是指如何在項目或者企業這樣一個肯定有風險的環境里把風險可能造成的不良影響減至最低的管理過程。風險管理的內容包括風險管理計劃、風險識別、定性風險分析、定量風險分析、風險應對計劃和風險監督與控制。
在執行過程中，項目風險管理可以簡化為風險識別、風險度量、制定應對措施和風險監控四個過程。
項目的風險管理是一個動態的工作過程。
項目風險識別是項目風險管理的重要環節。
在任何環境下做項目，風險都是無處不在的，也是最防不勝防的。項目風險其實就是一種不確定的事件或條件，假如發生，就會對項目造成積極或消極的影響，如范圍、進度、成本和質量。
所以我們在做測試計劃時，最重要的一項工作就是識別風險和制定風險應對方案。
上面我們了解了風險和風險管理的概念，風險管理就是在識別出項目可能有的風險之后，事先就可以做的或者是可以計劃的一系列應對手段，最終目標是降低風險發生的概率或者是當風險發生時，如何能快速地、有效地去應對和解決風險所帶來的后果。
主要有下面幾個步驟：
1、描述清楚風險是什么，會帶來什么樣的嚴重后果，包括發生概率有多大；
2、分析風險產生的可能原因有哪些，可能發生在某個階段或時間點；
3、針對每個原因再制定應對方案；
4、每個風險應對方案要有明確的責任人和時間計劃節點；
在實際項目當中，常常會有人把風險產生的原因當做風險本身，問題雖然不大，但會導致計劃里的風險計劃清單可能會比較長，給人一種，這個項目的風險也太多了吧，還能正常完成嗎的錯覺。所以，今天就以軟件測試項目中的常見風險為例，來做個風險管理計劃。
【風險】：
測試執行時間被壓縮，產品還未經過充分測試就發布上線，導致上線后用戶投訴增多（70%）
【原因】：
1、產品需求出來的晚，而且也不完善清晰，多次反復評審的時間擠占了研發時間；
2、開發自測不充分，導致提測的版本質量不高，影響正常測試計劃進度；
3、Bug 修復速度慢，阻礙了完整的新功能測試和最后的回歸測試；
4、中后期需求頻繁變更，或者是新增需求，導致測試資源被分散；
【應對方案】：
1、優化測試用例的設計，減少冗余的和無效的測試用例，同時提高自動化腳本的覆蓋率，節省出相應的人力用于新功能的驗證測試；
2、制定測試包的可接收標準，編寫 ATC （Acceptant Test Case），沒達到可提測標準的一律退回，采取這種倒逼的方式，讓開發提高自測質量；
3、和開發負責人明確 Bug Fix 的要求，每天幾點之前要日清當天的 New Bug，同時，測試任務包盡可能拆解的小一些，獨立一些，在某些模塊出現阻礙性 bug 時，可以略過先去測試別的模塊；
4、在做測試任務量評估時，預留10%~15%的 Buffer，用于應對需求變更和臨時新增需求；
在實際的項目中，風險管理其實也是需要漸進遞推的，在項目計劃階段，對于很多風險其實只是預估和猜測，它們可能發生，同理，也可能不會發生。
因為當時所處的時間位置，離項目結束還很遠，有效的項目信息也比較少，很難看清風險的虛實。
只有當項目開始進行了，隨著時間和進度的推移，離風險發生的時間位置越來越近，同時，項目信息也越來越豐滿了，才能更加清楚地看到相應風險是否會如期發生，到那時候，當初計劃好的應對方案，大多數都需要做一些適時地優化和調整。
所以，我認為風險是隨著項目的推進在不斷變化的，我們需要及時的識別和適時地出手應對，這也是風險管理的難點所在，當然，也是樂趣所在。
《測試路上你問我答》里的 Q&A 60，如果是你要的，甚好！如果不是，你問，我答！
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
