1. 為什麼這個話題很重要#

Joel 觀察到一個令人困惑的現象：許多軟體公司——包括一些知名的公司——竟然沒有專職的測試人員（Tester）。這些公司通常會搬出各種看似合理的理由來解釋為何不需要測試人員，但 Joel 認為這些理由全部站不住腳。缺乏專職測試人員，是軟體品質低落的最常見原因之一。

Joel 建議的理想比例是：每兩位開發人員配備一位測試人員。這不是奢侈，而是經過實踐驗證的合理投資。

2. 五個錯誤理由逐一拆解#

2.1 錯誤理由一：「Bug 可以由開發人員自己找」#

這是最常見的說法，也是最危險的。問題在於：

• 開發人員天生對自己的程式碼有盲點。你寫的程式碼反映了你對需求的理解，如果你理解有誤，你不太可能透過測試自己的程式碼來發現這個錯誤
• 開發人員傾向於沿著「快樂路徑（Happy Path）」測試——也就是功能正常運作的路徑。真正的 bug 藏在邊界條件、異常輸入與罕見的使用情境中
• 開發人員的心理模型與使用者不同。使用者會做出開發人員根本想不到的操作

這不是說開發人員不應該測試自己的程式碼——他們當然應該。但開發人員的自我測試與專職測試人員的測試是互補的，而非可以互相替代的。

2.2 錯誤理由二：「測試人員太貴了」#

這個理由的邏輯完全是倒過來的。考慮以下事實：

• 一位測試人員的薪資通常低於一位開發人員
• 如果讓高薪的開發人員花時間做測試工作，實際成本反而更高
• Bug 發現得越晚，修復成本呈指數增長。在開發階段發現的 bug 可能只需要幾分鐘修復；到了生產環境，同樣的 bug 可能需要數天的緊急處理、客戶溝通與商譽損失
• 一個沒被發現的嚴重 bug 造成的損失，可能超過好幾位測試人員一整年的薪資

2.3 錯誤理由三：「我們的軟體是 Web-based，可以快速修復」#

Web 應用確實可以比桌面軟體更快地部署修復，但這不代表你可以跳過測試：

• 「可以快速修復」不等於「不需要修復」。每次線上修復都有風險，可能引入新的 bug
• 使用者在你「快速修復」之前就已經遇到了問題。對使用者來說，你的速度再快也是事後補救
• 頻繁的「緊急修復」會打斷開發節奏，讓團隊陷入永遠在救火的惡性循環
• Web 應用的使用者基數通常更大，一個 bug 影響的人數可能是數千甚至數百萬

「我們可以快速部署修復」這句話聽起來像是敏捷開發，實際上往往是品質管理失敗的遮羞布。真正的敏捷是快速交付高品質的功能，而非快速修補低品質的產出。

2.4 錯誤理由四：「隨便找人都能測試」#

有些公司覺得測試不需要專業技能，找實習生、行政人員甚至「我的狗」來按按按就好了。這種想法嚴重低估了測試的專業性：

• 專業測試人員知道如何系統性地覆蓋測試案例
• 他們了解常見的 bug 模式與高風險區域
• 他們能撰寫清晰的 bug 報告，幫助開發人員快速定位問題
• 他們能設計自動化測試，提高長期效率
• 他們能區分「這是 bug」與「這是設計決策」，減少不必要的來回

2.5 錯誤理由五：「我們負擔不起」#

Joel 認為這是最荒謬的理由。實際上：

• 你負擔不起的是沒有測試人員。低品質軟體的隱性成本（客戶流失、商譽損失、開發人員花大量時間救火）遠超過測試人員的薪資
• 如果公司真的資金緊張到無法雇用測試人員，那更不應該浪費昂貴的開發人員時間去做測試
• 品質問題導致的技術債會像滾雪球一樣越積越大，最終壓垮整個開發團隊

3. 測試人員的真正價值#

專職測試人員帶來的價值遠不只是「找 bug」：

• 品質守門員：確保每次發布都達到可接受的品質標準
• 使用者代言人：從使用者的角度審視產品，發現開發團隊的認知盲區
• 開發效率提升器：讓開發人員專注在寫程式碼上，而非花時間做系統性測試
• 風險降低者：在問題到達使用者之前就將其攔截，降低事故的發生頻率

如果你的團隊目前沒有專職測試人員，最簡單的第一步是：先雇用一位。即使只有一位測試人員，也能立即改善產品品質，並讓你的開發團隊更專注、更有生產力。