IBM測試經理陳雅麗

在IBM測試經理陳雅麗的測試管理理念中,標準和流程處於重要的位置。標準和流程定義,也是測試工作的重要基石。測試是個集體性的工作,不但需要多方的支援,而且測試組內要協調一致,如果出現混亂對測試來說是個致命的打擊。

陳雅麗說,一件事情,既然要做,就要盡自己的所能,從這裡你就可以想像得出她在工作中的嚴格。而據我瞭解,她在換產品組的時候,有她原來的下屬員工申請去她的新組,可見她的魅力。

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 儘早交付上去。因為這些問題也是一個回饋,專案管理人員會根據這些回饋,而對專案計畫做一些相應的調整和修改。管理層可以根據當前測試的狀態,決定新功能的刪減,並評估專案計畫和時間。

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

另外,如果測試等待,等到Build 穩定了才進入,這樣開發方也會抱怨的,因為開發方Fix Bug 的時間少了。

測試工程師要盡全力去做好測試

蔡:在這個專案上你有什麼體會嗎?

陳:首先把工作當做你自己的事情,所以你就會更主動去解決問題。其次,我覺得,無論測試專案的大小,作為測試工程師的我們都一定要認真對待。透過你的手,讓軟體產品的品質有保障。設想一下,如果你能考100 分,但是實際只是得到了90 分,你會覺得冤的。測試是很重要的,對於一個軟體來說,軟體發佈了以後,再修改Bug 的成本是很高的,如你要做Patch,做測試,等等,成本高。當然,在實際的工作中,特別是在中小軟體公司,可能還是有一些朋友不大能理解測試的重要性。

推薦的測試管理方法

蔡:一個測試專案要開展,你有沒有麼推薦的流程或者方法?

陳:流程來說可能公司各有差異,我就說幾點管理方法。

關鍵字:及早介入

第一,測試人員可以及早地Involve(介入)到專案中。如果你在開發後期才進入,直接到了執行階段,就沒有時間去Training,去準備了。

當然,一個組一下子全過去不行,成本太高了。可以先讓幾個技術強一些的人進去,為小組做準備,對專案有一個全方位的理解。這種鋪墊會有利於制訂更合理的測試計畫,並瞭解開發每個階段的工作重點。

關鍵字:團隊建設

第二,Team Setup 也很重要。一個新的測試團隊建立之初,組員之間互相不大瞭解, 這個時候應當擬定一個完整的計畫書, 讓TeamMember 增進瞭解。

有的組員會做一天和尚撞一天鐘,只知道今天做什麼,不知道明天做什麼,這是管理上存在的問題,所以要加強專案的團隊建設,讓每個人都清楚專案的計畫和目標。

關鍵字:讓更多人參與

第三,做測試計畫的時候,可以讓更多的人參與進來,讓大家都有所貢獻,並對測試計畫有一個瞭解。

關鍵字:開好例會

第四,開好例會。每個小組每週都會有例會,泛泛而談Status 也會讓人感到枯燥,因此不要讓你的員工只帶“耳朵”來開會,要讓他們帶著問題來開會。我們要想辦法去改變會議的形式,關注效率和意義。

你要考慮到你要得到什麼,Team Member 他們能得到什麼。如果只是浪費時間地例行公事,不如去Run Case。有的老闆(註:外商中團隊負責人也被稱為老闆)能把大家調動得很好,那就是懂得了其中的技巧和藝術。

關鍵字:調節

第五,測試是重複的,枯燥的,團隊的主管要不定期地調節一下團隊的氣氛,讓團隊保持活力。另外,Leader 和Manager 保持團隊的士氣是很重要的。

關鍵字:做好總結

第六,做好總結。做了一個專案之後,我們拿出一點時間來,把經驗總結出來,這對於下一個專案很有好處。所以,即使是時間緊,也要拿時間出來進行總結。

微軟資深軟體測試經理周慶輝

微軟資深軟體測試經理周慶輝在微軟做測試工作已經超過10年,他提醒各位測試工程師要有程式設計能力,在學習的時候要以開發工程師的標準來要求自己;並希望測試團隊的管理者要去瞭解公司的商業目標。他建議在中小軟體公司做軟體測試的朋友,在制訂測試方面的流程的時候,要具體情況具體分析,而不要照搬大公司的做法。在實行自動化測試方面,也是建議大家逐步推行,量力而行。

Windows Media Player的測試專案經歷

蔡:請你舉例說一下你印象深刻的專案。

微軟資深軟體測試經理周慶輝(對談者,以下簡稱周):我在美國微軟總部雷德蒙的時候,當時是以做技術為主,Windows Media 是一個有代表性的、令人印象深刻的專案。

從一般意義上講,測試對開發的確有一定的依賴性,但在這個專案組中,我體會到,測試不是純粹被動的。例如,如何來證實產品的正確性。我們當時就遇到了挑戰:如何確定播放出來的音樂是正確的?如何確定播放出來的Video 是正確的?

我們可以做自動化測試,可是自動化的難點是Verification(驗證)。我們可以事先準備一段特殊的Video,但是如何驗證在做自動化測試的時候它被正確地播放了呢?如何排除Noise 呢?如何去開發測試工具,不光是測試團隊用,開發團隊也可以用?這些都是挑戰。

蔡:的確,驗證聲音和影像播放的正確性的確挺難的,那又是怎麼解決這個問題的呢?

周:那都是多年以前的事情了,我以播放Video 為例。我們在測試中需要驗證Frame rate 是否正確,內容是否正確等等。我們是這麼做的,把畫面劃分為小的區域,透過一種特殊的提取和演算法分析,再把得到的結果與檔案中的Block 進行比較,如果相似度很高,那說明播放是正確的。區域的大小可以調節,一般我們用4×4=16 個Block。如果你想更精準,當然Block 要劃分得更小一些。這樣,測試就不需要總是一個人去盯著螢幕了。

當然,人工觀看也是必要的。在一個Test Pass 之中,我們會有選擇性地由測試工程師來實際觀看播放的效果。人工的參與也可以驗證測試是否正確。

CWA的測試專案經歷

蔡:這是技術類的專案,是不是在管理方面也有印象深刻的專案?

周:管理類的專案中,CWA(Communicator Web Access)是有代表性的。專案啟動的時候,我們面臨著諸多挑戰。例如:

1. 這是一個1.0 版的產品,沒有以前的累積。

2. 測試的要求高,覆蓋面廣,功能測試、性能測試、安全性測試,等等,都覆蓋到了。

3. PM 都在美國,而不是本地,這在溝通上就是一個挑戰。

4. 測試組要從頭組建,並要帶著大家學習和掌握微軟的測試方法和開發流程。

5. 要建立測試Lab。

另外,CWA 是基於瀏覽器的,測試當中的OS 和Web Browser 的Matrix 很大,如何在有限的時間裡做好測試,如何排定優先順序,這也是挑戰。

如何尋求好的自動化測試的方法?當時MS 內部針對Web Application有不同的實現辦法,我們也需要做一個借鑒,然後透過自己團隊的探索,開發出適合CWA的測試框架來提高測試效率。

我做測試團隊的管理工作,從管理者的角度需要重點關注什麼,如何做好與總部團隊的溝通,這些都是挑戰。

測試要提供資訊,要儘早介入

蔡:你有多年的測試經驗,你對軟體測試的理解是什麼?

周:測試首先是要提供資訊。軟體研發的進度如何?進展到什麼程度?是否達到了預期的目標?大家透過這些資訊去推動專案,我們測試要為高層管理者提供決策的依據。

測試工程師要從用戶的角度來做工作,這是對的。但是,使用者可能希望軟體100%正確,完全沒有Bug,即Bug Free;而公司的資源卻是有限的,所以測試也要設定好自己的目標,因為一家公司是有商業目標的。

另外一個,也是測試的一個主要的作用,是要儘早、盡可能多地去發現問題。測試人員要儘早進入專案中,發現問題。問題發現越早,成本越低。我們也要推動整個團隊的Process達到高品質測試的要求。

制訂測試流程的時候要具體情況具體分析

蔡:我知道,很多大的軟體公司都有自己的一套相對完整的測試流程,但是國內的中小軟體企業卻不一定有,他們也很想聽到這方面的建議。在這方面你所推薦的測試流程是什麼?

周:這要看公司的具體情況。不同的公司,有不同的做法,要根據公司的承受能力來確定。對於中小公司來說,可以循序漸進地來做這件事。最開始的時候,公司可能也是剛開始引入測試角色,測試人員可以做一些End to End 的測試,就是一些大的場景測試,觀察主要的功能是否正確,是否能連貫地走下來。這樣,可以推進開發工作,並且發現了Bug 後,很容易知道問題出在什麼地方。

蔡:也就是說,你的意思是把重點放在主要功能上,保證一些主要的使用流程能走通,然後再逐步細化,是嗎?

周:對。在這之後,可以做功能測試,詳細一點的。然後,性能測試、擴展性測試、相容性測試,等等。如果你的產品準備賣到海外市場,還要做Globalization 測試,即當地語系化測試。如果你的人力有限,你不要一下子搭一個很大的架子,不要等整體的架子搭好了再去做測試。你還是要根據自己的實際情況先把事情做完。

手動測試、手動去做Verification,也是一種方法,在開始的時候不要花很長時間去做測試工具。等公司有了一定的累積以後,再引入或者開發Bug Tracking 工具、測試工具等等。

沒有依據,怎麼衡量

蔡:對於一些測試團隊的負責人來說,有一個難題就是如何把握軟體的品質。可能有的是老闆會經意或者不經意地問問:“軟體現在測得怎麼樣?軟體怎麼樣?”這個不好回答。

周:對於這個問題,測試負責人要先解決另外一個問題:當前的軟體產品的定位是什麼?

軟體應當有詳細的功能列表,各種功能參數,要做到什麼程度都要有定義,然後測試要儘早介入。這些都是軟體專案的Goal,而且是各方面都認同的目標,衡量的時候就以這些為依據。不然的話,沒有依據,怎麼衡量呢?

如果這個軟體的定位是搶佔市場,不讓競爭對手爭了先,那麼它的要求就會低一些,因為要儘快上市。只要能在一定程度上滿足客戶的要求就可以了。如果是要把這款軟體做強,與已經存在的競爭對手去競爭,那要求就不一樣了。例如,如果有一個Goal 是軟體持續執行500天,這個目標對於一個只是搶佔市場的產品就不大適合,因為客戶可能也只是先試試,沒有這方面的要求,或者說在這方面要求比較低。

如果沒有具體的Goal,你會很難衡量的。有了Goal之後,你就能知道當前軟體的主要問題是功能問題還是GUI的問題,你也好回答老闆的問題了。

另外,只要你帶著團隊認真地測試過一遍,你對產品就會有清晰的瞭解。這個時候,如果老闆來問,你就能很好地回答了。(摘錄整理自第七、八章)

關於軟體測試人員生涯規畫的建議

Q 蔡為東(作者):在軟體測試行業做了幾年的朋友,如果他/ 她是用心的話,就會開始考慮個人的職業發展規劃。這個問題也挺難的,大家都覺得個人規劃不好定,我想聽聽你的建議。

A 陳雅麗(IBM測試經理):我們要確定一個方向,那就是要做得更好。對於一位測試工程師來說,如果你在電腦技能上還有所欠缺,要去補課。例如,自動化測試技能,有沒有這個技能是相差很大的。

測試工程師也應當學一些開發語言,如Java。理工科的人去學習開發語言不會很難,因為畢竟也就是一個工具,不會很難的。

軟體測試工程師應當保持這樣的傾向:總是多瞭解一些。在廣度和深度上,多瞭解自己的產品,對於相關的產品也要有所瞭解。你看,有一種職位——Test Architect(測試架構師),他/ 她就要去定義測試的全過程,確認一個專案的投入和產出。如果沒有廣泛而深入的把握,是沒有這樣的能力的。

A 周慶輝(微軟資深軟體測試經理):我個人的看法是,制訂個人發展規劃的時候要考慮到很多的因素,無法一概而論。例如,自己到底喜歡什麼?如果不喜歡測試,那可能就不大願意繼續在這一行發展。如果你喜歡軟體測試,那就要看,是想在技術上繼續發展,還是管理上?
如果是在技術這條路線上發展,以後可以往測試架構上去發展(在大型的軟體企業裡,會有軟體測試架構師的職位)。

做測試的優勢:轉做相關工作不是很難

做測試還有一個優勢,就是轉做其他工作也不是特別難,例如三四年以後。測試廣度的要求對一個人有利,是一個優勢,你從頭到尾測試了這個產品,對產品是比較瞭解的。你做了幾年的測試,也有可能去做其他的行業,例如專案管理,因為測試在日常工作中與很多團隊都有接觸和合作。瞭解多了,你對專案管理的工作自然也不陌生。轉做開發也可以

自己擅長什麼

做了三四年的軟體測試以後,你對自己擅長做什麼要有所瞭解,對於自己希望達到什麼程度也要瞭解清楚,這對於確定自己的職業發展方向很有幫助。

 

贏在測試

軟體測試專家之道

蔡為東/編著

松崗出版

售價:420元


熱門新聞

Advertisement