什麼樣的人適合當軟體測試工程師

之前寫過一兩篇簡單介紹什麼是軟體測試. 最近參加一些論壇, 也看了一些其它人的文章, 就再寫寫我認為什麼樣的人適合當軟體測試工程師, 或要找什麼樣的人來當軟體測試工程師. 我最近聽到且深表贊同的, 就是應該要找 “會寫程式的測試工程師”, 而不是找 “程式設計員來教他如何做測試”. 這好像繞口令, 但其實就是說軟體測試工程師要會寫程式沒錯, 重點還是在測試, 提升軟體的品質. 微軟的軟體測試工程師, 正式名稱叫 “Software Development Engineer in Test”, 簡稱 SDET, 還是花大部分時間寫程式, 只是這些程式通常是測試工具或自動化測試的測試案例, 著重於程式碼的 performance, 可測試性, 可維護性, 安全性, 還有系統整合時可能產生的各種問題. 比起軟體開發工程師 (Software Development Engineer, 簡稱 SDE), SDET 接觸層面較廣. SDE 則較著重於開發技術的深度. 所以, 理想狀況下, 好的軟體測試工程師, 應該要文武全才, 要了解技術, 要會寫程式, 會 Debug, 要懂各種測試方法, 要考慮客戶使用產品的使用者案例, 要對系統了解去測試整合性的問題, 還要時時和 PM 還有…


中文的 Visual Studio 2010 程式碼範例!

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


Internationalization Testing Reference

之前曾經簡單的介紹過 Internationalization Testing. 大致講了一下 Globalization, Localizability 和 Localization 有什麼不一樣. 如果要實際對軟體做完整的國際化測試, 我建議先從這篇 MSDN 上的文章開始: Testing for World-Readiness Overview. 這篇文章裏針對測試順序及內容都有較詳細的說明. 大致上, 國際化測試的先後順序是 Globalization -> Localizability -> Localization, 而這三者的執行時期可以有部分互相重疊以期儘早執行所有測試工作. 這樣的測試順序是因為配合軟體 Localization 的程序. 大體上要把一個軟體 Localize 成為數種不同的語言版本, 首先要知道有那些字串是需要被翻譯的, 所以理想上要達到近乎 Code Complete 的階段才能開始進行 Localization 的工作. 所以 Localization 測試會最慢開始. 至於 Globalization 測試和 Localizability 測試則可以在更早的階段開始. 測試員甚至可以參與 Code Review, 或進行 WhiteBox testing 來及早發現程式碼本身對 Globalization…


User Scenarios and Test Case

軟體測試工程師和軟體品質有直接的關係. 但在我前幾篇的文章中一直重複述說軟體測試工程師的工作其實沒辦法直接確保品質. 也就是說, 測試和品保基本上並不相同. 簡單說, 測試結果顯示軟體的功能和規格相符, 達到發行團隊設定的可發行標準, 並不表示軟體的品質符合客戶的期待. 一個品質好的產品, 並不一定說亳無瑕疵, 而一個瑕疵不多的產品, 也不一定品質就很好. 一個產品如果沒辦法讓客戶覺得好用, 愛用, 就算沒有什麼 BUG, 客戶一樣不會覺得這是一個品質好的產品. 所以我們回頭看軟體測試最基本的測試案例, Test Case, 其實也就不一定能確保一個產品達到高品質的水準. 重點還在於使用者情節, User Sceanrio, 的收集和設定. 這就有賴和客戶有最直接接觸的PM們的努力了. 所以, Test Case 的撰寫, 除了根據技術規格書, 還會仰賴PM們設定的 User Scenario. 如果 User Scenario 一開始的設定就有問題, 那測試工作做的再好, Test Case 寫的再詳細, 也沒辦法保證客戶會滿意產品的品質.


Visual Studio Gallery and VS 2010 Extension Manager

各位或許知道 MSDN 上除了Code Gallery 有一些程式碼範例, MSDN 上還有 Visual Studio Gallery 提供一些好用的 Visual Studio extensions. 在VS 2008 時, 要連上 VS Gallery, 有兩個方法, 要嘛直接用 Browser 連上 MSDN, 或用VS Tools 選項下的 Find more extensions 然後打開 Document Explorer 瀏覽 MSDN 上的 VS Gallery.  在 VS 2010, 有一個新的功能叫 Extension Manager. 可以不用這麼麻煩, 打開 Extension Manger, 可以很快找到這些 Extensions, 還可以直接下載安裝, 比之前的做法方便簡單多了. 有興趣想知道更多細節的格友可以點上面的連結. VS Gallery 現在還沒有翻成繁體中文,…


Test Complete?

很多人應該都有聽過 “code compelete”. 在 Wikipedia 上, “Code complete” 可以是軟體開發周期的一個階段, 指的是開發團隊同意不再增加全新的程式碼到這個發行版本; 或者是有名的軟體開發書: Code Complete. (目前出到第二版). 那對測試而言, 有沒有 “Test Complete” 這個階段? 我的答案是 Yes or No. 測試團隊要簽核 (sign-off), 軟體才能發行給客戶, 而要簽核, 一定必需要完成某種程度的測試工作, 發行團隊才能根據測試團隊的簽核來評估軟體品質是否達到發行的目標. 所以在軟體發行前, 有很多測試工作必需要 “Complete”. 但是完成這些工作, 是不是就是 “Test Complete”? 嚴格來說並不是, 測試工作還是可以繼續進行. 除非發行團隊已經決定不再有下一個版本, 也不會有後續的 Service 的工作, 但就算如此, 也不代表測試就 “Complete”, 只是不再做了. 不再做不一定是 “Complete”. 看到這裏, 格友或許會問, 那軟體發行後, 還需要進行什麼測試工作? 我認為要看情況. 例如, 我們可能要做 Visaul…


For Newbies – Part II

之前寫過一篇給新手想選擇軟體測試工程師的文章. 對軟體測試工程師的工作做了一點很簡單的介紹希望能破除一些誤解多讓一些有志之士加入軟體測試的行列, 但內容有點過於簡單, 所以再補一篇. 不過這次我想直接介紹軟體測試界的大師, James Whittaker, 的文章 — Testing sucks! 嗯, 好吧, 那就表示測試很無聊? 所以不要做測試工程師了…如果你有這樣的結論, 那你一定沒有真的點過去好好拜讀大師的文章, 老師在講你沒有在聽…其實 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 上的部落格也不會再更新了….


Bug and Tester’s Responsibility

  近幾年陸續看到一種新的”軟體測試外包”方式: 外包給社群的測試工程師測試. 簡單的說, 就是有一些公司, 提供一個平台仲介全世界的測試工程師社群和需要測試服務的客戶. 由客戶提出測試的需求, 讓測試工程師自己選擇要不要接這個CASE, 計價方式是算BUG 和TEST SCRIPT 的數量. 這就出現幾個有趣的問題: BUG 有重要的和不重要的. 不重要可以不修的BUG, 或不能在這個專案時程內修掉且不影響專案發行的BUG, 客戶要付錢嗎? 如果要, 要算多少錢? SHIPSTOPPER 和這種”可忽略”的BUG的價錢是否相同? 如果沒有找到 BUG, 也沒有提供新的 TEST SCRIPT, 客戶就不用付錢. 但就算測試工程師真的找不到 BUG (或沒有一定要修的 BUG), 難道就表示這個測試工程師沒有做好工作所以不可以有收入? 要討論這些問題, 首先要想一下所謂 Software Test Engineer, 或更廣泛的稱呼, Software Tester, 的工作職責是什麼. 這些提供測試社群平台的公司宣稱利用這種平台, 客戶甚至可以完全不用有自己的測試團隊 (我這裏指的”自己的測試團隊”, 包括自己公司的正式員工, 和自己外包給專門提供測試服務的公司或個人, 但不包括這種測試社群的服務), 但這真的可行嗎? 由這種公司的商業模式, 我們可以簡單的認為, 如果所有測試真的可以透過這樣的方式完成, 那測試工程師的工作只有兩樣, 找 BUG…


Try the new search: Bing.com

相信很多人都已經知道微軟推出新的搜尋服務, 並正名為–“Bing”. 到底 Bing 有什麼特別? 首先, 它會把搜尋結果分門別類, 所以這些結果的顯示方式看起來比大家慣用的某公司的搜尋結果有條理, 還有相關連結看起來也很合理. 例如在BING 裏找 Chien-Ming Wang, 首先會顯示的是建仔最近一次出賽的成績, 然後有往下看會有他的WIKI, 他的新聞, 圖片等等. 左邊則會顯示一堆洋基球員的相關連結. 你也可以點選WEB, VIDEO, IMAGE…等不同的搜尋標的來搜尋你最想要的內容類別. 不過我個人最喜歡的還是預覽功能, 在網頁搜尋, 當滑鼠遊標移到搜尋結果時, 指到右手邊出現的小黃點可以預覽網頁內容的片段. 甚至在VIDEO 的搜尋中, 很多時候不用真的點擊影片連結, 只要把滑鼠遊標移到影片上, 就會自動開始在那小小的視窗中播放, 大大減少等後影片傳輸的時間. 不過很可惜的是這新酷炫的新功能在繁體中文好像都還不支援, 連地圖都還沒有, 所以找”王建民”跟找”Chien-Ming Wang”的結果差很多. 希望這些新功能能早日支援繁體中文.

1

Internationalization Testing

在國際化全球化的趨勢下, 軟體產品也愈來愈重視軟體發行國際化的相容性. 簡單說, Internationalization (I18N) Testing 大致包含三個部分: 1. Globalization. 2. Localizability. 3. Localization 1. Globalization: 著重於軟體在各種語言上運行的相容性. 也就是說軟體不論在中文, 在英文, 在日文, 應該都要可以正確運作 2. Localizability: 軟體要真正打入各種不同語言文化的市場, 就要把軟體上的使用者界面, 各種錯誤訊息, 所有使用者看的到的字串都翻成當地的語言, 但把所有字串翻譯完後常會導致軟體不能正確運作, 最常見的狀況就是程式員把呼叫字串直接硬寫到CODE裏面, 如果這時把字串在UI上翻譯成不同的語言, 呼叫不到正確的字串就會導致軟體不能正確運作 3. Localization: 當翻譯完成, 真正組建”在地化”版本的軟體後, 還要經過完整的測試方能確保所有翻譯不會導致UI的問題, 翻譯的問題…等等 說這麼多, 舉個例子. 到某知名網路地圖上查從 “Taipei, Taiwn” 到 “Taichung, Taiwan” 的 driving direction, 會發現圖上會顯示從台北一路開到台”東”去, 而不是台中. 我知道沒圖沒真相但這個地圖不是微軟的 maps.live.com 所以恕我就不貼圖分享了. 反正大家應該都猜到我在那個網站上發現這個BUG. 希望沒有外國人真的因此從台北一路開到台東還沒吃到太陽餅. 像這樣的BUG, 我個人就會把它歸到…

1