前言：那個下午我意識到自己錯放了位置
最近我在測一個篩選功能。
四個條件、每個三到四個值，光是基本組合就上百種；再加上排序、分頁、清除按鈕、預設值的交互——整整兩天，我坐在電腦前面，一組一組點下去、等載入、比對結果、寫紀錄。
到了第二天下午，我手指麻了，眼睛酸了，但更難受的是另一個東西——
我突然發現，我做的這件事情裡，沒有任何一處需要「我」這個人。
每組條件的點擊規則我用一句話可以講完。每組結果該長什麼樣，我可以寫出一個明確的 assertion。每跑一組之間我什麼都不需要思考——就只是按下去、等、比對。
那一刻我才看清楚一件事：我不是在「測試」，我是在「人肉執行 for 迴圈」。
而我這份「煩」，不是 QA 軟弱、不是不夠敬業——它是一個訊號。它在告訴我，我把自己放錯位置了。
這篇文章想認真聊聊這件事。
一、QA 圈裡那種「越煩越要做」的職業文化，只說了一半的真話
QA 這個職業有一種隱含的紀律：
- 越無聊的測試越要細
- 越累的迭代越要堅持跑完
- 不能因為煩就跳步驟
這份紀律是對的。但它只說了一半。
剩下的那一半是——有些「煩」是任務在告訴你它放錯位置了。
如果你聽不懂這個訊號，你會把自己的時間耗在一件本來不該由人做的事情上，然後把這份耗損當作「敬業」。但敬業不是「能忍多少煩」，敬業是有沒有能力辨認出哪些煩值得忍、哪些煩是組織該幫你解決的。
煩有兩種：
- 第一種煩：來自工作本身的張力——要面對不確定性、要承擔風險判斷、要拒絕做不該做的妥協。這種煩不該被自動化掉，這是 QA 的核心職能。
- 第二種煩：來自於「機器其實做得比你好」的重複勞動。這種煩該被自動化，留下來只是浪費 QA 的腦力庫存。
兩種混在一起，所以才會有人把「我每天都好煩」當作職業徽章。但其實該被自動化的那一塊，留得越久，你越無法分辨自己現在的疲倦是來自於「正當的張力」還是「不該扛的勞動」。
這篇文章要拆解的，是怎麼判斷你眼前這份煩，屬於哪一種。
二、五個訊號：當你眼前的測試符合這幾個訊號，它在跟你討救兵
訊號一：高重複率（同一段操作模式，每次幾乎一樣）
你做的事情可以用一段流程描述：「點 X → 等 Y → 確認 Z」，而每跑一組，這段流程是 99% 相同的。
判斷標準：你能不能用一句話把這個操作流程講完？如果可以，那它跟「人」沒關係。
我的篩選功能就是教科書例子——每組條件的測試動作，從第一組到第八十一組，操作模式完全一樣。
訊號二：低變異性（結果有明確的期望值）
不是「我看一下結果合不合理」這種需要審美判斷的測試，而是「結果就該長這樣，否則就是錯」。
判斷標準：你能不能寫出一條確定性的規則來描述「對」是什麼？例如「篩選價格 1000-2000，結果不該出現價格高於 2000 的商品」——這就是一條可寫成 assertion 的規則。
如果你發現自己每一組都在重複「我預期這個結果該是 ⋯⋯」這個內心獨白，那這個獨白應該寫在程式碼裡，不是寫在你的腦袋裡。
訊號三：結果可機器驗證（不需要人類審美）
這個訊號跟訊號二相關，但更強。它問的是：驗證這個結果，需要「人類常識」嗎？
- 需要人類的例子：UI 看起來「順不順」、文案「自不自然」、流程「直不直覺」——這些離不開人。
- 不需要人類的例子：篩選結果的 ID 列表、API 回傳的 JSON 結構、DB 查詢回來的記錄筆數——只要規則寫得出來，機器跑起來比你還準、還不會累。
如果你發現自己測一個東西時，每次都在做「這個資料筆數對不對」「這個欄位有沒有跑進來」這種比對動作，那你正在用人類的時間做機器的工作。
訊號四:組合爆炸（條件多到指數級）
QA 圈最常被低估的痛點之一。
- 4 個條件、每個 3 個值——81 種組合
- 5 個條件、每個 4 個值——1024 種
這個成長速度，人手是跟不上的。要嘛你跑不完、要嘛你開始偷工。
判斷標準：你的測試空間是不是「乘法級」的？如果是，自動化不是錦上添花，是必需品。
（額外提醒：自動化之後還有一個常常被忽略的優化空間，是 pairwise / 正交實驗設計——把 81 種壓到 9~13 種。這是另一篇文章的題目。）
訊號五：執行時間長到改變你的測試姿態
這是五個訊號裡最危險的一個。
當一輪測試需要兩小時、半天、一整天才能跑完時，你的腦袋會自動進入一個你沒察覺的模式：
- 跳過某些「應該不會錯」的組合
- 默默放寬驗證標準
- 在最後幾組偷偷收手
- 把「這個之後再仔細看」放進心裡，然後忘記
這個訊號最可怕的地方不是它讓你慢，是它讓你壞。它腐蝕的是你身為 QA 最重要的東西——判斷的紀律。
而紀律一旦因為時間壓力被讓步過一次，下次再讓步就更容易。這比任何技術 bug 都嚴重。
三、篩選功能為什麼是教科書答案
集合以上五個訊號於一身：
| 訊號 | 篩選功能符合嗎？ |
|---|---|
| 高重複率 | ✓ 每組條件操作模式一致 |
| 低變異性 | ✓ 結果有明確的期望規則 |
| 結果可機器驗證 | ✓ API/DB query 即可比對 |
| 組合爆炸 | ✓ 條件數 × 值數的指數級空間 |
| 執行時間長 | ✓ 人手跑往往以小時起跳 |
如果這還不該自動化，那什麼該？
但我必須誠實地承認——很多 QA 團隊，包括很多有能力寫自動化的 QA，都沒有真的把篩選功能自動化。下一節要拆的就是這個矛盾。
四、那為什麼很多 QA 沒這樣做？
幾個常見原因，我每一個都聽過、也都半信過：
1.「自動化要會寫程式，我還沒到那個程度」
這個門檻在過去十年已經被 pytest、Playwright、Cypress 這類工具大幅壓低，加上現在還有 AI 輔助寫測試。技術門檻仍然存在，但比想像中低很多。
2.「我們團隊不重視自動化投資」
這是真的問題，也是接 〈用 specs.md 餵 AI 生測試案例之前——先問一句：誰負責讓那份文件不過期？〉 那篇的命題——組織文化把 QA 鎖在重複勞動裡，是一種隱形的浪費。但個人能做的是：先在自己負責的範圍裡示範，等示範跑出 ROI，再讓主管看見。
3.「短期 ROI 算不過來——這個 sprint 我手動跑得完，何必投資自動化？」
這是最常被講的一句話。但它的盲點是——這次的「跑得完」，是用你下個 sprint 的時間預支來的。你的耐力就那麼多，今天耗在點篩選，下次出包時你會發現自己沒餘裕做應該做的探索式測試。
4.（最深的一個）「QA 的價值在於人手測」
這是一個陳舊的職業自我定義。在我看來，QA 的價值從來不在點擊次數，而在判斷力——判斷哪些該測、判斷哪些不需測、判斷出問題時該怎麼解。判斷力是稀缺資源，把它耗在點篩選——等於把鑽石當磚頭用。
五、與前一篇〈用 specs.md 餵 AI〉互為鏡像
我前一篇 〈用 specs.md 餵 AI 生測試案例之前——先問一句：誰負責讓那份文件不過期？〉 寫的是組織層面的失靈：公司把「文件維護」這種灰色地帶的工作丟給沒能力扛的人，然後期待 AI 能幫他們收尾。
這篇是它的反面：QA 也不該把「可自動化的勞動」丟給自己。
兩者表面看起來方向相反，但背後是同一個原則：
讓人去做只有人做得好的事；讓機器去做機器做得更好的事。
組織的失靈，會把人耗在文件維護這種模糊勞動裡。
QA 自己的失靈，會把自己耗在篩選組合這種重複勞動裡。
兩個方向必須一起動，整個 QA 生產力才會真的提升。一個只動組織不動個人，QA 還是被綁住；一個只動個人不動組織，個人會變成在失靈組織裡更孤獨的高手。
六、深一層：無聊本身是一種訊號（從《無聊心理學》談起）
讀過 James Danckert 跟 John Eastwood 的《無聊心理學》（Out of My Skull: The Psychology of Boredom）之後，我對「煩」有了新一層的理解。
書裡的核心定義很精準——無聊不是「沒事做」，是「心智空閒」加上「想投入某件事卻找不到那件事」的組合。一個人不會因為閒而無聊，會因為想做點什麼但現在做的事沒用到自己而無聊。
更微妙的是，書裡有一個我很久沒想清楚的觀察：「缺乏投入」比「缺乏意義」更容易直接引起無聊。所以滑社群媒體雖然意義稀薄，但因為提供投入感，可以暫時把無聊壓下去。
但那只是「壓下去」，不是治好。短期填補解決不了長期的訊號——那個訊號還在那裡，反覆說著同一句話：
你身上的能力，沒被用在它該被用的地方。
把這個視角搬回 QA 工作——
你在點第八十一組篩選條件時那份「煩」，不是因為這件事沒有意義（守住品質明明就有意義），是因為這件事沒有讓你投入。你的判斷力、你的不和諧感、你身為人類被需要的那些能力，都沒被用上。
機器點得比你準、比你快、比你不會累——這個動作，社會其實不需要由你來做。
但你身上有些能力，社會真的需要由你來做：
- 判斷哪些 bug 會讓使用者真的受傷
- 判斷產品的設計是不是踩了道德底線
- 判斷團隊的紀律是不是正在腐蝕
- 判斷主管的 trade-off 提案是不是合理
- 判斷「我們現在到底在做什麼」這個問題的誠實答案
這些是 AI 暫時做不了的事，是人類被需要的位置。
所以「煩」的最深層意義是這個——它是你身上的能動性在替整個系統呼喊：「我被擺錯地方了，請把我擺到真正需要我的位置上」。
把這份呼喊聽進去，比任何 ROI 計算都更有重量。把篩選自動化掉這件事，意義不只是「我輕鬆一點」——它是把人的能力解放回社會真正需要由人做的地方。
這跟前面五節的論述其實是同一件事的不同層次：操作上是 ROI、組織上是分工、職涯上是視野——而存在意義上，它是無聊作為一種訊號，呼召你投入真正需要你的事。
七、聽到訊號之後，要怎麼動？
三步：
1. 把疲倦量化
不要只跟主管說「這個很煩」。把它寫成數字：
- 我每週花在這個測試上的時間：__ 小時
- 這份時間佔我總工時的比例：__%
- 在這份時間裡，我抓到的真正 bug 數：__ 個（通常很少，因為這類重複勞動的 bug 密度低）
- 過去三個月有沒有因為時間壓力而漏跑的組合：__ 組
數字是跟主管溝通最有效的語言。
2. 估自動化投資
- 我學會 X 工具需要多久：__ 週
- 寫出第一版測試需要多久：__ 週
- 跑通 CI、可以日常使用需要多久：__ 週
加總通常 4-8 週，看起點。誠實估、不要為了爭取資源故意低報——低報之後做不到，扣的是你下次提案的信用。
3. 提案——不是談技術，是談 trade-off
跟主管的提案不要這樣寫：
❌「我想要把篩選功能自動化。」
（主管會問：那你原本的工作怎麼辦？）
要這樣寫：
✓「我目前每週花 X 小時在篩選功能的手動測試上。如果投入未來 6 週、每週 4 小時做自動化，第七週起這 X 小時可以降到 1 小時。代價是中間 6 週的覆蓋率短期下降到 80%。請主管選 A（維持現狀，保留 X 小時/週的成本到永遠）還是 B（短期投入，第七週起釋放出 X-1 小時/週做別的測試）。」
這跟我寫過的 〈測試工程師的「價值」如何量化？〉 是同一條紀律——用主管的語言談 trade-off，而不是用 QA 的語言談技術。
八、結語：把「煩」當作 QA 的診斷儀器
QA 的職業姿態，從來不是用「能忍多煩」來證明自己的敬業。
是有沒有能力辨認出「這份煩在告訴我什麼」。
煩可能在告訴你：這個任務該被自動化了。
煩可能在告訴你：這個產品的設計需要重來。
煩可能在告訴你：這個團隊的工作分配出了問題。
煩可能在告訴你：你不該繼續扛這份不屬於你的責任。
煩可能在告訴你：你身上的能力，社會還有別的地方更需要它。
把煩當訊號來讀，你就比那個「咬牙撐過去」的版本，多了一個維度的觀察力。
而那個觀察力，恰恰是 〈問題驅動測試〉 的核心——不要把感受當成終點，把感受當成提問的起點。
PDT 適用於測試對象，也適用於測試員自己。
下次你發現自己又在做一件煩到想睡的測試時，別急著用「敬業」蓋過那份煩。坐下來，問自己一個問題：
這份煩在告訴我什麼？
如果答案是「這個任務不該由人做」，那就是時候動了。
給也是基督徒的讀者：一個禱告
如果你不是基督徒，這篇文章到上一段就結束了，謝謝你陪我讀到這裡。
接下來，請容我以基督徒的身分，用一段簡短的禱告為這篇文章收尾。
主，
謝謝祢給了我「煩」這個訊號。
原來它不只是疲倦，是祢在提醒我——
我身上的能力是祢造的，不該耗在機器更擅長的事情上。
求祢讓我有勇氣，把該交給機器的交出去；
也讓我有判斷力，把該由人守住的守住。
在 AI 越來越能做事的時代，
讓我聽得到祢呼召我去的位置——
那個真正需要一個有名字、有信用、願意簽名的人的位置。
奉主耶穌基督的名禱告，阿們。