對于測試團隊而言，測試中途接手的項目和產品，存在很多的風險和挑戰。本文首先從測試的角度闡述中途接手項目測試可能存在的風險和挑戰;然后根據筆者的經驗和知識，提出測試方面的建議，以幫助測試人員更好的開展此類條件下的測試活動。
1)風險和挑戰
(1)項目測試經驗欠缺
對于中途接手的項目，測試團隊首先面臨的一個挑戰是缺少當前項目的測試經驗，至少是不熟悉項目，例如：系統的整體設計架構、實現的主要功能、客戶的關注重點、系統的測試平臺、系統使用的測試工具、系統配置和管理的命令、系統中主要的缺陷分布等。項目中這些信息和知識，都需要測試團隊花費很多的時間進行學習和理解。測試團隊中盡管有的成員可能對系統功能有些經驗和知識儲備，但是對于該項目而言，測試經驗方面肯定是欠缺的，或者是缺乏經驗的。
(2)開發測試文檔不全
中途接手的項目，測試團隊面臨的第二個問題是：原有的需求文檔和測試文檔可能不全，甚至沒有，例如：由于軟件開發的成熟度低下，或者由于項目移交的時候沒有將相關的文檔成功交接。而后續的測試工作需要詳細了解以前項目版本的需求和相關的測試文檔，從而可以深入學習和理解以前項目的基本功能。
對開發團隊而言，沒有原始的需求文檔也是一個非常大的挑戰。首先，開發人員只能通過研究軟件的代碼來理解系統的功能和實現。而對系統各種可能的數據輸入都進行研究是不現實的，并且也很容易遺漏一些復雜的功能實現。其次，開發人員在面對特定輸入情況下系統產生令人迷惑的輸出，開發人員可能會想當然的認為系統就是這樣實現的。令情況更糟的是，開發人員在確定系統正確的輸出和工作方式過程中，并沒有進行相應的文檔化，而是在這基礎上直接進行代碼設計，導致這種猜測循環經常持續，從而使需求的收集和文檔化更加困難。
而對于測試團隊來說，同樣面臨嚴峻的挑戰。雖然從表面上看，在已有系統上進行測試，測試人員可以通過比較以前軟件的輸出和新的軟件輸出結果進行對比。但是，基于不同版本輸出結果進行判斷并不總是安全的，例如：原來系統的輸出就是錯誤的�；谶@樣的判斷，測試人員就會遺漏系統中的一些缺陷�；蛘�，原來系統實現的功能是不正確的，而在新的系統中，由于增加或升級了軟件修改了原來代碼的缺陷，其輸出是正確的�；趦烧咧g的比較，測試人員會認為新的系統由于代碼的修改引入了缺陷，而提交了不應該提交的缺陷報告。假如開發人員修改了本來是正確的代碼，新的軟件中又引入了新的缺陷。原本應該在需求階段確定的預期結果的判斷，落到了測試人員頭上。
(3)不穩定的測試對象
在很多時候，項目在移交之前可能已經交付給客戶使用了，后續的開發和測試會在用戶版本的基礎之上進行一些維護工作，例如：新功能的添加、缺陷的修改、系統架構的更改、新技術代替老技術等。在這種情形下，整個系統看起來更象是移動的不穩定的實體，這樣導致的結果是新的系統一直處于多種開發狀態的混合體，它們會經歷不同的生命周期階段，是個不穩定的測試對象。
(4)測試工作量的估算
由于中途接手的項目經常處于不穩定的狀態，導致測試工作量、測試進度、測試人員和資源的估算更加困難。測試工作量的估算只能是基于對系統功能的粗略理解，而所謂的系統功能甚至可能是錯誤的，或者系統在維護過程中功能經常發生變更。對于測試估算而言，即使有詳細的需求文檔的情況下，也是一件非常困難的事情。因此，對中途接手的項目，由于其不穩定的特點，進行測試工作量的估算，將是難上加難的事情。
(5)回歸測試用例選擇
對于中途接手的項目，后續的開發和測試是基于前面的軟件版本而展開的。針對開發活動而言，后續的開發主要是指軟件版本新功能的增加、版本的升級、平臺的升級，以及前面版本中遺留的缺陷的修改等。而對于測試活動而言，后續的活動主要是驗證新增功能是否符合系統的要求、確認是否滿足客戶的要求、確定缺陷是否已經修復以及新增加的功能和缺陷修復沒有在原來系統中引入新的缺陷。因此，對于中途接手的項目，測試團隊的很多測試工作將關注在由于軟件變更而進行的回歸測試。
在中途接手的項目中，回歸測試在整個測試活動中會占有很大的比重。因此如何選擇每次測試的回歸測試用例，對于測試團隊而言，也是一個很大的挑戰。由于前面提到的測試項目經驗欠缺和開發測試文檔的不全，導致測試團隊很難進行測試風險的估算，從而很難確定回歸測試的重點和優先級，影響回歸測試用例的選擇。
(6)項目知識的轉移
中途接手的項目，還有一個很大的挑戰是項目相關知識的轉移，例如：系統、開發和測試相關知識的轉移。項目是從一個研發中心轉移到另外一個研發中心，由于語言、文化和習慣的差異，在知識轉移過程中，很難實現無縫的轉移。由于測試團隊中本身對項目的測試經驗的不足，導致相關知識交流方面會更加困難。
2)經驗和對策
從測試的角度，上面談了中途接手項目中存在的7個主要風險和挑戰。雖然存在比較多的困難和不確定因素，測試人員還是可以利用已有的測試經驗和知識，采取一些合適的手段和方法來應對這些問題。
下面根據筆者在中途接手測試項目方面的經驗，對上面提到的這些問題提供一些參考的信息和建議。這些建議并不是肯定適合的，在進行具體項目的時候，還需要考慮不同企業組織和不同項目的背景。同時，下面的經驗并不是對應解決上面的每個風險和挑戰，而是從整體上對如何進行中途接手項目的測試提供了一些實踐。
(1)合適的測試經理或專家
對于測試工作而言，測試經理應該是整個測試團隊的靈魂，對于中途接手項目的測試中體現的尤為明顯。中途接手項目中，測試團隊的測試經驗相對欠缺，因此測試工作的計劃、估算、執行以及控制等尤為重要，因此需要更加慎重的選擇合適的測試經理來領導這樣的項目。合適的測試經理，除了需要具備的一些能力和知識外，例如：熟悉測試過程、具備測試管理能力等，針對中途接手的項目測試，測試經理具備下面幾個方面的能力也非常重要：
ü 測試經理應該對項目產品相關的功能、協議等有很深厚的經驗和知識，能夠從全局上把握軟件產品的風險、測試的重點和優先級。在項目測試初期，最好能夠在測試團隊中能夠起到知識方面的引路人;
ü 測試經理應該有良好的溝通能力，包括對內溝通和對外溝通。由于項目是從國外研發中心轉移過來，因此需要測試經理有很熟練的英語溝通能力。
對于有的組織和項目而言，測試經理并不是技術方面的專家。那么，在面對中途接手的項目測試中，測試經理需要選擇產品相關的測試技術專家(測試領域的專家，例如：數據通信領域的專家)對整個測試過程中的技術進行把關。協助測試經理進行測試活動的計劃、估算、協調和控制，同時幫助測試經理進行測試團隊的構建和發展，使得測試團隊能夠勝任中途接手項目的測試。
(2)合適的軟件測試過程
選擇了合適的測試經理或者測試專家，基本上可以保證測試團隊對測試工作的適應性。測試質量中除了人的因素外，另外一個很重要的因素是過程的因素。測試質量的提高和保證，需要一個完善的測試過程來控制和保證。
當然，軟件測試過程的選擇，需要考慮企業組織的成熟度和測試項目的特性。一般來說，測試過程包含下面幾個階段：測試計劃和控制、測試分析和設計、測試實現和執行、測試出口評估和報告以及測試結束活動。
測試過程定義中，需要明確每個測試過程階段的輸入和輸出、每個測試階段的主要測試活動以及每個測試階段中的質量檢查點。明確定義軟件測試過程以及相關的測試活動和輸出，可以從制度上保證測試工作的順利進行，并且可以有針對性的進行測試活動的控制。軟件開發的產品質量是通過整個開發過程的質量控制來保證的。同樣，測試質量也需要測試過程質量來保證。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
