我最近聽到且深表贊同的, 就是應該要找 "會寫程式的測試工程師", 而不是找 "程式設計員來教他如何做測試". 這好像繞口令, 但其實就是說軟體測試工程師要會寫程式沒錯, 重點還是在測試, 提升軟體的品質. 微軟的軟體測試工程師, 正式名稱叫 "Software Development Engineer in Test", 簡稱 SDET, 還是花大部分時間寫程式, 只是這些程式通常是測試工具或自動化測試的測試案例, 著重於程式碼的 performance, 可測試性, 可維護性, 安全性, 還有系統整合時可能產生的各種問題. 比起軟體開發工程師 (Software Development Engineer, 簡稱 SDE), SDET 接觸層面較廣. SDE 則較著重於開發技術的深度.

所以, 理想狀況下, 好的軟體測試工程師, 應該要文武全才, 要了解技術, 要會寫程式, 會 Debug, 要懂各種測試方法, 要考慮客戶使用產品的使用者案例, 要對系統了解去測試整合性的問題, 還要時時和 PM 還有 SDE 保持良好的溝通. 不過最重要的, 其實是對品質的要求要比團隊中其它角色都更挑剔和堅持. 一般在招募人力時, 很難真的找到每個條件都具備的人. 那種人萬中選一, 可能好幾年都遇不到一個. 來應徵的人不是只會寫 Code 不懂測試方法, 就是只懂測試方法但不會寫 Code 把測試工具和測試案例開發出來. 找到會寫 Code 也懂測試, 卻可能不夠細心或對品質要求不高. 這時優先考慮的要件, 我個人認為是測試高於寫程式. 如果一個對測試完全不了解或有誤解, 甚或心態上不是很重視測試和品質, 就算可以很快把程式寫出來, 也很難培養成好的測試工程師, 反之, 若這個人了解測試要求品質, 但程式沒有寫的那麼好, 成功的機率還是大於前者.

不過當然, 相當程度的技術能力和 Coding 能力還是要的, 開發測試工具和自動化測試案例, 畢竟也是在開發軟體, 這部分的工作也是100% 的 Programmer 的工作. 要重新培養基本的東西, 可能沒有幾個雇主有那個時間和耐性吧.

Visaul Studio 2010 多了許多新功能, 例如 C# 也演變到 4.0 版 (請參閱 C# 4.0 中的新功能). 像 Type Dynamic, 委派和介面中使用泛型型別時對共變數 (covariance) 和反變數 (contraqvariance) 的支援等. 當然也包括諸如平行處理, Sharepoint 開發, F#...等等很多好用的範例. 希望這些範例能對大家使用 VS 10 時有所幫助.

大致上, 國際化測試的先後順序是 Globalization -> Localizability -> Localization, 而這三者的執行時期可以有部分互相重疊以期儘早執行所有測試工作. 這樣的測試順序是因為配合軟體 Localization 的程序. 大體上要把一個軟體 Localize 成為數種不同的語言版本, 首先要知道有那些字串是需要被翻譯的, 所以理想上要達到近乎 Code Complete 的階段才能開始進行 Localization 的工作. 所以 Localization 測試會最慢開始. 至於 Globalization 測試和 Localizability 測試則可以在更早的階段開始. 測試員甚至可以參與 Code Review, 或進行 WhiteBox testing 來及早發現程式碼本身對 Globalization 和 Localizability 的支援的瑕疵. 這些都可以在遠早於 Code Complete 的階段就開始執行. 另一個決定這樣測試順序的原因是如果軟體被設定成只能執行在某種特定語言的環境, 就根本不用考慮 Localize 成其它語言的狀況, 自然也不用考慮 Localizability 的問題了. 所以 Globalization 總是第一個開始執行的國際化測試工作.

所以我們回頭看軟體測試最基本的測試案例, Test Case, 其實也就不一定能確保一個產品達到高品質的水準. 重點還在於使用者情節, User Sceanrio, 的收集和設定. 這就有賴和客戶有最直接接觸的PM們的努力了.

所以, Test Case 的撰寫, 除了根據技術規格書, 還會仰賴PM們設定的 User Scenario. 如果 User Scenario 一開始的設定就有問題, 那測試工作做的再好, Test Case 寫的再詳細, 也沒辦法保證客戶會滿意產品的品質.

 在 VS 2010, 有一個新的功能叫 Extension Manager. 可以不用這麼麻煩, 打開 Extension Manger, 可以很快找到這些 Extensions, 還可以直接下載安裝, 比之前的做法方便簡單多了. 有興趣想知道更多細節的格友可以點上面的連結.

VS Gallery 現在還沒有翻成繁體中文, 上面的 extension 中支援繁體中文版本的也沒有很多. 不過其中有一個 extension 叫 Microsoft Visual Studio International Pack 支援繁體中文並且可以幫助使用者做一些字元轉換 (例如繁簡互換), 倒是不錯用的工具.

那對測試而言, 有沒有 "Test Complete" 這個階段? 我的答案是 Yes or No. 測試團隊要簽核 (sign-off), 軟體才能發行給客戶, 而要簽核, 一定必需要完成某種程度的測試工作, 發行團隊才能根據測試團隊的簽核來評估軟體品質是否達到發行的目標. 所以在軟體發行前, 有很多測試工作必需要 "Complete". 但是完成這些工作, 是不是就是 "Test Complete"? 嚴格來說並不是, 測試工作還是可以繼續進行. 除非發行團隊已經決定不再有下一個版本, 也不會有後續的 Service 的工作, 但就算如此, 也不代表測試就 "Complete", 只是不再做了. 不再做不一定是 "Complete".

看到這裏, 格友或許會問, 那軟體發行後, 還需要進行什麼測試工作? 我認為要看情況. 例如, 我們可能要做 Visaul Studio 2008 在 Windows 7 上的相容性測試. Visaul Studio 2008 是已發行的軟體, 但當發行時並沒有 Windows 7 可供測試所以現在我們要進行相容性測試. 當然, 也有一種可能性是測試發行前沒有被包含的案例, 例如發行後客戶回報的使用性問題或缺失.

簡單說, 對 Developer 而言, 在這個發行版本中, 所有的程式碼總有寫完的時候, 但對 Tester 而言, 就算測試工作已經讓我們有足夠的信心 Sign Off, 也還是很有可能必需再繼續做測試, 而且幾乎不可能宣稱所有可做的測試都 "Complete". 舉個簡單的例子, 一個使用者介面上有顯示生日日期的BOX, 有接受, 取消, 兩個按鍵, 還有三個Radio Button 可以選擇國曆, 陰曆, 或西元. 這樣會有多少種日期表現形式的選擇? 還要考慮閏年, 陰曆的閏月, 等等. 隨便一年都有上千個不同的日子可以測 (365 X 3). 當然真的執行測試工作時一定會將所以資料分門別類, 用各種手段來涵蓋各種可能性, 例如 Equivalence Partitioning Testing, Combinatorial Analysis, Boundary Testing...等等, 不會真的把 365 天每天都拿來測一遍, 但我們可以從上面這個簡單的例子中看到, 一個簡單的軟體要處理的使用者案例數目就很大了, 更遑論那些很複雜的專案和商業軟體.

所以當下次客戶回報 Bug 時, 先不要急著找 Tester 算帳, 重點先看是不是整個 Engineering Process 有問題, 為什麼產生這樣的漏洞, 規格文件有沒有涵蓋這樣的使用者案例, 然後做出持續改進才能真正解決問題.

嗯, 好吧, 那就表示測試很無聊? 所以不要做測試工程師了...如果你有這樣的結論, 那你一定沒有真的點過去好好拜讀大師的文章, 老師在講你沒有在聽...其實 Dr. James Whittaker 是一個很愛開玩笑的人, 他下這個標題只是要引起讀者的注意而已. 他真正的意思是, 執行 Test Cases, 報告 Bug, 其實是測試工作中最無趣的部分, 而測試工程師應該把大部分的時間和精力放在有趣的部分 -- "strategy, deciding what to test and how to combine multiple features and environmental consideration in a single test". 我強力推薦大家點上面的連結過去細讀.

不過比較另人難過的是, 大師最近離開微軟公司了, 所以他在 MSDN 上的部落格也不會再更新了. 他的新書付梓了, 希望能早日拜讀他的新書.

近幾年陸續看到一種新的”軟體測試外包”方式: 外包給社群的測試工程師測試. 簡單的說, 就是有一些公司, 提供一個平台仲介全世界的測試工程師社群和需要測試服務的客戶. 由客戶提出測試的需求, 讓測試工程師自己選擇要不要接這個CASE, 計價方式是算BUG 和TEST SCRIPT 的數量.

這就出現幾個有趣的問題: BUG 有重要的和不重要的. 不重要可以不修的BUG, 或不能在這個專案時程內修掉且不影響專案發行的BUG, 客戶要付錢嗎? 如果要, 要算多少錢? SHIPSTOPPER 和這種”可忽略”的BUG的價錢是否相同? 如果沒有找到 BUG, 也沒有提供新的 TEST SCRIPT, 客戶就不用付錢. 但就算測試工程師真的找不到 BUG (或沒有一定要修的 BUG), 難道就表示這個測試工程師沒有做好工作所以不可以有收入?

要討論這些問題, 首先要想一下所謂 Software Test Engineer, 或更廣泛的稱呼, Software Tester, 的工作職責是什麼. 這些提供測試社群平台的公司宣稱利用這種平台, 客戶甚至可以完全不用有自己的測試團隊 (我這裏指的”自己的測試團隊”, 包括自己公司的正式員工, 和自己外包給專門提供測試服務的公司或個人, 但不包括這種測試社群的服務), 但這真的可行嗎?

由這種公司的商業模式, 我們可以簡單的認為, 如果所有測試真的可以透過這樣的方式完成, 那測試工程師的工作只有兩樣, 找 BUG 和寫 TEST SCRIPT, 頂多再加上一些 USABILITY 的建議. 但事實上, 我認為測試工作不只是這樣, 尤其是找 BUG 這件事在我看來, 根本是測試工程師執行工作後所必然得到的”結果”, 而不是測試工程師執行工作的”原因”或”動機”.

如果要用簡短幾句話來講測試工程師的工作, 大致上測試工程師要負責提供資料讓發行團隊評估發行軟體的風險, 決定發行軟體的功能是否達到計畫目標, 並且要利用工程方法改進軟體開發的全部過程, 減少缺失產生的可能性. 如此看來, 一個好的測試工程師, 應該要讓軟體經過精心設計和執行測試工程後, 使其”品質”達到或超過客戶的預期, 雖然從以上的工作內容, 測試工程師並未直接”確保品質”.

所以回頭看這種外包給社群的計價方式, 其實並沒有真的針對測試工程師的主要內容計價, 這樣的”測試”工作,其實和直接把軟體開放給部份客戶"試用"沒有太大的不同. 如果測試工程師只專注於找到更多的BUG來得到收入, 也並不能真正提升軟體的品質.

到底 Bing 有什麼特別? 首先, 它會把搜尋結果分門別類, 所以這些結果的顯示方式看起來比大家慣用的某公司的搜尋結果有條理, 還有相關連結看起來也很合理. 例如在BING 裏找 Chien-Ming Wang, 首先會顯示的是建仔最近一次出賽的成績, 然後有往下看會有他的WIKI, 他的新聞, 圖片等等. 左邊則會顯示一堆洋基球員的相關連結. 你也可以點選WEB, VIDEO, IMAGE...等不同的搜尋標的來搜尋你最想要的內容類別.

不過我個人最喜歡的還是預覽功能, 在網頁搜尋, 當滑鼠遊標移到搜尋結果時, 指到右手邊出現的小黃點可以預覽網頁內容的片段. 甚至在VIDEO 的搜尋中, 很多時候不用真的點擊影片連結, 只要把滑鼠遊標移到影片上, 就會自動開始在那小小的視窗中播放, 大大減少等後影片傳輸的時間.

不過很可惜的是這新酷炫的新功能在繁體中文好像都還不支援, 連地圖都還沒有, 所以找"王建民"跟找"Chien-Ming Wang"的結果差很多. 希望這些新功能能早日支援繁體中文.

1. Globalization: 著重於軟體在各種語言上運行的相容性. 也就是說軟體不論在中文, 在英文, 在日文, 應該都要可以正確運作

2. Localizability: 軟體要真正打入各種不同語言文化的市場, 就要把軟體上的使用者界面, 各種錯誤訊息, 所有使用者看的到的字串都翻成當地的語言, 但把所有字串翻譯完後常會導致軟體不能正確運作, 最常見的狀況就是程式員把呼叫字串直接硬寫到CODE裏面, 如果這時把字串在UI上翻譯成不同的語言, 呼叫不到正確的字串就會導致軟體不能正確運作

3. Localization: 當翻譯完成, 真正組建"在地化"版本的軟體後, 還要經過完整的測試方能確保所有翻譯不會導致UI的問題, 翻譯的問題...等等

說這麼多, 舉個例子. 到某知名網路地圖上查從 "Taipei, Taiwn" 到 "Taichung, Taiwan" 的 driving direction, 會發現圖上會顯示從台北一路開到台"東"去, 而不是台中. 我知道沒圖沒真相但這個地圖不是微軟的 maps.live.com 所以恕我就不貼圖分享了. 反正大家應該都猜到我在那個網站上發現這個BUG. 希望沒有外國人真的因此從台北一路開到台東還沒吃到太陽餅.

像這樣的BUG, 我個人就會把它歸到 Localization. 因為很顯然, 因為某種不知那來的黑暗力量, 台中 (Taichung) 和台東 (Taitung) 的翻譯在這家公司的地圖資料庫裏搞混了. 對了, 忘了提, 打中文去找的話, 不會看到這個BUG.

還有, 如果你沒辦法 reproduce 這個BUG, 大概是他們在很短的時間內修好這個問題了. 聽說這種線上服務都更新的很快.