[心得] QA更應該擁抱AI技術，而不是害怕被其取代
============
前言：
最近準備要換到一段新的旅程，想趁中間過度休息的時間整理一下目前這份工作得到的一
些經驗以及心得。除了作為整理自我沉澱的心得之外，也想分享一下順便和大家交流交流
。
以下說明本文的一些預設前提：
1. 我大部分的職業生涯都是QA，並沒有太多完整Dev都經驗
2. 此篇文章適用於產品為軟體的產業，硬體以及韌體我並沒有太多經驗不確定是否適合
3. QA的學經歷仍然是本科系(STEM)出身
4. Junior QA：CS知識或coding能力是同等學經歷的SDE約3成左右
5. Senior QA：CS知識或coding能力是同等學經歷的SDE約6成左右
6. 自動化測試的結果不穩定（偽陽性/偽陰性）我覺得是軟體工程的問題而不是使不使用
AI的問題，故不特別討論
============
# QA更應該擁抱AI技術，而不是害怕被其取代
在當前的技術討論中，「AI 寫 Code 的能力越來越強，測試人員（QA）會不會最先被取
代？」似乎是一個最被大眾討論且被接受的共識。
但我的觀點恰恰相反。我認為在軟體開發中，「QA 才是這波 AI 浪潮下最大的受益者」
。
這聽起來可能很反直覺，但如果我們觀察軟體工程以及品質的本質，從風險與回報的經濟
學角度來看，你會發現 QA 處於一個極其特殊的「不對稱優勢」位置。這篇文章將探討為
什麼工程師對 AI 充滿顧慮，而 QA 卻可以大膽擁抱 AI ，以及各種不同等級的QA該如何
善用這個技術來達成更高的效率。
## 0 與 100 不同的開發方向
首先，我們需要釐清開發（Dev）與測試（QA）在產品生命週期中的不同責任。
軟體開發像是一條光譜：
工程師（Dev）是從 0 到 100 的創造者。他們照著規格從無到有構建產品，每一行程式
碼都是像層層往上疊的磚塊一樣將產品建構完成。
測試人員（QA）是從 100 到 0 的解構者。 我們拿到的是已經被構建好的產品（100），
然後層層剝開細節，尋找裂縫與邏輯漏洞，試圖將它還原成規格文件並驗證。
正是這種出發點的極端差異，決定了兩者在使用 AI 時面臨的「壓力」完全不同。
## 代碼的本質：外部產品 vs. 內部產品
為什麼工程師即便擁有能夠寫出複雜Code的AI，依然不敢放心地讓 AI 「全自動」寫 Cod
e？原因在於「風險」。
工程師產出的程式碼是「外部產品（External Product）」。它必須面對真實世界中數以
百萬計的未知使用者、千奇百怪的網路環境、以及潛在的惡意攻擊。這意味著程式碼必須
具備極高的通用性與安全性。如果 AI 生成的程式碼在百萬分之一的場景下發生一次致命
的邏輯錯誤（編按：最近明日方舟的Paypal事件就是一個），對公司來說就是毀滅級的災
難。這種「對外交付」的沈重責任，導致工程師在使用 AI 時必須支付極高的「信任成本
」與 Review 時間。
反觀 QA，我們產出的自動化程式碼，本質上是「只」服務於公司產品的「內部產品（Int
ernal Product）」。
我們的「對象」是明確且單一的——就是眼前的這個產品。
我們不需要讓測試腳本相容於全世界所有的軟體，只需要它能夠測試我們公司的產品就可
以。
「外部產品」追求的是無懈可擊的廣度；而「內部產品」追求的是解決特定問題的深度。
正因為 QA 的程式碼是「受限的」且「目標單一的」，這導致我們使用 AI 生成的Code「
驗證是否合法」的成本遠低於工程師。只要 AI 寫出的 Code 能在這個特定版本、特定環
境下抓出 Bug（或幫助我們工作），它就是有價值的 Code。
這就是 QA 使用AI的「不對稱優勢」。
所謂不對稱優勢，是指我們處於一個「下行風險有限，但上行回報無限」的位置：
極低的下行風險：
過去我們常將風險解釋為「修復腳本的成本」，但真正的風險應該是「退回手動執行 」
。當 AI 生成的測試腳本失效或無法執行時，我們最壞的情況僅僅是切換回原本的人工測
試模式。重點在於，無論是由 AI 執行還是由人工執行，最終的測試結果是一樣的。這意
味著我們的「風險底線」就是現狀。
舉個例子：
你有一個test acse，內容是做A、B、C三個操作，之後驗證狀態是否為預期的，並且你本
來就有一份自動化測試在執行這個case了。
現在你們的軟體改版，還是一樣做A、B、C三個操作驗證狀態，但是UI改版了，於是你原
本的自動化測試告訴你某個UI找不到了無法執行。
這時候通常會是兩種情況：
1.時間不夠來不及修腳本所以這次改為人工執行
2.時間還夠把腳本修好繼續用自動化測試執行。
在這兩個選擇中，不論是人工執行或是用程式執行得到的結果都是一樣的，從品質的角度
來看這兩種方式都提供了一樣的品質保證，唯一你有可能承擔的風險只有「時間不夠」（
例如用程式跑只需要1分鐘但是人工需要30分鐘），而不是「品質下降」，這就是所謂的
「風險僅是退回手動測試」的意思。
註：當UI改動（或是業務邏輯改動）後本來測試就需要「跟著更新」，這個成本不論是手
動或是自動都要承擔的，只是我們都把更新人腦的成本忽略了。但這本質上還是「成本」
而不是「風險」。
極高的上行回報 ：
相對於被鎖定的低風險，一旦你接受使用AI來幫助執行測試，獲得的卻是「指數級的效率
提升」。
我們並非將結果交給 AI來產生，而是將 AI 視為一個「低風險、高回報」的增強外掛：
AI 寫的腳本不能用？那就退回手動，品質結果不變。
但只要這個腳本能夠成功幫助我們執行測試，通常就是十倍速以上的效率躍進回報。
## 實戰落地：AI 賦能的兩個層次
理解了優勢後，我們該如何落地？許多人對 AI 自動化有個誤區，認為必須一步登天，建
立完美的自動化框架。事實上，QA 使用 AI 可以分為兩個層次：
### 1. 初級使用：繁瑣任務
（適合 Junior QA / Manual Testers）
如果你的工作目前依賴大量手動測試，不要一開始就想著「將 Test Case 100% 轉為自動
化代碼」。你應該關注那些手動測試中「繁瑣、重複、低腦力」的任務。
舉例：
Log抓取：
你需要抓取android手機中你們公司產品app的log。但是你不知道adb logcat以及grep兩
個指令，所以你以前只能每次都連線進去手機找到log檔案複製出來並且ctrl+f一行一行
尋找。
但是如果你把這個問題拿去問AI後就可以得到一個adb + grep的一行組合指令解決你的問
題並且節省了許多時間。
Log 分析：
以前你需要花 5 分鐘肉眼過濾 Device Raw Log 找錯誤代碼，現在你可以花 30 秒讓 A
I 寫一個 Shell Script 幫你parse raw log並且直接判斷是否有Error。
資料生成：
需要許多筆符合特定格式或是規則的測試資料，以前人工執行的話要一直複製貼上資料並
且修改不同的部分（最大值、最小值、中間值、超出邊界…等等），現在把這些規則告訴
AI之後，AI能在很短的時間內產出高品質資料。
為什麼在這個層次 AI 特別有幫助？
首先是「積少成多的複利效應」。
假設你每天需要分析 20 個失敗的 Test Case Log，手動查找原因平均每次耗時 5 分鐘
，這意味著你一天有 100 分鐘（近 1.7 小時）消耗在單調的肉眼檢查上。
若用 AI 生成的腳本輔助，將分析時間壓縮至 1分鐘，你每天就憑空多出了80分鐘的深度
工作時間，這就是微小進步帶來的巨大回報。
其次是「極低的驗證成本」。
由於這些任務的 Scope 很小，要驗證 AI 寫出來的程式碼或結果是否正確非常簡單。相
比於工程師驗證產品的高昂成本，QA 在這些繁瑣任務上的試錯成本幾乎為零，是典型的
「低風險、高回報」投資。
對於這些任務，我們甚至可以抱持著「拋棄式代碼」的心態。它們是為了取代當下那 100
% 的手動苦工而存在的。
* 如果它能用了，你賺到了時間。
* 如果它過期了或壞了，就丟掉它，讓 AI 重新生成一個，或者暫時退回手動。
這些碎片化工具是通往自動化的「鷹架」。它們幫助手動測試者跨越了「不會寫 Code」
的恐懼鴻溝，在一次次與 AI 的協作中，逐漸成長為能駕馭程式碼的工程師。
### 2. 進階使用：開發自動化測試架構（適合 Senior QAE / SDET）
當你以及團隊跨過了初級階段，進入到系統級自動化測試時，AI 的角色就從「寫手」變
成了「副駕駛」。
在這個階段，我們不能再依賴拋棄式代碼，而是要建立穩健的架構。這時候，QA 的職責
是定義架構、制定方向、提供規格、設計介面、規範 Pattern，然後讓 AI 去填充具體的
實作細節。
有人會挑戰：「如果內部產品充滿了 AI 寫的爛 Code，會變成團隊的隱形殺手。」
這正是Senior QA或是SDET 的價值所在。AI 的產出效率越高，Code Review 的重要性就
越高。我們必須確保引入的自動化測試程式碼符合軟體工程標準。
但即便如此，相比於開發正式產品，QA 在建立自動化測試時的 Scope 依然小得多。
為什麼這麼說？
工程師的產品程式碼必須處理高同步、嚴格的資安標準、以及各種來自現實世界的攻擊…
等等的各種極端情況。
而 QA 的測試程式碼通常運行在受控的環境中，面對的是可預測的輸入與單一的系統狀態
。它不需要服務全世界，只需要服務公司產品。
因此，同樣的資深工程師使用 AI，撰寫自動化測試面臨的技術複雜度指數遠低於正式產
品，因此能換取指數級高的效率回報。這不再只是節省幾分鐘，而是能將原本需要「3 天
的手動回歸測試週期，透過 AI 加速構建自動化測試，壓縮至 2 小時內完成」。這對產
品發布節奏的影響是革命性的。
## 結語：AI 無法模仿「品味」
最後，可能會有人問：如果 AI 能寫 Code 也能寫測試，那未來的 QA 價值在哪裡？
這是一個哲學問題。在我看來，工程師和 AI 追求的是「邏輯的正確」，但 QA 追求的是
「體驗的品質」。
產品的最終使用者是人類，而只有人類能理解人類的痛點與「品味」。AI 可以幫我們寫
出完美的 Assert 語句，但它無法告訴我們這個按鈕的觸感是否「對勁」，或者這個流程
是否讓用戶感到「挫折」。
如果我們承認了AI可以想出這些含有人類情感的test case，似乎也就承認了AI擁有了跟
人類一樣的情感。至少在2026一月的今天，我覺得AI還沒擁有這些能力（如果有的話應該
比取代QA還大條XD）。
總結成最後一句話：AI 負責處理邏輯的 0 與 1，QA 負責守護那不可量化的「人類體驗
」。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.70.223.81 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1769242057.A.954.html