不用測試人員的五大(錯誤)藉口 Top Five (Wrong) Reasons You Don’t Have Testers

1992年，James Gleick 正和一個多蟲軟體的各種問題週旋。科學作家 Gleick 認為微軟剛出的 Word for Windows 新版很可怕。他在星期天紐約時報雜誌寫了一長篇文章，這篇文章只能以激動來形容，整篇都在指責 Word 團隊不理會客戶的要求，交付問題如此多的產品。

稍後，他以地區 Internet 供應商 Panix(剛好也是我的 Internet 供應商)客戶的身份，要求提供自動排序並過濾其郵件的方法。提供這個功能的是一個叫 procmail 很神秘的 UNIX 工具，它的介面連最硬派的 UNIX 迷都覺得難用。

總之 Gleick 先生不小心在 procmail 裡打錯字，結果把他所有的信都刪掉了。一氣之下就成立自己的 Internet 連線公司。他雇用了 Uday Ivatury 當程式師，並且建立了Pipeline 這個真的有點超越時代的公司：這是第一個有圖形介面的商業 Internet 連線供應商。

當然囉，Pipeline 也有它自己的問題。很早期的第一個版本沒有使用任何錯誤更正的協定，所以很容易把資料弄亂或當掉。它就像所有的軟體一樣有臭蟲。1993年我去 Pipeline 找工作，面試中問到 Gleick 所寫的文章。「現在你已經身在籬笆的另一邊，」我問道：「有沒有稍微體會到創造好軟體的難處呢？」

Gleick 惱羞成怒。他否認 Pipeline 有任何問題，他也否認這個軟體有和 Word 一樣糟。他告訴我說：「約耳，總有一天你也會恨微軟的。」他做了一年的軟體開發而不再只是個使用者，這一年的經驗卻沒有讓他體會到無蟲又易用的軟體是多麼困難的事，這實在令我有點震驚。所以我就回絕那個工作機會逃掉了。(Pipeline 後來被一家世界上最奇怪的 Internet 供應商 PSI 買走，然後隨隨便便就被關掉了。)

軟體有蟲。CPU 異常的守規矩，它們絕對會拒絕處理沒有被明確教過的東西，而且通常會以最孩子氣的方式拒絕。我的筆記型電腦在外頭使用時常會當掉，因為它找不到本來找得到的印表機，多麼像個嬰孩。不過原因可能是某一行程式有個極微小卻又很嚴重的問題。

這也正是你絕對要有 QA 部門的原因。每用兩個程式師就需要一個測試人員(如果軟體需要用於多種複雜的組態或作業系統時還不只)。每個程式師都應該和某一個測試人員緊密配合，儘可能頻繁地丟出自己編譯的版本給測試人員測。

QA 部門應該要獨立並擁有權力，絕對不可以對開發團隊負責，事實上 QA 的主管應該有否絕權，可以阻止發行不合格的軟體。

我第一份真正的工作是在微軟；這家公司並不以高品質的程式聞名，不過它還是雇用了大量的測試人員。所以我曾經認為每個軟體組織都會有測試人員。

雖然很多組織確實有，不過沒有測試人員的組織還是多的令人驚訝。事實上很多軟體團隊甚至不相信測試。

你可能會認為，現在的經理經過 80 年代的品質狂熱洗禮，又有各種無意義的國際「品質」認證(如ISO-9000)和「六個標準差」等術語，應該會瞭解高品質的產品才能獲得高品質的生意。事實上他們都瞭解，其中大多數人已經儘量把它塞進腦袋，不過他們還是找出各種理由不用軟體測試人員，而這所有的理由通通都是錯的。

我希望可以對你解釋這些想法的錯誤。如果你趕時間剩下的就別看了，直接算人頭每兩個全職程式師請一個全職測試人員就對了。

下面是我聽過不雇用測試人員最常見的鬼叫：

1. 問題是懶惰的程式師弄出來的。

這種幻想的內容是這樣的：「如果你請了測試人員，程式師就會馬虎而寫出問題更多的程式。不要請測試人員，就可以強迫程式師一開始就寫出正確的程式。」

哇！如果你會這樣想，那你不是沒寫過程式，就是把寫程式這回事完全想歪了。由定義來看，臭蟲會出現就是因為程式師沒看到程式碼裡的問題。通常就是需要其他人才看得到問題。

當我還在Juno寫程式時，每次都會用一樣的方式執行我的程式。我會照我自己的習慣大量使用滑鼠操作。我們神奇的測試強者習慣有點不同：她比較常用鍵盤(而且會嚴厲地實際用所有可能的組合去測試使用介面)。這樣子很快就會找出大量的問題。事實上有時候她還會說整個介面都不能用，而且是百分之百不能用，可是在我的機器上一切正常。當我看著她重現問題才恍然大悟。Alt鍵！你按住Alt鍵了！我怎麼會沒測到呢？

2. 我的軟體放在網路上。即使有問題也馬上就能修好。

哈哈哈哈！好吧，你說對了，用網路分發軟體的確能比以往套裝軟體時代更快速的更新修正版本。不過即使把軟體放在網站上，也別低估在專案凍結後修正一個問題的代價。一來你可能在修正第一個問題時產生更多的問題。更糟的是如果你檢討發行新版本的程序，就會瞭解在網路上丟出修正版是個相當昂貴的建議。更別提會讓人因為有以下感覺而造成壞印象了：

3. 客戶會替我測試軟體。

啊，令人害怕的「Netscape防線」。這家可憐的公司藉著獨特的「測試」方法嚴重傷害了自己的聲譽。他們的測試方法是：

1. 當程式帥寫好一半時，不經任何測試就把軟體發行到網路上。
2. 當程式師說完成時，不經任何測試就把軟體發行到網路上。
3. 重複做六到七次。
4. 把其中某個版本稱為「最終版」
5. 每次當c|net上爆出一個丟臉的問題時就發行.01、.02、.03版。

這家公司是「廣泛beta」這個點子的先驅。意思是讓數百萬人下載這些多蟲的未完成版本。最初幾年幾乎所有 Netscape 使用者都在用某個搶鮮版或 beta 版。結果大多數人都認為 Netscape 軟體的問題實在很多。雖然最終版通常問題都極少，可是 Netscape 已經讓多到離譜的人用過多蟲的版本，所以大多數人對該軟體的整體印象都很差。

另外讓「客戶」來測試的重點在於讓他們找到問題然後由你來修正。不幸的是，Netscape 或任何其他地球上的公司都沒有人力，可以處理兩百萬客戶的問題回報並找出真正重要的問題。當我要填報 Netscape 2.0的問題時，問題回報網站一直當機，根本不讓我回報(不過反正問題回報最後都會丟進黑洞)。可是 Netscape 並沒有學到教訓，現在6.0「搶鮮版」的測試人員就在新聞群組裡抱怨，說問題回報網站還是沒辦法送出報告。那麼多年了！還是老問題！

不過我敢打賭，在這些多得要命的問題回報中，絕大多數都在講相同的 5 到 10 組很明顯的問題。裡面可能還埋有一兩個有意思又難查的問題，是某人千辛萬苦才成功送出的。不過反正沒人會看這些報告，所以也就等於不見了。

這種測試型式最糟的一點，就是公司會得到非常差的印象。當 Userland 推出主力產品 Frontier 的第一個Windows版時，我去下載並開始照著教學操作。不幸的是 Frontier 當了好幾次。我完全照著教學上面的指令逐一照做，怎麼樣都沒辦法執行兩分鐘以上。我覺得 Userland 可能連最基本的測試都沒做，根本沒有確認教學是能動的。產品品質低落的印象讓我有很長一段時間不再碰 Frontier。

4. 有資格可以勝任的人都不想做測試人員。

這是個很沈痛的理由。好的測試人員非常難找。

測試人員和程式師一樣，頂尖高手和一般水平的人相差一個量級。Juno 有一個測試人員 Jill McFarlane，她找到的問題是其他四個人合起來的三倍。我是真的算過，絕對沒有誇大其辭。她比普通測試人員的生產力好12倍。當她離職時，我寫了封電子郵件給執行長說道：「我寧願只有星期一和星期二讓 Jill 幫忙，也好過讓QA團隊其他人全部一起測。」

不幸的是，這麼聰明的人大都容易對日復一日的測試感覺厭煩，所以頂尖的測試人員通常只待三或四個月就會換工作。

這個問題唯一的解法就是面對然後想辦法處理。下面列出幾個建議：

• 把測試當作技術支援的下一個晉升工作。測試或許很沈悶，不過絕對比用電話處理憤怒的使用者好，而且可能也是消除某些技術支援人員騷擾的方法。
• 允許測試人員上程式設計課程拓展職業生涯，並且鼓勵較聰明的測試人員，運用程式工具及腳本語言開發自動化測試套件。這比不斷重複測試相同的對話盒要有趣多了。
• 要有頂尖測試人員經常流動的認知。積極的進行招募以保持穩定的人員流入。不要只因為暫時滿額而停止招募，因為總會有下一波好景氣。
• 找尋「非傳統」的工作者：找聰明的青少年，大學裡的小朋友還有退休人士來兼差。你可以用兩三位頂尖全職人員再搭配一群趁暑假賺學費的 Bronx Science(紐約一流高中)學生，建立出一個效果驚人的測試部門。
• 雇用臨時人力。如果請10個臨時工進來拿你的軟體來玩個幾天，就會發現很多很多的問題。裡頭可能會找到兩三個測試技巧不錯，值得簽約轉成全職人員的人。要先有心理準備，裡面有些人可能做不了測試人員；這時只能請他回家再繼續找新人。這也正是臨時人力仲介的功用。

下面這種方法無法處理這個問題：

• 千萬不要對來工作的電腦科系學生打歪主意，說什麼「所有人都要在QA部門磨練一陣子才能去寫程式。」我看過太多例子了。程式師沒法子當個好的測試人員，而且還會因而損失好的程式師，而這就更難找了。

終於到了，這是人們不雇用測試人員的頭號笨理由：

5. 我請不起測試人員！

這是最笨而且也是最容易揭穿的理由。

不管測試人員有多難找，還是比程式師要便宜，而且便宜多了。另外如果不請測試人員，就得讓程式師自己測。再來如果你認為測試人員大量增加不太好，就想想這件事的代價吧：年薪十萬美元的明星程式師受不了有人要他「在發行前留幾個星期測一測」，而換去比較專業的公司。光是為找新程式師而付給獵人頭公司就夠你一年請三個測試人員了。

吝嗇請測試人員是如此的划不來，我實在不懂為什麼有這麼多人認不清。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.