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

Why do you want to be a software tester? For newbies or who are considering to choose this career…

身為軟體測試工程師, 有時和台灣一些其它從事軟體業的朋友聊起軟體測試這一行在台灣的狀況, 感覺是每個人都覺得軟體測試很重要, 但實際上從事軟體測試的人員, 或說公司在招募軟體測試工程師時, 又多是招募一些剛入行比較缺乏工作經驗, 或技術能力要求相對較低的人員, 給的薪水也比其它軟體工程師低一些. 要是上一些入口網站搜尋”軟體測試”, 有些人對軟體測試的了解還有軟體測試工程師的定位還真是另人搖頭, 例如”低階”, “乏味″…等等負面的字眼, 大概會因此阻擋很多有理想有抱負的年輕人進入這個行業. 個人有幸在微軟當軟體測試工程師, 並沒有感受到這些不受尊重的負面字眼發生在我的工作中, 不過既然有如上的狀況出現, 雖然沒有正確的取樣數據, 但這在台灣應該還是常見的狀況. 如果不改善, 這對軟體產業在台灣的發展絕對會有不好的影響. 我個人有時也會被問到軟體測試工程師在做什麼, 以及我為什麼要從事軟體測試, 而不是當個 DEVELOPER 或 PM, 原因其實很簡單, 因為我認為測試軟體, 不但要看懂 DEVELOPER 的程式碼, 了解整個軟體架構的設計, 還要做出計畫, 和開發團隊溝通, 並在某種程度上了解客戶的需求(雖然我認為搞懂客戶的需求其實是 PM 的責任). 最後, 還要想盡辦法去預防 BUG, 調查分析發生 BUG 成因, 並提供測試報告給軟體發行團隊評估產品發行的風險, 簡言之, 一個好的軟體測試工程師, 需要了解所有(負責領域的)開發流程的技術和流程環節, 還要利用各式各樣的工程方法來降低軟體出錯的機率, 或找到軟體的錯誤, 這其實是很有挑戰性且樂趣一點也不少於其它角色的工作. 至於究竟一個稱職的軟體測試工程師需要那些技能, 或更簡單的講, 要如何做軟體測試, 如果不怕看英文的話, 不妨參考…

1

What is the customer impact of this bug?

在我之前的 POST, Tester vs QA, 中有一小段文字是說, “tester 並不負責提供 user scenarios, 那是 pm (或 ba) 的事”. 可是在個人的工作經驗中, 三不五時就會被問到, “這個 BUG 的 customer imapct 是什麼?” 言下之意, 是要我, 也就是報告 BUG 的 Tester, 回答或評估這個 BUG 對客戶的影響有多大. 說實話, 有時候我還真的可以回答這個問題, 但有一個先決條件, 就是我已經有 PM (或 BA) 交給我的使用案例 (Use Case) 或情節 (Scenario) 了, 而這個 BUG 就剛好會導致使用案例失敗, 那對客戶的影響很簡單, 就是這個案例或情節掛掉, 會導致客戶沒辦法這樣使用產品. 但大多時候, 事情不會這個剛好, 而且就算剛好是掛在已經有的 CASE…

2