這篇文章中，作者以誠懇的筆觸將自己在組織beta測試的親身感受與大家分享，希望可以給廣大開發人員帶來幫助。
下面是一些關于如何組織一次軟件的beta測試的秘訣。需要注意的是，這里所說的“軟件”指的是面向大量用戶的軟件，也就是我所稱的“包裝盒軟件（注：“包裝盒軟件”指的是在商場中上架銷售、有獨立包裝、外面用熱收縮塑料膜密封的軟件商品。）”（shrink-wrap）。這些秘訣對商業項目和開源項目都適用。不管你開發軟件的目的是獲得報酬，還是獲得眼球效應，或是提高在同行中的知名度，都可以參考這些秘訣。但是，我關注的只是有大量用戶的軟件產品，而不是公司內部的IT項目。
1. 開放式的beta測試是沒用的。要是你那樣做，只可能有兩種結果。一種結果是你有太多的測試者（就像Netscape那樣），這些人向你反饋了大量的意見，你從中根本不可能得到有用的數據。另一種結果是，現有的測試者根本不向你反饋他們的使用情況，導致你無法得到足夠的數據。
2. 要想找到那些能夠向你反饋意見的測試者，最好的方法是訴諸他們“言行一致”的心理。你需要讓他們自己承諾會向你發送反饋意見，或者更好的方法是，讓他們自己申請參加beta測試。一旦他們采取了某些主動行為，比如填寫一張申請表，在“我同意盡快發回反饋意見和軟件故障報告”的選項上打勾，許多人就會發送反饋意見，因為他們想要“言行一致”。
3. 不要妄想一次完整的beta測試的所有步驟能夠在少于8-10周的時間內完成。我曾經試過，結果是除非老天幫忙，否則根本不可能做到。
4. 不要妄想在測試中發布新的軟件版本的頻率能夠快于每兩周一次。我曾經試過，結果是除非老天幫忙，否則根本不可能有效。
5. 一次beta測試中計劃發布的軟件版本不要少于4個。我從來沒試過少于4個版本，因為太明顯了，那樣不可能達到測試目的。
6. 如果在測試過程中你為軟件添加了一個功能，那么哪怕這個功能非常微小，整個8個星期的測試也要回到起點，從頭來過，而且你還需要再發布3個或4個新版本。我犯過的最大錯誤之一就是，在CityDesk 2.0的beta測試接近尾聲的時候，我向軟件中加入了一些保留空格的代碼，這產生了一些意想不到的副作用（如果我們可以這樣說），測試的時間不夠了，我本應該將測試時間加長、進一步收集數據的。
7. 即使你有一個申請參加beta測試的步驟，最后也只有五分之一的測試者會向你提交反饋意見。
8. 我們制定了一條政策，所有向我們提交反饋意見的測試者都將免費獲贈一份正版軟件。不管你的反饋意見是正面的，還是負面的，只要你提交給我們，就能獲得贈品。但是，在測試結束的時候，那些不提交反饋意見的測試者什么也不會得到。
9. 你需要的嚴肅測試者（即那些會把反饋意見寫成3頁紙發送給你的人）的最小數量大約是100人左右。如果你獨立開發軟件，那么這是你能夠處理的反饋意見的最大數量。如果你有一支測試管理團隊或專門的beta測試經理，那么設法分別為每個處理反饋意見的人找到100個嚴肅測試者。
10. 根據第7條，即使你有一個參加beta測試的申請步驟，最后也只有五分之一的測試者會真地使用你的產品并將反饋意見發送給你。那么，假定你有一個質量控制部門，里面一共有3個測試管理人員，這就意味著你必須批準1500份參加beta測試的申請表，因為這樣才能產生300個嚴肅測試者。批準的數量少于這個數目的話，你就不會得到充分的反饋意見；批準的數量多于這個數目的話，你就會被許許多多重復的反饋意見淹沒。
11. 大多數beta測試的參與者只是在第一次拿到這個程序的時候才會去試用一下，然后就喪失了興趣。此后每次你推出一個新的版本并發送給他們，他們也不會有興趣重新測試它。除非他們每天都在用這個程序，但是對于大多數人來說，這是不可能的。因此，你需要錯開不同版本的測試對象，將你的所有beta測試參與者分成四組，每次發布一個新版本的時候，就把一個新的組加入測試，這樣就能保證每個版本都有第一次使用這個程序的測試者。
12. 不要混淆技術beta和市場beta。我上面談的這些都是針對技術beta，它的目標是發現軟件中的錯誤和得到及時的用戶反饋意見。市場beta則是軟件正式發布前的預覽版本，對象主要是新聞媒體、大客戶和那些寫入門教程的家伙（該教程必須在軟件上市的同一天問世）。對于市場beta，你的目的并不是得到反饋意見。（雖然無論你怎么做，那些寫書的家伙很可能都會滔滔不絕地告訴你一大堆意見。如果你置之不理，這些意見就會被復制粘貼進他們自己的書里。）