文/秋之川

【目錄】

這是《落葉》文集里第 *328 *片落葉，希望你能喜歡，不為別的，只為這份堅持。

第十三章 管理測試項目中的風險時應該關注些什么？

結合著老大給我的實例，我也自己參看了一些理論書籍，對于測試項目的風險，有幾點是我應該重點關注的：

1. 影響結果
   （1）指的就是這類風險最終會導致的結果是什么，項目延期？發布后缺陷率上升？還是項目成本的增加？
   （2）只有明確知道了最終的影響結果，我們才可以判斷該風險的嚴重性是高還是低；
   （3）只有判斷出風險的嚴重性，我們才能決定是否有制定應對方案的必要；
2. 應對策略
   （1）在實際的項目中，多數風險可能會發生，也可能不會發生，存在一定的概率，所以我們需要根據歷史項目經驗和相關的項目數據，來判斷該風險發生的可能性；
   （2）當項目開始了，隨著時間和進度的推移，離風險可能發生的時間點越來越近，項目信息也越來越充分，那時候會更加容易地判斷風險發生的可能性；
   （3）降低風險所產生的影響結果是風險應對的一種手段，這個是我們最常用的，也是最容易采取的一種策略，比如說通過增加人力，優化流程來，減少需求變更等手段來將降低項目延期風險的影響；
   （4）轉移風險也是風險應對的一種手段，就是將可能有嚴重影響的風險轉化為影響較小的風險，從概念上來看，覺得有些難搞，但實際上我們在項目中經常采用這種策略，我舉個例子就清楚了：

   比如在項目的中后期，臨近上線了，發現一個低概率碰到的程序 Crash Bug，要不要修復呢？
   （1）如果要修復這個 bug，需要動到功能模塊的底層庫，測試需要做一輪 Full Regression Testing;
   （2）但因為臨近發布時間了，所以沒有足夠的時間去做，只能針對問題發生的周邊范圍做一輪簡單地回歸;
   （3）這里的風險就是可能會導致較為嚴重的 Regression Bug 被漏到線上，這就是很嚴重的風險。
   （4）我們一般碰到這種問題，都會怎么應對呢？肯定是將這個 Bug 延期到下個版本修復：

   • 首先，下個版本會有足夠的時間做一輪充分的回歸測試；
   • 其次，本身那個 Crash Bug，用戶碰到的概率就很低，這個風險就較低了；

3. 應對方案
   （1）應對方案的制定，我認為應該是隨著項目進度的推進而從粗到細的，因為在項目剛開始時，有效的項目信息比較少，對于風險發生的可能性判斷準確性比較低；
   （2）項目開始時根據風險發生的可能性制定粗細不一的應對方案，等到風險清晰可見時再做一些優化和適時的調整，性價比會更高些；

最后，就我經歷過的項目，我認為我們需要很清楚的認識到：絕大多數風險都是不可消除或者說避免的，如果說某個風險我們提前就知道怎么能不讓它發生，那它就不應該算作風險。

風險最大的特點應該就是它的“不確定性”，而且，正因為風險的不確定性，我們才需要及時的識別并出手應對，這既是風險管理的難點所在，但也是其樂趣所在。

《告訴你如何從執行測試到管理測試》帶你邁出第（13）步！，點擊這里可查看完整地圖

作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵

【目錄】