與軟體測試專家對談 @ 老實念佛，以戒為師

與軟體測試專家對談

Sametime的測試專案經歷
蔡為東（作者，以下簡稱蔡）：請和我們分享一下你印象深刻的專案。

IBM測試經理陳雅麗（對談者，以下簡稱陳）：我做Sametime 時間長，讓我印象深刻的專案也來自於它。Sametime 現在仍然在做版本的升級開發，產品壽命時間很長。你知道，對於一個軟體產品來說，在這麼激烈的競爭環境下，有10 年的壽命就很不容易，這就相當於人的長壽了。當初Sametime 是Lotus 買的另外一個公司的產品（後Lotus 又被IBM 收購），是關於聊天和會議的整合式軟體，在同類產品中是很先進的，因為它提供了線上溝通和會議並行的解決方案。

產品從Domino遷移到WebSphere
陳：2005 年，Sametime 做了一個很大的底層改進，從基於Domino 服務遷移到基於WebSphere server。這是一個很大的變化，相當於要做一個全新的產品。那麼，對於測試初期來說，最困難的工作是把測試環境建立起來。不然的話，測試沒法進行。在建立基於WebSphere 的測試環境的時候，我們遇到了難題，因為產品的品質和我們的技術能力的原因我們怎麼也作不起來。

怎麼辦？專案的進度是有要求的。我們當時把人分成兩組，一組人白天工作，一組人晚上工作。美國方面，一個QE 協助我們，幫助我們和美國的開發人員交流。但是，兩周的時間過去了，這個Deployment（部署）的難題還是沒有解決。

後來，終於有一個人率先把環境建立起來了。我們回過頭去分析，是什麼原因讓我們這麼長的時間沒有把環境建立起來呢？除了產品的不穩定和新技術的缺乏，我們還有自身的原因。當時我們有一個Setup 文件，裡面有詳細的步驟，工程師要去一步一步地去Follow，更重要的是要理解做每個步驟的目的。我舉個例子，有的步驟要求在host file 中去設置hostname，但是要保留空值，有很多的人看到這一步的時候都會憑自己的經驗去做一個判斷，然後按照習慣新增上主機名稱。這個小小的舉動，導致了全域的失敗。所以，第一個把環境建立出來的人，是一個優秀的測試工程師，他沒有被自己的經驗所誤導，而是理解為什麼要這樣做。他首先明白自己為何要這樣做，而不是簡單的照搬。

測試要根據實際情況做相應的調整
蔡：在這個Project 當中，你有什麼體會和經驗的總結？

陳：前面我提到了，這個專案中Sametime 做了一個底層的改變，並且是很大的變化，所以在某種程度上成為了一個新的專案。那麼，對於新專案，測試工作就要做相應的調整，去做配合。

對於成熟的產品，測試案例可以是那種大Scenario的，就是一個案例包括了很多步驟，相當於把代表客戶的使用場景走一遍。這種辦法拿到新專案來不行，因為專案在有了很大的變化之後，Bug 就會多一些，這樣你的Scenario 案例可能就會全部失效。在測試報告中，全部失敗既給開發方面施加了很大的壓力，也沒有表現出實際的專案進展，開發肯定會有所進展的，怎麼會一點進展都沒有呢？所以，對於新的專案，測試案例要細分到更小的功能點，這樣測試的結果中就有成功的，也有失敗的，這才是真實的研發進度。也能幫助開發人員瞭解他們的開發品質。

更重要的是合作
陳：另外，我們知道，測試是前後連貫的，有的時候測試案例前後有依賴性，一個失敗了，後面可能就全部被Block 住了。

蔡：對，這種情況下有的測試經理會偷偷笑，反正責任在開發方，就發一個報告出去，表示測試無法繼續，然後就等著。

陳：這樣有點像踢皮球，測試完全把事情推回給開發方。是不是真的沒有辦法繼續測試？測試方應當去找找Workaround，因為可能會有辦法繞過這一塊，從而讓測試繼續進行。在產品研發中，重要的是合作。我們隨時都要想到，怎麼才能推動專案的進展，而不是互相推脫或抱怨。

測試方如果在開發遇到問題的時候，旁觀等待，這樣會造成研發團隊內部的不和諧，也會影響工作的效率。我們去幫助開發，其實也是在幫助自己。你想，如果開發方延遲了交付，到最後一周才把可以測試的Build 做出來，測試的風險是很高的。

在這個專案上，我同樣感受到交流的重要性，在做軟體測試的專案中要多做有效的交流。

Sametime的Client端從C++到Eclipse的測試專案經歷
蔡：還有沒有印象深刻的專案？您這邊的經驗是非常寶貴的，我及讀者朋友都願意知道更多。

陳：好。這個專案同樣來自Sametime。具體時間我一下子說不準，那次是Sametime 的Client 端發生了很大的變化，從用C++ 程式設計移植到用Eclipse。另外，也新增了一百多個新功能。

新的開發工具加上新功能，這個專案的前期不大穩定。有的功能不穩定，有的功能甚至在不同的Build 裡時有時無，就是說這個Build 有，那個Build 沒有。

蔡：這對測試是個很大的挑戰啊，測試總是期盼一種穩定的狀態。

不要把時間浪費在等待上
陳：對，測試人員也感到很迷惑，這怎麼測試，因為沒有一個設計文件或需求文件可以參考？感覺沒有辦法開始做。測試專案天生就有些被動，在這種情況下，怎麼去進行控制？這是個問題。但測試肯定不能等，於是我去提醒team leader，無論如何不要等。等待的風險是很高的。

首先，我們主動和美國的開發人員交流，讓他們瞭解我們測試的困惑，希望能得到一個相對完整的功能列表。然後做測試，把發現的Bug 儘早交付上去。因為這些問題也是一個回饋，專案管理人員會根據這些回饋，而對專案計畫做一些相應的調整和修改。管理層可以根據當前測試的狀態，決定新功能的刪減，並評估專案計畫和時間。

有了問題，如果我們解決不了，一定要回饋到上一級。