1. 測試流程
首先說說測試流程,微軟的測試流程也沒什么新的東西,和大多數的測試流程一樣。
大致是先進行測試準備,然后是Testcase的編寫,然后是白盒測試(不一定每個項目都有),然后是功能測試階段,然后是驗收測試,最終release。
如果看流程的話,和一般公司大同小異,沒什么新花樣。但是我覺得值得借鑒的是兩點。
第一, 微軟的流程執行的非常認真。
這點非常值得提倡,我們都知道,測試的最終質量決定于測試流程和測試人員素質,要想測試質量有保證,要么是流程很完善,要么你流程不行,但是個人能力超強。如果有一個很好的流程,就算執行的人稍微差點,最終的質量也不會差到哪里去。所以流程是很重要的。
但是,看國內的公司欠缺的就是這個,要么是沒有流程,要么流程是個花架子,沒認真執行過。我想微軟的測試人都是超級牛人,但是人家還是老老實實的忠實按照流程來走,我覺得這點非常好。(在IBM 也是這樣,筆者以前在IBM作項目的時候,發現他們的文檔寫的特認真,流程特認真),所以說忠實的執行一個好的流程是成功的一大半。
第二, 在整個流程中,微軟非常強調測試盡早介入。
微軟在這方面是一致提倡的,按照我們國內IT業的惡習,一般都是軟件主體差不多成型了,拉幾個測試人員過來點點,其實這是非常不好的。微軟的測試人員在項目一開始就和開發人員同步介入,在需求階段就開始介入,進行需求評審。在開發人員開始編碼的時候,測試人員就開始編寫Test case,并開發一些測試工具,或者寫一些配套的測試代碼(不要奇怪,微軟的測試人員都能寫很好的代碼)。微軟的理念就是:預防bug比解決bug好,所以非常提倡測試盡早介入,把一部分bug消滅在需求階段。
2. 自動化流程
說到自動化,大家可能以為我是說微軟的自動化測試工具多牛,其實微軟內部用到的自動化測試工具倒是不多,就算有也都是內部開發的,非常實用的,他們不會去用MI的工具。
說微軟的自動化程度高,主要是體現在流程方面,譬如說整個自動構建流程,在開發人員代碼check in之后,系統自動發郵件,郵件內容就是一個change list,包括代碼更新list以及一個編譯者添加的comment,其內容是該版本功能的變化或者修改掉的bug ID。整個測試過程中能用自動化的地方都盡可能采用自動化,盡可能減少人為失誤,并且可以使人和機器并行工作。個人覺得,這點很值得我們國內的測試公司借鑒,能自動化的流程都自動化,減少一些不必要的溝通。
原文轉自:http://www.anti-gravitydesign.com