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

實習的時候我開單很勤。

重現步驟、預期結果、實際結果、截圖，該有的都有。按下送出，那張單就從我的畫面上消失了。

我以為後面有人在管。

我沒想過「管」這件事需要什麼

〔Day 15 講的是那張單預設會落到誰手上〕（連結待補，Day 15 發布後補上）。這篇講下一步：接到單的那個人，要做什麼。

我當時的想像很單純。有一份清單，有人排順序，排到了就修。

我沒想過「排優先順序」需要什麼能力。

追功能和追 bug 是兩件事

這兩件事只有名字像。

最後一列是整篇的重點。

追功能追得好，會出現在考績上。追 bug 追得好，不會出現在任何一張表上。Day 6 講的非晉升性任務，這是又一個。

而做 bug 管理需要的判斷，跟做功能需要的判斷不是同一組。severity 要校準、重複的單要合併、要看得出這張跟上一版哪張同源——這些沒有人教過接手的人，因為在他的職務描述裡，這件事根本沒有被寫下來。

所以它掉在地上

把 bug 預設給產品端（Day 15 那六種的第一種）有一個很實在的好處：QA 的 inbox 清空了。

但搬走的是追蹤的勞動，搬不走的是判斷的專業。

搬不走的那一半會以別的形式回來。評級開始飄移，因為給 severity 的人用的是商業直覺。重複的單沒有人合併，因為要合併得先知道怎麼搜舊單。同源的關聯沒有人建，因為建它得記得上一版出過什麼事。

然後某一天有人回頭問你：這張跟之前那張是同一個嗎？

負擔沒有消失。它只是從一個 inbox，變成零碎的諮詢。

我做過的事，跟做不到的事

我有段時間為了要增進跟 PM 的關係，每次開了一些 bug 之後，我就會跟PM約個時間，走過去對方座位，跟他溝通這次測試遇到哪些 bug ，重要不重要的都跟他一一確認過一次，對方也蠻友善的，很願意跟我討論說哪一些優先程度比較高，哪一些可能真的還好，或者是他自己有些參數沒有設定正確。

我到現在也沒有把這個洞補起來。

補不起來的原因很具體：補它需要有人決定這件事算誰的工作，而我不是那個人。Day 11 那份沒人敢刪的清單卡在同一個地方，只是那邊卡的是刪，這邊卡的是收。

我能做的剩兩件事。把單寫到不用問我也判斷得出來。有人來問「這張跟那張一樣嗎」的時候，回答得夠快。

這兩件事都不會讓那個洞消失。它們只是讓掉進洞裡的東西少一點。

帶走的一樣東西

如果你開的單經常沒有下文，先別急著歸因到自己身上（單寫得不夠清楚、我沒有去追）。

先問一句：在這裡，決定一張 bug 要不要修的那個人，這件事算在他的哪一個考績項目裡？

問不出答案的時候，那不是你的問題，是那份工作還沒有主人。

你唯一控制得了的是那張單本身。把它寫成不需要問你就能判斷的樣子，洞不會消失，但掉進去的東西會少一點。

明天聊：無主之地的另一塊。那份文件過期了，那是誰的工作。

延伸閱讀

• 你的團隊 Bug 預設給誰？業界六種主流 Bug 分派（Triage）模式對照
• 用 specs.md 餵 AI 生測試案例之前——先問一句：誰負責讓那份文件不過期？