Silverlight Deep Zoom and VE

剛剛發現在 Silverlight 2 中有個很好玩的新功能, 叫 Deep Zoom. 會知道這個, 是因為發現有人把 Silverlight 2 的這個新功能用在 Virtual Earth 上. 實例就在這裏. 還滿酷的. 至於 Silverlight 2 還有什麼好玩的, 有興趣的話可以看這篇: Silverlight 2 Beta2 Release

1

Tester vs QA

上一篇談 Tester 的職責是什麼, 這一篇談另一個觀念, Tester  不應該被叫做 QA (quality assurance), 因為基本上, Tester 沒辦法真的確保 “Quality”. 很奇怪? 驚世駭俗? 推卸責任? 嗯, 當然不是啦, 上一篇才講過要追查到底才算盡忠職守, 怎麼這一篇突然說 Tester 不確保 Quality, 你可能會問, 那老闆雇用你幹嘛? 這個問題, 其實要從什麼是 “Quality” 談起. 為方便中文讀者, 我暫且把它稱為品質. 首先, 我們要先想一下, 到底是誰在決定產品的品質? 是 tester 嗎? 我今天執行一個 test pass, 有 99% 的 pass rate, 還有很好的 code coverage %, 就表示我的產品品質很高嗎? 假如事情有這麼簡單, 我們就一定不會聽到有人報怨微軟產品的品質了. “有人” 報怨產品的品質, 是因為 “有人”…

2

A Software Tester is…

我是個 Software Tester , 但是我突然發現, 我的 BLOG 裏的 “Test” 這個類別裏的 Post 居然沒有很多, 所以我想我應該多談談 Software Testing. 最近看了一些其它高手的部落格, 還有根據我自己的經驗, 其實, Software Tester 和 CSI 沒什麼分別, 都要根據各種蛛絲馬跡, 找到線索, 抓到兇手, 再交給法官和其它執法人員 (Developer and PM) 決定要怎樣去制裁兇手(Fix Bug or…just ignore this bug). Alan Page 在他的部落格中畫了一個 Tester 處理 bug 的流程, 在找到 bug 後, 首先要去找可能產生 bug 的原因, 然後根據這個原因, 找看看有沒有類似的 bug, 或因為這個原因產生其它的 bug, 然後看看有沒有辦法防止同樣的問題再度產生, 或利用同樣的 pattern…

1

UI Automation Tesing?

做軟體測試的人, 大多會希望把所有的測試都自動化, 就算沒辦法全部 (事實上, 全部自動化在目前是不可能的…), 至少也要愈多自動化測試愈好, 畢竟, 自動化測試的好處很多, 使用得當, 絶對能大大幫助軟體測試人員的效率, 但相信大家也都發現, 在做 UI 的自動化測試, 還真是不容易. 而且常常達不到預期的效果, 為什麼會這樣? 可能的原因很多, 但 Bj (微軟公司裏一個相當資深優秀的軟體測試工程師), 在他的部落格裏這一篇, GUI Automation and ROI, 提出一個重要的觀點, UI 常會變動, 所以 Autoamtion 很難維護. 導致 COST 太高. 在這篇裏還有很多人回應了很多很有趣的觀點, 不妨一起參考.

1

.Net Framework 2.0/3.0 SP1 on Vista

大家大概都知道, Vista 裏面是有尬 .Net Framework 2.0 以及 .Net Framework 3.0 的, 自去年底我們 release 這兩個版本 (2.0/3.0) 的 .Net Framework 的SP1 後, 相信一定有人會想, 那我要怎麼把 SP1 裝在 Vista 上? 為什麼 .Net Framework 3.0 SP1 Download Center 上標明:Supported Operating Systems: Windows Server 2003; Windows XP 而已?這這這…到底是怎麼回事? 關於這個問題, 在 Aaron Stebner’s Blog 裏面有詳細的說明. 正如 Aaron 說的: “The standalone redistributable packages for the .NET…

1

A Powerful Tool to Diagnose Problems in Your Windows System

我的專長不是做系統的, 不過前兩天純繂基於好奇, 去聽了一個有關 Windows 安全的講座, 席間的安全大師利用了一個好用的工具檢查電腦上有那些 Process 使用者是誰, 開了那檔案等等的資訊來研究潛在的安全性的問題, 發現原來微軟公司有提供這樣免費的工具: Process Explorer. 上網查了一下, 原來這個工具都出到第11版了(In fact, V11.20). 相信大家一定有個經驗, 在和別人共用的電腦上 (甚至自己的電腦上), 有時某個 File 就是沒辦法打開, 但一時也找不到到底那個傢伙(或那個程序)佔用了這個檔案, 這種情形由其在做 I/O 時最煩, 這時這個工具就可以派上用場了. 進來這間公司這麼久了, 從來不知道有這種工具可以用, 用Task Manager 看通常又看不出個所以然來. 嗯…這樣說好像 Task Manager 很遜的樣子, 其實對一般使用者來說, Task Manager 就很夠用了. 只是如果你是個 Developer, 常搞不清你的程式到底為什麼跑不大動, 或跑不好, 或沒事給你來個 I/O Exception, 甚或你要做一些安全性的檢查, Task Manaher 就不夠用了 講半天, 其實總歸一句話, 就如這個工具的作者在介紹這個工具的首頁上寫的: Process Explorer shows you…

1

Using MS technologies in Interface-Based Programming

前一陣子我同學從台灣來找我, 這位同學之前用 Jave 工作比較多, 但現在的工作用 .Net. 他跟我提到, 在他的公司裏的人, 用 .Net 開發, 但完全不懂 Interface-Based Programming, 所以他要跟那些資深同事們溝通時都很挫折, 他問我, 難道用 .Net 的人都不管這個嗎? 是不是因為 Visual Studio 太好用, 隨便拖拉一下就可以寫出可以用的程式所以用 .Net 開發的人都不管架構… 嗯, 關於這個 “Customer Feedback”, 我就當成是個讚美, 感謝他肯定 “Visual Studio” 相較於 Java 世界的其它開發工具是 “太好用”. 這樣我們每天辛苦的測試 Visual Studio, 總算沒有白費力氣. 可是, 對於廣大的 .Net 開發者社群而言, 我想他的疑問應該沒有反映真實狀況, 所以我就在此分享一些 MSDN 上的文章, 希望對好奇怎麼利用 MS 技術做 Interface-Based Programming…

1