Test Complete?

很多人應該都有聽過 "code compelete". 在 Wikipedia 上, "Code complete" 可以是軟體開發周期的一個階段, 指的是開發團隊同意不再增加全新的程式碼到這個發行版本; 或者是有名的軟體開發書: Code Complete. (目前出到第二版).

那對測試而言, 有沒有 "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 有問題, 為什麼產生這樣的漏洞, 規格文件有沒有涵蓋這樣的使用者案例, 然後做出持續改進才能真正解決問題.