前言：表面缺截圖，裡面缺的是別的東西
某天下午，我快把新功能測完了——正準備補剩下的幾個 edge case（邊緣案例）、抓截圖、錄影、整理報告——測試站的登入服務掛了。
時間點剛好。功能驗證做得差不多，但 artifacts（截圖、錄影等測試產出） 不齊。PM 在敲我「下週一就要上」，我選了一條中間路：先把報告交出去，註明「截圖週一補（登入服務當下不可用）」。主管 OK、PM OK、團隊也算能理解。
但那天結束之後，我心裡卡了一個問題，那個問題跟登入無關、跟截圖也無關——
「我真的測完了嗎？」
寫這篇，是為了好好回答這個問題。
一、「快測完了」這四個字，藏著什麼
我可以說「我快測完了」、「主要 case 都跑過了」、「我感覺沒問題」——這些話我講得很順，但我講不出「我覆蓋了哪些、沒覆蓋哪些」。
平常這個問題不會浮上來。因為我可以一直回去點點看：心裡卡卡的 case 再跑一次，懷疑某個流程沒測再跑一次，發現某條 path 漏了再補一次。我的「測完了」感，是『隨時可以回去確認』撐起來的。
登入一掛，這個撐住「測完了感」的東西就沒了。
我才意識到——我的「測完了」一直是後驗的、靠摸出來的、靠多跑幾次補回來的。它不是一開始就有計畫、有清單、有覆蓋率定義的東西。
那一刻很尷尬：如果有人問我「你哪些測過了哪些沒測？」我答不出來。
二、Jersey Su 引用的那道題：「10 分鐘，寫一份測試計畫」
讀過 Jersey Su 的〈計畫趕得上變化〉，他引用 Google 測試前輩 James Whittaker 給團隊出的一道題：
「給你 10 分鐘，寫出一份測試計畫。」
Whittaker 在《How Google Tests Software》裡寫過這段故事——他剛接手 Google 部分產品的測試工程時，發現團隊習慣花上幾週寫一份巨大的、沒人會回頭翻的測試計畫文件。所以他出了這道挑戰題：把計畫壓到 10 分鐘。如果一份計畫有價值，那它的價值應該在 10 分鐘內就能浮現。
Jersey 自己把這個練習調整成「30 分鐘寫一頁式測試計畫（One Page Test Plan）」，當作肌肉記憶在練。
但這道題如果只看「快」這個字，是會誤讀的。Whittaker 同時提了一個配套的方法，叫做 ACC——這才是這道練習真正在回答的問題。
三、ACC 是什麼：把 QA 思考拆成三個欄位
ACC 是 Whittaker 在 Google 推的測試計畫框架，三個字母代表：
| 字母 | 全名 | 詞性 | 你在問什麼 |
|---|---|---|---|
| A | Attribute（屬性） | 形容詞 | 使用者在乎這個產品什麼？快？穩？安全？容易上手？ |
| C | Component（元件） | 名詞 | 這個系統由哪些可分離的部件組成？ |
| C | Capability（能力） | 動詞 | 系統能為使用者做什麼？每個能力的優先級多高？ |
ACC 的順序很重要：先從使用者在乎什麼開始（A），再拆系統有什麼（C），最後談這些部件提供什麼能力（C）。Capability 被打上優先級與風險評分之後，就直接變成了「測試該往哪裡放力氣」的依據。
四、ACC 真正在回答的，是那個我答不出來的問題
我以前以為 ACC 是給「測試前」用的工具——產品剛立項、需求剛來，QA 拿來寫計畫。
但登入壞掉那天我才看見它另一個樣子：ACC 是測試完之後，QA 用來自我審問的工具。
ACC 把測試的覆蓋變成可以被檢查的東西：
- 使用者在乎的 Attribute，我有沒有都覆蓋到？（不只是功能對不對，還有「快不快」「順不順」「會不會嚇到人」）
- 系統的 Component，我有沒有都跑過？（包含邊界元件、依賴的元件、容易被忽略的元件）
- 高優先級的 Capability，我有沒有都驗證？（不是 case 數量多寡，是高優先級項目的覆蓋率）
寫完這三欄，「我測完了嗎？」這個問題從『感覺』變成『可以指著清單回答』。每一格都有答案，就是測完了；某一格空著，就還沒測完——而且你能講得出「還缺哪一格」。
這就是為什麼 Whittaker 敢說「10 分鐘」。不是逼你打字快，是逼你練到熟，熟到你可以隨時拿這份結構出來檢查自己。10 分鐘只是熟練度的證明。
而我在登入壞掉的那個下午——我發現我沒辦法拿這份結構出來檢查自己，因為我從一開始就沒寫過。
五、所以那天我做的，其實是「事後補一份 ACC」
當時我並沒有覺得自己在補測試計畫。但事後看，我那兩個小時做的三件事，每一件都對到 ACC 的一個欄位：
- 梳理舊 bug 的脈絡 — 我在事後問「過去使用者在哪個 Attribute 上最容易受傷？（穩定性？資料正確性？權限？）」
- 盤點哪些測試需要登入 — 我在事後問「Component 之間的依賴怎麼畫？哪些其實不依賴登入也能驗？」
- 重排 case 的優先順序 — 我在事後問「Capability 的優先級到底長什麼樣？哪些必須測、哪些可以晚？」
三件事拼起來，就是一份遲到的 ACC。
而做完之後我發現一件殘忍的事：有兩三個 case 我以為測過，其實是漏的——只是平常我可以隨時補測，所以沒意識到「漏」這件事的存在。是 ACC 把它逼出來的。
如果登入沒掛，我大概不會做這個練習，這份報告就會帶著兩三個我自己都不知道的洞被交出去。
登入服務掛掉那天，幫我做的不是「製造一個藉口」，是「製造一個必須誠實面對覆蓋率的時刻」。
六、然後下班後，我心裡冒出一個小聲音
ACC 的部分我事後補上了。但下班後我重看了一次交出去的報告，心裡的小聲音問我：
「截圖週一補（登入掛了）」這句話，到底是『事實說明』，還是『一個方便的擋箭牌』？
我才發現這句話其實有兩層問題。
第一層：表面像甩鍋
報告因為帶了那一句註記，自動變成了一份「指出 cause 的報告」——而 cause 是另一個團隊。如果這次上線順利，沒人會回頭看；但如果上線後出事，這份報告會被翻出來——上面寫著「截圖未補，因為登入服務掛了」。
| 維度 | 解釋原因（OK） | 甩鍋（NOT OK） |
|---|---|---|
| 焦點 | 我做了什麼、還缺什麼、什麼時候補 | 誰造成的、不是我的錯 |
| 主詞 | 我（我會補上） | 他們（因為他們壞了） |
| 時態 | 未來（接下來） | 過去（誰要負責） |
第二層：暗中替「我自己沒把握」找掩護
但這還不是最不安的部分。最不安的是更裡面那一層：
我寫「截圖週一補（登入掛了）」的時候——我描述的「不齊」是 artifact 的不齊（缺截圖）。可是那個下午我心裡真正卡的，是 coverage 的不齊（我不確定有沒有測完）。
這兩種不齊，我都用同一句話打發掉了。
第一種不齊（截圖）有明確的歸屬：登入壞了所以補不了，是客觀事實。第二種不齊（覆蓋率）的歸屬是我自己——但是因為我把兩種不齊綁在同一句註記裡，第二種不齊也跟著沾上了「因為登入壞了」的味道。
這個就是我事後想到最不舒服的地方。它不是甩鍋給開發團隊，是甩鍋給「狀況」——讓「狀況」幫我吸收掉一份我對自己的不確定。
外人看不出來，但我自己看得出來。
七、寫法的紅線：缺的東西，主詞永遠是我
事後我給自己訂了一條紅線——
缺的東西，主詞永遠是我；而且「缺什麼」要分清楚。
下次遇到一樣情況，我會這樣寫：
- ❌ 「截圖週一補（登入掛了）」
- ✅ 「測試覆蓋（依 ACC 清單）已完成主要 Capability 驗證，剩 [X 功能的權限切換邊界] 待補測。週一補上截圖。（補充：當下登入服務不可用）」
差別不只是禮貌——是我強迫自己把兩種不齊拆開來、各自負責：
- 覆蓋率的部分：是我的責任，主詞是我，我講清楚剩什麼
- artifact 的部分：客觀情況的影響，可以提，但放在後面、放在小字
ACC 在這裡的功能是——它逼我把「缺什麼」講清楚，沒辦法用「截圖週一補」這種模糊措辭把覆蓋率不確定一起帶過去。
結語：忠心是「敢用 ACC 問自己有沒有測完」+「誠實署名」
寫到最後，我想講那天最真實的感受。
聖經裡有一句話我以前讀過：「所求於管家的，是要他有忠心」（哥林多前書 4:2）。我以前一直把它讀成「管家要把工作做好」。
但那天我重新想了一次——這句話真正的重點是「忠心」這個詞，它跟「把工作做完」其實是兩件事。把工作做完要有工具、有時程、有資源；忠心不需要這些，它是「這個位置交給我的時候，我願不願意誠實面對自己做到了什麼、沒做到什麼」。
那天我學到的是——忠心是兩件事的合一：敢用 ACC 反過來問自己「我真的測完了嗎」，也願意把答案誠實寫進報告裡。
「敢用 ACC 問自己」是 Whittaker 那道題練出來的肌肉——10 分鐘寫測試計畫的能力，不是給你 demo 用的，是給你在交報告前 10 分鐘救自己用的。它把「測完了」從感覺變成可以被檢查的東西，讓你不敢隨便講「測完了」這三個字。
「誠實署名」是報告的工藝——我交出去的東西，主詞是不是我？我有沒有把『缺截圖』跟『缺覆蓋』混在一起、讓狀況幫我吸收掉一份我對自己的不確定？
我不掌管測試站什麼時候會修好。我只負責那一段時間裡認真活著——用 ACC 問自己有沒有測完，用主詞權承擔那份回答。
那天結束的時候，我一個新 case 都沒跑——但我第一次清楚知道自己漏了哪幾格，也第一次寫得出「缺什麼是我該補的、缺什麼是狀況造成的」。
工具是 QA 的延伸，不是 QA 本身。
延伸壞了，本體還在——但本體要先願意被自己看清楚。