執行 BETA 測試的十二大技巧

適用範圍#

這些秘訣針對的是面向大量使用者的包裝盒軟體（shrink-wrap），對商業項目和開源項目都適用。重點是有大量使用者的軟體產品，而非公司內部的 IT 項目。

開放式 beta 測試只有兩種結果：要麼湧入大量無用的意見（像 Netscape 那樣），要麼測試者根本不回饋使用情況，導致你無法獲得足夠的數據。

最好的方法是訴諸**「言行一致」的心理**：讓測試者自己申請參加 beta 測試。一旦他們採取了主動行為（例如填寫申請表），就更可能發送回饋意見。

一次完整的 beta 測試的所有步驟，除非老天幫忙，否則根本不可能在少於 8-10 週內完成。

一次 beta 測試中計劃發布的軟體版本不要少於 4 個，否則無法達到測試目的。

如果在測試過程中添加新功能，哪怕很微小，整個 8 週的測試都要從頭來過。Joel 在 CityDesk 2.0 的 beta 測試中犯過這個錯誤，加入了保留空格的代碼，產生了意想不到的副作用。

即使你有申請步驟，最後也只有五分之一的測試者會向你提交回饋意見。

Fog Creek 的政策是：所有提交回饋意見的測試者都將免費獲贈一份正版軟體，無論回饋是正面還是負面的。

如果你獨立開發軟體，100 人大約是你能處理的回饋意見的最大數量。如果有測試管理團隊，可以按每個處理回饋的人找到 100 個嚴肅測試者。

根據第 7 條（五分之一會回饋）和第 9 條（需要 100 個嚴肅測試者），你需要批准約 1500 份申請。批准太少得不到充分回饋，太多則被重複意見淹沒。

大多數參與者只在第一次拿到程式時會去試用，之後就失去興趣。因此需要把測試者分成四組，每次發布新版本時加入一組新的測試者，確保每個版本都有第一次使用的人。

技術 beta 的目標是發現軟體中的錯誤和獲得及時的使用者回饋。市場 beta 則是軟體正式發布前的預覽版本，對象主要是新聞媒體、大客戶和撰寫入門教程的人。兩者目的完全不同，不要混為一談。