測試管理 - 基於產品風險的測試策略

對於測試工程師而言，隨着在這個行業的深耕，逐漸會接觸到一些項目層次的理念和方法論。

風險分析以及風險管理就是其中重要的一項。

風險管理與質量控制實際存在着很是大的關聯關係，也是管理測試的有效理念。

 

 

 

 

1. 什麼是風險

在項目管理的領域內，風險被定義爲：某一事件發生給項目目標帶來不利影響的可能性。

 

在開發新的軟件系統過程當中，因爲存在許多不肯定因素，軟件開發失敗的風險是客觀存在的。所以，風險分析對於軟件項目管理是決定性的。風險管理是項目管理團隊的重要職責，也是促使項目成功的有效辦法，測試管理人員以及整個測試團隊在這個過程中要起到很是重要的做用。

風險分析實際上就是貫穿在軟件工程過程當中的一系列風險管理步驟，其中包括：風險識別、風險評估、風險策略、風險解決和風險監督等。

對大多數軟件研發組織和項目而言，當談及風險的時候，通常分爲兩個方面：

• 項目風險（過程風險）
• 產品風險（質量風險）

咱們首先要將這兩個概念區分開來，由於測試團隊在這兩項風險管理過程當中的任務多是大相徑庭的。

 

1.1 項目風險

項目風險或者叫「過程風險」是圍繞項目按目標交付的能力的一系列風險，好比來自組織方面，人員管理方面，流程方面和其餘方面的風險。

 

 

咱們只對測試工程中常見的風險作一個大體羅列，如：

• 技能、培訓和人員不足；
• 項目團隊成員出現的我的問題，人員流失；
• 組織內部協做不調，缺少有效的溝通渠道；
• 管理流程缺少組織，測試工做的支撐和依賴沒法獲得知足；
• 項目成員尤爲是管理人員可能對測試團隊抱有錯誤的態度和認知；
• 有效的測試方法（好比靜態測試）不受重視；
• 技術支持的缺少致使的測試技術問題；
• 測試時間受到壓縮；
• 交付的代碼質量低下，加劇測試以及返工任務量；
• 產品的缺失配置管理，變動流程等控制手段；
• 離岸團隊的合做效率問題；
• 第三方支持的問題；

以上都是可能影響到測試任務完成的常見項目風險，管理人員須要在計劃階段對風險進行預估，並給出規避方案和應急措施。

 

1.2. 產品風險

產品風險又稱爲「質量風險」，用通俗的話講即爲：「產品交付以後可能帶有的質量問題」。

爲何咱們研發的軟件產品會有風險存在呢？問這個問題實際就等同於問「爲何軟件產品可能會有缺陷呢」？

其實其本質在於「人都是會犯錯誤的」這樣一個論斷的成立。

基於這個論斷咱們又能夠推論出：「由於人都會犯錯誤，因此人開發出來的軟件也就可能帶有錯誤」。

這些在研發過程當中咱們犯的錯誤，遺留在產品中，就是缺陷；缺陷存在的可能性，就是產品風險。

產品風險產生的緣由，可能有如下這些：

1. 產品大小/代碼量：工做量越大，那麼咱們就越有可能犯錯。
2. 技術因素：不曾使用過的新技術都存在風險。包括未使用過的新型硬件、支持軟件，缺少標準與規範的非傳統的開發方法等。技術過期也是風險。
3. 開發環境：適用的開發工具不足、不可靠、使用不方便等因素，都會下降開發效率。
4. 組織規模和人員經驗：好比人手不足，人員經驗不豐富，都有可能帶來產品風險。
5. 客戶因素：表如今客戶需求常常矛盾，不瞭解客戶的特殊須要，客戶不瞭解項目中採用的新技術，且雙方又難於溝通等。

在軟件研發領域，經過測試過程發現而且解決問題，實際就是產品風險的最重要和直接的規避手段。

換言之，軟件測試就是產品風險管理的重要手段，也即產品風險控制的有效辦法，甚至有些組織會將軟件測試從組織架構上歸入風險管控部門。

常見的軟件產品風險有以下類型：

• 軟件的故障頻發；
• 軟件/硬件對我的或公司形成損害；
• 軟件特性低劣，好比性能低下；
• 數據完整性不足；
• 既定的功能未被徹底知足；

等等。能夠看到，以上的軟件產品風險，咱們軟件測試的活動和任務都有可能對他們進行評估，而且經過信息收集和事件報告等手段實現規避和控制的目的。

 

2. 項目風險管理

風險管理通常經過下面四個階段來完成：

1. 風險識別
2. 風險評估
3. 風險緩解
4. 風險監控

 在進行風險管理的過程當中，要把握好四個原則：

• 可避免的風險，採起好的過程管理和流程控制來應對；
• 不可避免的風險，採起下降和轉移的措施；
• 作好風險管理計劃；
• 作好應急方案；

 

咱們列舉一下測試過程當中可能存在的風險和對應的可行舉措：

對於測試過程風險：

• 需求的計劃外變動
  • 作好變動控制和配置管理
  • 爲可能的變動預留時間和人員的調整空間
• 測試用例執行率不足
  • 平常跟蹤全部工做過程，及時發現阻礙測試執行的因素並協調解決
• 測試分析產生誤差
  • 更完善的測試分析流程，對於經驗不足的人員安排指導
  • 用評審的手段予以檢查
• 測試用例設計不足
  • 更完善的測試分析流程
  • 充足的人員技能培訓和指導
  • 用例評審的把關
測試與生產環境差別
• 儘可能縮小測試環境與生產環境的差別，好比使用更大的數據量
• 更強的客戶響應以肯定用戶生產環境的特性
• 偶現類問題
  • 倡議充分的問題記錄和分析流程
• 代碼質量太低
  • 更好的單元測試實行
  • 倡議和創建規範的提測控制流程
• 迴歸測試覆蓋率不足
  • 適合的迴歸測試策略
  • 自動化的迴歸測試覆蓋

 

對於人員風險：

• 人員流失
  • 積極響應人員訴求
  • 創造更積極的工做流程及環境
  • 作好人員技能儲備
• 人員不可用狀態（休假等）
  • 創建良好的文檔歸檔流程
  • 創建完善的工做後備機制（不可以讓某項工做只有某一我的能完成）
  • 協調完備的人員抽調機制
• 新人工做準備
  • 創建良好的人員培訓機制
  • 創建幫助新人融入的導師機制
• 外包人員管理
  • 控制項目團隊中外包或兼職人員的比例
  • 與外包人員保持足夠的溝通和把控
  • 與外包公司保持足夠的管理聯繫

 

能夠看到這部分項目風險預估和應對的內容，更多的出如今測試計劃以及一些項目籌劃會議上，應劃歸爲項目管理範疇。

 

3. 基於風險的測試

上文提到，項目風險須要經過管理手段和策略來緩解規避。

那麼產品風險呢？長話短說：測試（質量控制）就是下降產品風險的行之有效的手段。

 

 

正由於如此，因此以風險爲基準來制定的策略是測試領域內很是重要也很是普及的一種方法。

這就是所謂的基於風險的測試（Risk Based Test - RBT）。

常見的測試策略可能有：

• 分析型策略
• 基於模型的策略（如：基於運行概況分析的測試） ·
• 符合過程或標準的策略（如符合OWASP標準的web安全測試）
• 應對型策略（如：探索性測試）
• 諮詢式策略（如：外部機構測試）
• 面向迴歸測試策略（如：自動化迴歸測試）

而基於風險的測試就是典型的分析性策略。

正如咱們前文中提到的項目風險和產品風險的區別，基於風險的測試是基於「產品」風險而非項目風險。經過對於產品不一樣區域和特性可能遺留缺陷，以及其影響程度的分析，肯定測試的資源分配等問題。

基於風險的測試策略之因此有很大的應用價值，是基於如下幾個基本論斷：

1. 事有輕重緩急，對於測試工程而言，並不是全部被測對象和模塊都具備同等的重要程度。
2. 測試不可窮盡，測試成本和錯誤成本處在天平兩端，用更少的資源和成本覆蓋更多更重要的測試目標是測試管理的重要訴求。
3. 缺陷具備集羣性，經驗而論，對於缺陷集中的模塊投入更多的測試關注度和資源能夠最有效的發現最多的缺陷，從而帶來質量的快速提高。

 

 

下面咱們經過一個簡化版的RBT實例來論述其組織實施過程。

某稅務處理系統

• 該項目爲一個COTS產品的定製性二次開發項目
• 項目週期計劃爲4個月
• 採用持續集成，高速迭代的研發方式

①風險識別：識別出軟件研發過程當中，可能產生缺陷的區域，包括功能模塊和專項問題，羅列以下：

這個風險識別的過程，能夠依靠專家的分析，好比測試經理和開發組長、項目經理等的討論，可是更多的狀況下應該依靠集體智慧，條件容許的話項目全部利益相關方，都應該參與到風險分析的過程當中來。在風險識別這個動做上，頭腦風暴是一種可行的方法（即與會各方各抒己見，提出本身認爲產品可能有的風險項）。

除了頭腦風暴法之外，更爲嚴格的風險研討會議，經驗總結會議，第三方獨立評估，問卷調查法都是可使用的風險識別方法。不一樣的人員處在不一樣角度和專業背景下，對於風險的識別和分析等能夠提供更全面專業的思路。

 

②風險評估：在風險評估過程當中，咱們要對上個階段列出的風險項目作出評估，得出風險高低大小的一個排序。

風險評估中須要考慮的兩個維度：風險發生的可能性大小，以及風險若是發生，帶來的影響範圍和嚴重程度。兩個維度結合起來，才最終定義一個風險項目的級別高低。

所以，首先須要肯定咱們對於這兩個維度以及風險級別之間的判別關係，採用風險定義矩陣是一個比較好的作法，好比採用以下風險分析矩陣：

 

將識別階段得出的風險項目列表進行兩個維度的風險判斷，得出以下結果：每個風險項都從兩個維度給他’高、中、低‘的判斷，得出下表：

 

 

按照風險分析矩陣，進一步整理：

 

  

到此爲止咱們已經獲得了風險評估結果列表，可使用風險追蹤表格管理起來。

在這個評估過程當中，只是使用簡單的高中低三個級別的劃分對於風險進行評估。若是須要更爲精細的評估，也能夠採用更爲細緻的評分方式，而且對於風險的發生機率和影響度能夠分開進行更爲嚴格的評估，好比使用下表進行的發生機率分析：

 

 

 同理對於另外的影響範圍和嚴重程度，也能夠作出相似的分析評估。

最後使用（可能性X影響）的公式得出風險項目的最終級別。

 

③風險緩解

基於產品風險分析，測試管理人員能夠在測試活動的安排上，實施緩解措施：

肯定測試優先級

根據測試風險的分析和評估獲得的風險分佈，肯定測試的優先級。如上例中，將風險級別最高的三個項目定位最高優先級，優先進行測試分析、設計和執行。其餘項以此類推。

肯定測試完備性

前面提到的一個假設條件：並非全部的測試對項目而言是同等重要的。一樣的道理，並不須要對測試對象的不一樣內容進行同等重要的測試，最重要或者風險最大的模塊或者對象須要測試得更加完全，更加完備。而對於風險比較小、優先級低的模塊或對象，能夠簡單測試。對於優先級最低的對象，在時間和成本等不容許的時候，甚至不進行測試。

爲達到更高的完備度，能夠採用更爲嚴格的測試分析、設計，更爲全面的執行和測試覆蓋。

測試資源優化分配

根據測試風險的分析和測試優先級的評估，將經驗豐富和技術能力豐富的測試人員（無論是設計人員、實現人員，仍是執行人員）放在最重要的模塊或測試對象中，能夠達到以下效果：

• 設計更加完善、完備和準確的測試用例。
• 實現高質量的測試用例腳本和代碼。
• 更加高效地發現測試對象中的缺陷。

這種基於風險的測試策略能夠很是有效的幫助測試團隊快速實現重要模塊的測試覆蓋，而且能夠有效的快速提高產品質量，進而帶來利益相關方的信心提高。同時，對於測試監控而言也是很是有幫助的。

 

④風險追蹤

風險分析不是一個一次性的工做，須要持續追蹤。經過在項目實際研發過程當中獲得的信息和反饋，對風險等級進行調整，好比調高和調低風險等級。

一個實際的例子是：當項目開始時，將某一個風險項目定爲了高級，所以這個風險項頗有可能引發了團隊的重視。而正由於團隊對這個風險項目很重視，以致於在後續工做開展過程當中，團隊投入了更多的資源和力量，致使最終測試階段可能反而在這個模塊裏面沒有發現太多問題，也即他真正展現出來的風險等級並無預計的那麼高。當發現這樣的現象時，應該對風險跟蹤表作出及時更新。

風險級別的更新能夠是即時的，即發現現象則對應更改；也能夠是階段性的，好比每週一次，對於風險項目進行更新和調整。

風險級別一旦發生調整，測試活動的安排也應隨之相應調整。

 

4. 總結

風險的控制，在企業生產和管理中是被廣爲接受和採納的理念。

對於軟件產業而言，產品質量風險的緩解很大程度依賴於測試工做所提供的質量控制（QC）。

也許並非全部測試人員都會採用如本文所述的精益化的風險管理過程，但無論是對於測試管理人員仍是測試技術人員而言，風險的觀念都是不可或缺的。

不論採用怎樣的測試過程，都應採用風險管控理解來編排工做，抓住重心，這樣才能將有限的（有時很是有限！）測試時間合理投入到無限的任務中去。