上禮拜開sprint review，我們家PM又問了那個經典問題：「所以這個功能測試做完了嗎？什麼時候可以上線？」
工程師翻了個白眼：「單元測試過了，但整合測試還沒跑完。」
PM一臉問號：「蛤？測試不是測試嗎，怎麼還分這麼多種？」如果你也有一樣的疑惑，恭喜你，這篇文章就是寫給你看的。
1.為什麼測試會分這麼多階段？因為你的PRD也分很多階段啊
你寫PRD的時候會分：需求分析、功能架構、詳細規格、實作細節對吧？
測試也一樣，而且是倒著來的：
- 單元測試（Unit Testing）：測最小的功能單位（通常是一個function或class）
- 整合測試（Integration Testing）：測不同模組接在一起會不會出問題
- 系統測試（System Testing）：測整個系統在真實環境下能不能動
- 驗收測試（Acceptance Testing）：測這東西到底符不符合客戶需求
你看出來了嗎？這四個階段剛好對應你寫PRD的四個層次。
所以下次工程師跟你說「單元測試過了但整合測試還沒跑」，他不是在找藉口，他是在告訴你：個別零件沒問題，但組裝起來還不確定。
就像你買IKEA家具，每個零件看起來都對，但組裝的時候發現螺絲孔對不上，這就是為什麼需要整合測試。
2.Validation vs Verification：你到底要做對的事，還是把事做對？
工程師常會提到兩個詞：Validation和Verification。這不是工程師在掉書袋，這兩個概念直接影響你的產品會不會做錯方向。
簡單記：
- Validation（確認）：Are we building the right thing？（我們做的是對的東西嗎？）
- Verification（驗證）：Are we building the thing right？（我們把東西做對了嗎？）
舉個例子：
你要做一個「一鍵匯出報表」功能。
Verification（驗證）：系統測試、整合測試、單元測試都在做這件事，確保匯出功能技術上沒問題，格式正確，不會crash。
Validation（確認）：驗收測試在做這件事，確保這個匯出功能真的解決了使用者的痛點，而不是你自high覺得很酷。
很多專案做到最後，技術上完美無瑕（Verification過了），但使用者根本不買單（Validation沒過）。
這就是為什麼驗收測試這麼重要
它是唯一能確認你有沒有做錯方向的關卡。
3.為什麼工程師這麼愛單元測試？因為改錯誤的成本差100倍
圖表上有個很殘酷的事實：越早發現問題，修復成本越低。
單元測試階段抓到bug，改一行code就好。 整合測試階段抓到bug，可能要改三個模組。 系統測試階段抓到bug，要重新測一輪。 驗收測試階段抓到bug？恭喜你，客戶不爽了，專案可能要重新來過。
這就是為什麼工程師會堅持要寫單元測試，即使看起來很花時間。
他們不是在龜毛，他們是在省未來的時間。
而且，單元測試還有三個好處：
- 除錯耗時短：問題範圍小，容易定位
- 了解如何使用：單元測試本身就是最好的使用說明書
- 知道程式碼健康狀態：測就知道
所以下次工程師跟你說「我要先寫測試」，不要催他，他是在幫你省時間。
4.整合測試的三種玩法：為什麼不能一次全測？
整合測試有三種策略：
- Big-Bang（大爆炸式）
一次把所有模組組起來測。
優點：快
缺點：出問題根本不知道是哪裡爛掉
就像你煮火鍋，把所有食材一次丟下去，結果湯很難喝，你也不知道是高麗菜還是蛤蜊壞掉。
- Top Down（由上到下）
從最上層的UI開始測，逐步往下測底層模組。
優點：可以早期展示給客戶看
缺點：底層模組還沒寫完，要用Stub（假模組）擋著
就像蓋房子，先做外觀設計，內部結構慢慢補。
- Bottom Up（由下到上）
從最底層的模組開始測，逐步往上整合。
優點：底層邏輯穩定
缺點：要很晚才能看到完整功能
就像先把地基打好，再一層一層蓋上去。
大部分團隊會用綜合式（Hybrid）
重要的核心功能用Bottom Up確保穩固，UI層用Top Down快速展示。
5.PM該知道的「可測試性」
工程師常說某個功能「不好測」，不是在找藉口，是你的需求可能欠缺「可測試性（Testability）」。
一個好測的系統要有這些特性：
- 可觀察性（Observability）：測試人員要能看到系統狀態。你不能寫個需求說「系統會自動判斷」但不給工程師任何log或狀態查詢方式。
- 可控制性（Controllability）：測試人員要能控制系統輸入。如果你的需求是「根據使用者過去30天的行為推薦內容」，但沒辦法模擬或改變這些資料，根本測不了。
- 簡單性（Simplicity）：系統越複雜越難測。如果你的需求寫得像迷宮，工程師光是設計測試案例就要一週。
- 隔離性（Isolation）：模組之間要能獨立測試。如果你的功能A一定要搭配功能B、C、D才能跑，測試成本會爆炸。
- 可自動化程度（Automatability）：能自動化的測試才能重複執行。如果你的需求需要人工點100個按鈕才能測，沒人想測第二次。
下次寫PRD時，想想：這個功能工程師要怎麼測？
如果連你自己都想不出測試方法，那這個需求八成有問題。
6.實戰建議：PM要怎麼跟測試階段共存？
- 規劃整合測試策略時，記得預留測試環境準備時間。測試環境掛掉是常態，不要期望一次到位。
- 需要準備一個專門的測試資料庫。準備測試資料很煩，但這能讓測試結果可重複驗證。
- 設計整合測試案例時，要考慮各個模組之間的交互行為。不是只測「能不能動」，要測「在各種極端情況下會不會爆炸」。
- 推行整合測試時，團隊要按照設計的測試案例，對系統進行實際測試。不要臨時抱佛腳隨便點點。
7.結語
下次當工程師跟你說「測試還沒做完」，不要翻白眼。
問他：「是哪個階段的測試？」
如果是單元測試還沒過，那是程式碼品質問題，可以催。 如果是整合測試還在跑，那是架構穩定度問題，要有耐心。 如果是驗收測試不過？那可能是你的需求有問題。
測試不是開發流程的最後一關，而是每個階段都在進行的品質把關。
身為PM,你不用懂怎麼寫測試，但你要懂測試在幹嘛，這樣你才能合理安排時程，也才能跟工程師好好溝通。
不然你只會一直被工程師白眼，還不知道為什麼。
就這樣。
