本文是「測試之外的那一半：一個 QA 回頭帶當年的自己」系列第 21 篇。

Day 1 我問過一個問題：QA 的 A 是 Assurance，保證。但我在中文的辦公室裡，從來沒聽過有人用「保證」這個詞。

我們說的是「這個沒問題」「這個可以上」「這個我 hold 不住」。

那時候我以為那只是用詞習慣。這一週寫完，我想法變了。

六天，六件沒有人在保證的事

Day 15 那張 bug 單是怎麼跑到我面前的
一個新 bug 預設會派給誰，這件事沒有人決定過。它是繼承來的。

Day 16 我開完 bug 就交出去了
追功能追得好會出現在考績上，追 bug 追得好不會。所以沒有人保證那些單子會被處理。

Day 17 我讀不懂那份規格
規格有人寫，但「幫新人讀懂」跟「讓它不過期」都不在任何人的職責描述裡。

Day 18 我把 locator 寫得越來越聰明
元素的用途是誰決定的？是產品端。但沒有人保證那個決定會被記錄下來，所以 QA 每個 App 手工重建一次。

Day 19 兩條路我選了比較醜的那一條
跨專案的權限治理該有人統一管。沒有人管，所以那條乾淨的路就一直不通。

Day 20 你是在 QA 部門過得不開心嗎
這些事都沒有流程可以走。能不能推動，取決於你認不認識那個能動的人。

我以為「保證」是用詞問題，其實是狀態問題

我實習的時候以為，中文沒有人說「保證」，是因為那個詞太重、講出來太像在立軍令狀。

現在我認為原因更樸素：很多事情，本來就沒有人在保證。

不是大家迴避那個詞。是那個詞對應的狀態不存在，沒有一個人被指定要對它負責，所以講不出那句話的人，並不是謙虛，而是誠實。

回頭看這六篇，每一篇的形狀都一樣：

有一件事會影響品質。它需要一個判斷。而那個判斷落在職責的縫隙裡，沒有人被指定要做。

於是它要嘛不被做（那份沒人寫的導讀），要嘛被繼承（那個沒人決定過的預設），要嘛由最痛的那個人自己吞下來（每個 App 重推一次 locator）。

第一週跟第三週接起來了

第一週講的是別人沒有講出來的擔心。你得把它挖出來，才知道要測什麼。

第二週講的是我自己講不出依據。我得把判斷的理由寫下來，交出去的才是資訊而不只是綠燈。

這一週是再上一層：有些擔心沒有主人。

沒有人在擔心那份文件會過期，因為它不會讓任何人的數字變難看。沒有人在擔心那些 bug 老化，因為老化不會觸發任何警報。

而 QA 常常是第一個撞到的人，因為品質問題最後都會流到測試這一關。

這就是為什麼我實習的時候會覺得「我好像比較忙」。我不是比較忙，我是坐在所有縫隙的下游。

我能給你的，跟我給不了的

我先說我給不了的。

這六件事，我一件都沒有真正解決。我不能決定 bug 派給誰、不能讓文件維護變成某人的 KPI、不能改掉那個放錯層級的決策、不能統一跨專案的權限。這些都需要有人在組織設計上做決定，而我不在那張桌子上。

我能給的只有一件事：一個比「我不夠好」更準確的解釋。

實習的時候我把這些通通歸因到自己身上。我比較忙，是因為我不夠熟練。我讀不懂，是因為我程度不夠。腳本一直壞，是因為我技術不行。

那些歸因大部分是錯的。我確實有很多要補的東西，Day 17 那個領域知識就真的該我自己讀。但把結構的問題算到自己頭上，會讓你在錯的地方浪費太多時間。

看懂它在哪一層，至少你會把力氣花在對的地方。有時候那個對的地方是「做一個小到有人願意點頭的提案」，有時候是「把代價算出來寫在有人看得到的地方」，有時候只是「別再拿它當作自己不夠格的證據」。

下一週換一邊

前三週講的是人跟組織。

最後一週回到手上：AI 進來之後，這份工作有哪些部分真的變了，哪些沒有。

我會講我實際在用的分工，AI 接手了哪幾塊、哪幾塊我到現在還不敢交出去、以及為什麼不敢。也會講幾個具體的排查現場：畫面黑掉的時候怎麼判斷是誰壞了、測試偶爾失敗的時候那個「偶爾」在說什麼、本地能跑 CI 不能的時候該先懷疑什麼。

比起這一週，那一週會比較好寫。因為那些問題大部分真的有解法。

明天見。