QA 的第二大腦 — 把測試知識變成會自己浮現的系統

1. 為什麼 QA 需要第二大腦？ — 「那個業務邏輯只有某個資深 QA 知道，他一請假整個版本測試就卡住。」測試知識住在少數幾個人腦袋裡，bus factor 就是 1。這篇講 QA 為什麼要把知識寫出來，以及一個找得到、用得上的知識系統長什麼樣子。
2. 蒐集漏斗：讓知識進來有地方落 — 需求散在 Slack、Figma、Jira 和站會的一句話裡，某個關鍵驗收條件 PM 順口提過，沒人記，上線就出事。知識最常消失在蒐集這一關，原因是當下記錄太麻煩、也沒有固定地方放。這篇講三個原則，讓任何形式的知識進來都有地方落。
3. 組織：讓活的浮上來、死的下沉 — 測試案例庫越積越厚，幾百條 case 沒人知道哪些還準。想清理又不敢刪，最後變成打開只會更焦慮的知識墳場。卡住的原因是分類方式看不出哪些還算數。這篇講怎麼按「跟現在工作有多近」重新整理，讓現在需要的東西浮上來，過期的安靜下沉。
4. 可重用知識塊：你的測試零件庫 — 接到新功能、坐下來設計 case，寫到第三條又是那套：登入態、權限邊界、空值、錯誤訊息。每個 QA 心裡都有一本，卻很少有人寫出來共用。這篇講怎麼把反覆用到的測試思路整理成有名字的零件，下次設計 case 直接拿來組裝，不用從零想。
5. 把 Case 連到業務規則，讓影響範圍自己浮現 — PM 說「結帳流程的折扣計算邏輯改了一下」，你開始憑記憶圈範圍：折扣、運費、會員等級、稅金，圈了一輪心裡還是不踏實。這篇講怎麼把 case 連到業務規則，改動一發生，影響範圍不用靠回想就自己浮現。
6. 從踩過的 Bug 整理出測試啟發，同一類問題不再重來 — 又是時區問題。這季的跨日結算因為 UTC/本地時間搞錯出包，跟去年那次幾乎一樣，只是換了個功能。修完了，retro 寫了，大家點頭。三個月後，同一類 bug 換個地方又來一次。這篇講怎麼把踩過的 bug 整理成下次設計測試用得上的測試啟發。
7. 第二大腦當 Onboarding 資產：用索引筆記當地圖 — 新人來三個月了，還在問「結帳折扣怎麼算」「這個欄位為什麼要這樣驗」。知識明明都在系統裡，他就是找不到入口，只能一條條問你，你變成人肉索引。這篇講怎麼做一張索引筆記當地圖，讓新人順著入口往下走，不靠老鳥也能自己找到答案。
8. 輸出導向：知識要可行動，計畫與報告由零件組起來 — 又要寫測試計畫了。你打開空白文件，游標閃著。做過十幾次，腦袋裡也有一堆累積的知識，但還是從第一個字開始打。寫完發現跟上次那份八成像，只是又手刻了一遍。知識囤了一整個系統，真正要產出的時候卻沒派上用場。這篇講怎麼讓累積的知識輸出成測試計畫和報
9. 維護習慣：讓第二大腦長在工作流裡，不再爛回去 — 三個月前你建了一套系統，收件位置、分層、零件庫都有了。前兩週很勤，後來衝刺一來，沒空整理，它又悄悄變成另一個墳場。系統會爛，多半是因為把它當成一次性專案，沒有長進工作流。這篇講怎麼讓第二大腦不靠意志力也能活下來。