本文是「測試之外的那一半：一個 QA 回頭帶當年的自己」系列第 15 篇。
實習的時候，bug 單會自己出現在我的待辦裡。
我做的事情很固定：照著重現步驟走一遍、確認沒重現、關單。Day 10 講的就是那十分鐘。
我從來沒有問過，那張單子在跑到我面前之前，經過了誰。
我實習的時候遇到 bug ，預設是在 Slack 上群組通知RD跟PM，給 PM 看過後再派給RD去修。
後來我待過兩間公司，bug 的流程像得驚人。都是按模組分派給對應的 owner，再每週開一次會，把卡住的、有爭議的攤開來決定。兩間都是 PM、RD、QA 坐在同一個團隊裡，所以那個會很小，同團隊的不同職能坐下來談就決定了。
我一度以為這就是業界常態。bug 本來就該按模組分、每週開會推，不然要怎樣。
直到我認真做了一輪 survey，才發現那只是六種模式裡的一種組合。
| 預設給誰 | 常見在哪 | 代價 |
|---|---|---|
| PM | B2C、product-led 組織 | 商業優先級判得準，但 severity 估不準，也看不出兩張單其實是同一個根因 |
| Tech Lead | 工程主導的團隊、infra | 修復難度估得準，但體驗類的 bug 容易被低估 |
| QA | 金融、醫療、高合規 | 去重和 severity 最一致，代價是 QA 慢慢變成預設清潔工 |
| 未分派佇列 | open source、客服中心 | 負載自然平均，但沒人撿的就一直沒人撿 |
| 每週 triage 會議 | 大公司的跨部門委員會，也有團隊內的輕量版 | 歸屬很明確，但 bug 要等到下次開會 |
| CODEOWNER | 大型 codebase | 專業對位，但跨模組的 bug 卡在邊界互推 |
真實世界很少有純的。(挖靠這AI不知道純這個字在台灣有其延伸意涵嗎)
大部分團隊都是兩三種混在一起。
所以該問的不是「我們是哪一種」，是「我們這個混法，把成本壓在誰身上」。
一個 backlog 裡面，同時堆著四種人用四種語言寫的東西。
客服寫的是情緒：使用者很生氣，說 app 一直閃退。RD 寫的是 stack trace。PM 寫的是影響範圍和商業權重。QA 寫的是重現步驟。
很少有人四種都讀得流利。而每一種分派模式，都會在它最不擅長的那一種語言上失手。PM 讀不流利技術，Tech Lead 讀不流利客訴，QA 讀得最全但被當成翻譯機，未分派佇列乾脆沒人讀。
換模式只是把失手的位置，從一個人移到另一個人。
我得誠實講一件事：看懂這個之後，我的處境沒有變好。
我還是不能決定那些單子預設要派給誰。那是更上面在決定的，而且多半不是開會決定的。它是繼承來的——前一個人怎麼做，這一任就照著做，中間沒有人停下來討論過。
Day 11 那份沒人敢刪的清單是同一種東西。沒有人在維護它，因為維護它不是任何人的工作。
看懂只換到一件事，但那件事不小。
實習的時候我常覺得自己比較忙、比較容易被塞事情，然後把它解釋成我大概還不夠熟練。
那個解釋是錯的。我忙的原因寫在那張流程圖上，不在我的能力上。
找一天問一句：我們這裡，一個新 bug 預設是誰的？
問完再問第二句：這個預設是誰決定的？
第二句通常沒有答案。沒有答案本身就是答案：這個預設是繼承來的，沒有人決定過它。
你未必改得動它。但你可以停止拿它當作自己不夠好的證據。
明天聊：bug 管理明明是一門專業，卻不在任何一個人的 KPI 上。
iThome鐵人賽
看影片追技術