嗨，我是 Jane。無論你是對自動化測試有興趣的工程師，或是已經從事自動化測試工作的朋友，或許都曾經遇過類似的問題：

「公司所有功能都已經有自動化測試了嗎？」
「目前的自動化測試覆蓋率是多少？」
「為什麼這個功能還沒有寫自動化測試？」

有時候，主管甚至會直接根據「完成了多少自動化測試案例」，來評估一位測試工程師的工作成果，或決定團隊接下來應該投入哪些工作。

但我認為，在開始撰寫自動化測試之前，我們更應該先思考一件事情：

這個測試自動化之後，究竟能為團隊帶來什麼價值？

自動化測試並不是寫得越多越好，也不是所有功能都一定要自動化。每一個自動化測試案例，都需要投入開發、維護、執行環境與問題排查的成本。

如果一個測試案例執行頻率很低、結果容易受到環境影響，或維護成本比人工驗證還高，那麼即使成功將它自動化，也不一定能真正幫助團隊。

因此，在決定是否投入自動化測試之前，我通常會先從以下幾個面向評估。

1. 提升回饋速度

自動化測試最直接的價值之一，就是縮短團隊取得測試結果的時間。

當程式完成建置、部署到測試環境，或準備進入下一個交付階段時，自動化測試可以快速執行一批重要案例，協助團隊初步確認這個版本是否出現明顯問題。

例如，一套原本需要人工花費兩個小時執行的基本驗證，如果能透過自動化測試在十幾分鐘內完成，就能讓開發人員更早收到回饋，也可以降低問題累積到後期才被發現的風險。

不過，真正重要的並不只是「跑得快」，而是：

能不能在團隊仍有時間處理問題時，提供有用的測試結果。

如果測試需要執行好幾個小時，等到結果出來時，版本早已經進入下一個階段，那麼這套測試即使涵蓋很多功能，實際價值也可能有限。

2. 降低重複驗證成本

有些功能在每次版本更新後，都需要反覆執行相同的驗證。

例如：

• 曾經多次發生Regression Bug的功能
• 修改其他模組時容易被意外影響的功能
• 人工操作步驟繁瑣但結果明確的流程
• 每次上版都必須執行的基本檢查
• 容易因為疏忽而漏掉的細節

這類測試通常非常適合自動化。

自動化測試可以代替測試人員執行大量重複性操作，讓測試人員把時間投入在更需要判斷力的工作，例如探索式測試、風險分析、需求釐清，以及異常情境驗證。

但這並不代表只要是重複執行的測試，就一定值得自動化。

如果一個案例一年只執行一次，但每次系統改版後都需要花很多時間修改腳本，那麼它帶來的效益，可能仍然低於人工測試。

因此，除了人工執行成本之外，也要一起考慮自動化測試的維護成本。

3. 保護高風險功能

有些功能一旦出錯，就可能造成嚴重影響，例如：

• 登入及權限控管
• 付款與訂單流程
• 帳務計算
• 核心資料處理
• 重要客戶使用的主要流程
• 可能造成Production Issue的關鍵功能

這些功能通常不允許在每次版本更新後，只依賴人工記憶或臨時抽查。

如果某個核心流程在每次上版前都必須百分之百確認，那麼就應該優先建立穩定的自動化測試，讓它成為版本交付前的重要防線。

不過，高風險功能的自動化測試也不能只追求「有寫就好」。

如果測試案例本身不穩定，經常出現誤報，久而久之，團隊就會開始忽略失敗結果，甚至習慣直接重新執行。

這樣的測試不但無法保護產品，反而可能讓真正的問題被掩蓋。

因此，保護高風險功能的前提，是測試結果必須穩定、清楚，而且能夠被團隊信任。

4. 支援頻繁交付

現代軟體開發通常不會等到所有功能都完成後，才一次進行大型版本更新。

開發團隊可能每天都會修改程式、合併Code、建立Build，甚至部署到不同環境。

在這種頻繁交付的情況下，人工測試很難在每一次變更後，都完整驗證所有既有功能。

自動化測試可以配合CI/CD流程，在每次程式異動後，自動執行適合的測試，例如：

• Pull Request建立後執行基本驗證
• Build完成後執行Smoke Test
• 部署到測試環境後執行主要流程
• 正式上版前執行Regression Test

透過不同層級的測試，團隊可以更早知道新的程式修改是否破壞既有功能。

但是，支援頻繁交付並不代表每次都要把所有自動化測試全部跑完。

如果一套測試需要花費很長時間，或佔用大量環境資源，就必須進一步思考測試分類、執行時機，以及哪些案例應該優先執行。

5. 提供可被信任的品質訊號

自動化測試能夠提供相對一致且客觀的執行結果。

同樣的輸入、同樣的步驟與同樣的驗證條件，理論上應該產生一致的結果。團隊也可以透過測試報告快速了解：

• 哪些測試通過
• 哪些測試失敗
• 失敗發生在哪一個步驟
• 目前版本可能影響哪些功能
• 問題是來自產品、測試腳本，還是環境

不過，這裡有一個很重要的觀念：

Pass rate並不等於產品品質。

即使自動化測試顯示100%通過，也只能代表「目前已經執行的這些測試條件都通過了」，並不能證明產品完全沒有問題。

相反地，如果Pass rate很低，也不一定代表產品品質很差，因為失敗可能來自測試環境不穩定、測試資料錯誤，或測試腳本本身存在問題。

因此，真正有價值的品質訊號，不只是顯示測試通過或失敗，而是讓團隊能夠快速判斷：

這個版本是否值得信任，以及失敗結果是否需要立即處理。

自動化測試也有成本

當我們只關注自動化測試的數量時，很容易忽略它背後所需要的成本，包括：

• 開發測試腳本的時間
• 建立與維護測試環境
• 準備測試資料
• 維護因產品變更而失效的案例
• 分析與排查測試失敗
• 提供執行測試所需要的機器與資源
• 維護測試報告與CI/CD流程

如果沒有先評估實際價值，團隊可能會花費大量時間撰寫自動化測試，最後卻發現這些測試很少被執行，或是在真正需要快速驗證Hotfix時，因為執行時間過長、環境不足或案例不穩定，而無法提供即時幫助。

這樣的自動化測試，雖然在數量上看起來很多，卻不一定能提升產品品質，甚至可能成為團隊新的技術債。

結語

我認為，真正值得自動化的測試，應該至少能帶來一項明確價值：

• 更快提供回饋
• 降低重複驗證成本
• 保護高風險功能
• 支援頻繁交付
• 提供可信任的品質訊號

自動化測試的目標，不是讓測試案例數量持續增加，也不是讓報表上的覆蓋率看起來更加漂亮。

真正的目標應該是：

用合理的維護成本，持續提供快速、穩定且值得信任的品質回饋。

因此，在開始寫下一支自動化測試之前，我們或許都可以先問自己：

「如果沒有這支自動化測試，團隊會失去什麼？」
「如果寫了它，真的能讓我們更快、更穩定地交付產品嗎？」

當答案足夠明確時，這個案例才真正具有被自動化的價值。