喲哪桑在《產品歷史愈悠久，測試工作也愈多？》一文中，試圖回答讀者老軟體測試包袱的問題。
我雖然認同喲哪桑的解法，因為他的解法確實具體可行也能解決問題，但我提出了與喲哪桑不同的解法-「測試最小化」。
讀者的問題和喲哪桑回覆
喲哪桑你好：
目前我正參與了一個老產品的專案。我們正要推出這個產品的下一版。這個產品的歷史很悠久，正在使用它的顧客人數眾多，裡面也累積了數量龐大、而且歷史悠久的程式碼，因此，即使正在開發的這個新版本，其實也只是加上幾個小功能，但是我們的QA卻還是得要花上三個月來做測試，比我們開發的時間還要長！我現在只好到處去調人來幫忙QA。可是，這測試動不動就要三個月，難道歷史愈悠久，測試要更長，怎麼會這樣呢？除了加人，我還有什麼其他的辦法呢？
Young
喲哪桑認為可以有兩種做法：
- 第一，用人海戰術來對付，並搭配教育訓練、SOP 或者是 checklist 的運用，以提高測試覆蓋率、減少漏檢的機率。
- 第二，導入測試自動化 (test automation)。
通達人的「老軟體測試包袱」解法 Resolved Testing Burden
我雖然認同喲哪桑的解法，因為他的解法確實具體可行也能解決問題，但我試圖提出不同的解法-「測試最小化」。
「測試最小化」的目標就是儘量使用有限的資源，測試優先項目，而不測試未被影響的低優先、非必要項目。
但要作到我所謂的「測試最小化」，得先導入 SCM (Software Configuration Management) 制度，再藉由 REQM (Requirement Management) 了解每個版本的變更輻度，接著釐清該系統的核心功能，最後重新調整測試策略。
第一步：導入 SCM 制度
所謂的 SCM，中文翻譯成：軟體配置管理、或軟體組態管理）。簡單地說：就是對某個軟體內的每項功能的每項變更進行管控，並維護每項變更所影響的版本變更關聯，使軟體在開發過程中任一個時點的任何一項變更內容都可以被追溯。
但要作好 SCM，至少得先作好 RC（Revision Control，版本控制）再整合 REQM（需求管理），才能把這兩項資訊綜合在一起變成最後的 SCM。
但光是要作好 RC 和 REQM，對某些公司而言就是一項嚴苛的挑戰。
以 RC 來說
和 REQM 相比，算是比較簡單的部份。安裝任何一套免費的 RC 軟體（如CVS、SVN、Git、或SVK），再搭配一套 Issues Tracking 軟體（如Bugzilla、Bugfree、Redmine），就能架設好版本控管的「硬體」。
但困難的地方是安排「軟體」，也就是相對應的配合機制，如：
- 把Programmer 的 Local Space 清空，改採 Repository 內的版本；
- Checkin版本時要求加入Requirement、Issue(Bug) ID 及註解；
- 加入協同開發的制度與習慣，讓多個成員能併行開發；
- 依照程式的成熟度對 Repository 分層，以避免影響到已經驗證過的程式。
以 REQM 來說
在台灣的軟體業界，這個就更難了。
從提出需求的客戶開始，客戶通常對自己的需求不一定能完全了解，如果再加上未指派有相關經驗的人作為Contact Window、或是 Contact Window 有自己的業務無法兼顧專案，又加上客戶「通常」會大輻改變需求、不願依需求追加預算、甚至恣意縮減專案時程，種種的行徑都讓接案的業者吃不消。
從軟體業者的觀點來看，如果配上低價搶案，因為成本的考量又急著將專案結束，以致未在初期花心血需求訪談、急就章的架構設計、缺少完整的需求管理的機制，再再都使需求在開發過程中漸漸發散到難以控管。
最後的結果就是大家看到有很多專案都落得結不了案的下場。
老實說，要作好需求管理，從瞭解需求、取得需求承諾、管理需求變更、到維護需求的雙向追溯性，確實要花不少人力、成本；但不作需求管理的結果，只會讓軟體專案更難管理，越到後面越難收拾。
第二步：從 SCM 追溯影響輻度
有了 SCM 提供的資料，就可以從中去推估每個版本的影響輻度。
例如：產品 XYZ 的 v1.2.3 專案中有：
- 新功能 K
- Bug A、B
我們把上述功能、Bug所影響到的 Test Case 作為範圍時，可以用示意圖說明影響到的範圍（圓形的部份為XYZ全部範圍）。
假設我們修正的 2 個Bug中：
- Bug A需要修正 2 支舊程式A1、A2，而A1、A2除了Bug A的Test Case 外，還有各自其他的變動（Bug、功能修正）及其Test Case（A1'、A2'）；
- Bug B需要修正3支舊程式B1~B3，而B1~B3除了Bug B的Test Case 外，也各自有其他的變動及其Test Case（B1'~B3'）。
另外，新增功能 K 中：
- 新增3支程式K1~K3僅包含此次變動的Test Case；
- 修正舊程式3支K4~K6，而K4~K6除了功能K的Test Case 外，也各自有過去其他的變動及其Test Case（K4'~K6'）。
我們可以用示意圖說明上述內容中所有被影響到的部份。
第三步：釐清核心功能
另外，我們也需要重新對所有的 Test Case 分類，以區分出 Test Case 的重要性。
因為每個系統的功能不同、差異也很大，所以很難一概而論的說有什麼原則可供參考。但我通常會用「該功能的失效是否影響系統的主要功能」作為判斷依據。
簡單地說，如果某個功能掛了，系統也就跟著失效或停擺，會使出貨系統不能出貨、薪資系統會計算錯誤、出勤系統無法正確記錄打卡時間，那這個就功就算是核心功能。
另外，如果以功能數的比例來看，核心功能的數量不應該超出所有功能的20%，因為依照「80/20法則」來看，「80%的結果將取決於20%的少數功能」。
如果我們再把這些核心功能 C 納入，並以示意圖表示時，就可以看到以下的圖。
第四步：調整 Test Strategy
在 Test Plan 中，通常有一項很容易被忽略的 Test Strategy。
一般人可能會想測試需要什麼 Strategy？不是每個版本都要 Fully Testing 就好了？但事實上，在某些情況 Fully Testing不僅作不到、沒有必要、有時甚至浪費時間。例如：在經過幾輪的測試後，可以很明確地知道某個 Build，只改了少數的地方；又或者是某些只是改介面的 Title 的修正。
因為就現實面來看，除非是個重要到每年都有編列固定維護預算的專案，不然通常每個專案的維護預算都會逐年刪減、甚至是直接刪除。在資源排擠的情況下，要應付與日俱增的 Test Case，即便採用了自動化回歸測試，也仍然會有資源的限制，和無法採用自動測試的項目。
所以我的建議方式就是對所有的 Test Case 標記測試的優先次序和必要項目，再設定可能會遇到的情況、以及該情況下需執行的優先次序和必要項目。
以發生錯誤的機率來看，我們可以把上述的項目，依重要性的高低由上而下排次序，重疊的部份則以重要性高的為準，變成以下的情況：
但採用這個方式排列測試的優先順序卻有個致命的缺點。若最重要的核心功能 C 沒通過測試，即使新功能 K 或 Bug A、B 通過測試了也沒有用，因為核心功能 C 的 Bug 使整個系統都不能正常運作了，所以核心功能 C 的測試順序和必要性應該高過新功能 K 或 Bug A、B。
因此我建議以「失效後的影響結果」作為擬定 Test Strategy 的考量，會是個比較務實的選擇：
另外，在每個版本變動的初期，測試的進度可能趕不上每個新 Build 出來的速度，這時候我建議，可以依照由上到下的優先順序橫跨數個 Build 以掃完所有的 Test Case，之後可以再決定是要依照從上到下的優先順序分別測試每個 Build。
小結
要想出前述的過程比較簡單，但真要作到這些活動，卻不容易。
除了因為這些活動需要花更多的資源管理，還因為這些活動後面需要有一套完整的開發資訊系統支援，以減少人力的需求、提昇這些活動的效率，但光是要建置這套系統就所費不貲，完全考驗開發組織的管理者對於軟體開發系統的決心。
以我的觀察，很少聽到或看到業界真有那間企業，真的能下定決心採購或自行開發、整合這類系統，以改善原本的開發流程。當然這後面自然有企業主在商業上的市場考量。
但即使真的導入了這類系統並改善了開發流程的活動還不夠，在實作時還需要 System Designer 和 Programmer 有相當的經驗，能貫徹Design for Test的精神，在設計系統架構的初期，就長遠地考量到後續的測試活動，才有機會在每一個版本，作到能釐清每個程式的變動後面所影響的範圍。
另外，決定 Test Case 的優先次序和必要項目本身也是個不容易的工作，需要有經驗的 System Analyser 和 Test Manager花時間去釐清，倘若能在更早之前的決定需求階段就釐清這些資訊，會遠比在已開發完成後才回過頭去作來得容易。
所以真要作完整個「測試最小化」，需要不同部門在整個開發過程的不同階段，齊心合力的去作才有可能完成，更別說是要在事前就作大量溝通開發觀念以取得整個開發團隊的共識。
一想到這，我建議這位讀者還是參考喲哪桑的解法好了，他的作法真的比較容易達到。
沒有留言:
張貼留言