為什麼 QA 需要第二大腦？

為什麼 QA 需要第二大腦？ 上線前三天，測試計畫卡關了。 負責回歸結帳模組的資深 QA 臨時請假。沒人知道哪些 case 是因為某次歷史事故才加上去的、哪些邊界條件是業務特別交代的、哪個流程在某版改過又改回來。測試計畫有，但很薄，只列了 case 名稱，沒寫為什麼要測。 三個選項：等他回來、自己猜、砍 scope。三個都不好。 這怪不到那個 QA 頭上。沒有地方可以放的時候，每個人都會把最重要的判斷留在腦袋裡，因為那裡最快。代價是這個模組的知識 bus factor = 1，他不在，就沒人接得住。 我自己是回去支援手動測試之後才撞上這件事。要測哪些情境、哪裡以前出過事、這次改動會影響誰，答案散在我的筆記、舊 bug 單、會議紀錄，還有同事的腦袋裡。每次測新功能都要重翻一遍，翻完下次又忘了。（那段經過寫在從寫自動化到經營知識庫。） 測試知識是 QA 最大的隱形資產 QA 做久了，腦袋裡會累積這些東西： 這個業務規則為什麼這樣設計，背後有什麼例外。 上次上線前沒抓到的 bug 從哪來的，為什麼那個 case 是後來才補的。 「改了這裡，通常要連帶回歸那裡」的隱性地圖。 哪些 case 是因為客訴加的，哪些是因為某個工程習慣要特別留意。 這些東西不在 Jira、不在 spec 文件、不在任何版本紀錄裡。它們是做了兩三年才長出來的判斷力，偏偏也最容易跟著人一起消失。 搜不到，也交接不了。你一請假，它就跟著你一起休假。 外部化的投報 寫文件很花時間，這是真的。可是大部分文件系統只解決了「存起來」，沒解決「找得到、拿來用」，寫了跟沒寫差不多。 做對了，回報會出現在四個地方。 減少重複問。「這個欄位怎麼驗？」「這個模組有沒有已知邊界條件？」如果系統裡找得到，就不需要問人、不需要佔用資深成員的時間。 減少重造輪子。每次測新功能從零設計 checklist，其實很多判斷前人做過了，只是沒有留下來。留下來之後，就能直接拿來組裝、重用。 降低 onboarding 成本。新人接手一個模組，靠的是口耳相傳或 shadow。如果知識在系統裡，他可以自己讀、自己找，三個月後還在問基本業務邏輯的狀況就少了。 降低 bus factor。組裡不再只有一個人知道那個邏輯。知識不綁在個人身上，就算輪組、請假、離職，系統仍然在。我們組裡是在同事開始自己把負責的知識補進去之後，那一塊才不再只有我知道。 第二大腦是什麼 這個系列用「第二大腦」來指那個外部化的知識系統。但它不是把腦袋裡的東西全部倒進去。我一開始就是這樣，看到相關的就收，結果文件越收越雜，要找的時候反而抓不到重點。它要有三個特徵： 可檢索 ：你需要的時候找得到。這是最基本的要求。一個只能靠「我記得放在哪裡」才找得到的系統，等同於不存在。 可重用 ：找到的東西能組裝起來用。不是只能讀，是可以直接拿來做測試計畫、寫回歸範圍、應付新功能設計 case。 會自己浮現 ：最難做到，也最值得。你不用記得去翻，需要的時候，相關的知識自己會跳出來。這靠的是結構設計：讓知識之間有連結、讓業務規則和 case 綁在一起、讓改動一發生，相關的知識就一起被觸發。 少了任何一個，系統都會慢慢變成沒人想翻的文件堆。 這個系列要去哪裡 這個系列共 9 篇，每篇處理一個痛點。 S02 ：需求散在 Slack、Figma、Jira、嘴巴，你永遠在問「這版到底要幹嘛」。怎麼建一個蒐集漏斗，讓知識進來有地方落。 S03 ：案例庫長到沒人信、沒人敢刪。怎麼分層讓活的浮上來、死的下沉。 S04 ：每次都從零設計 case，同樣的 checklist 重造輪子。怎麼把判斷變成可重用的知識塊。 S05 ：「這次改動要回歸哪些？」算不出來，只能憑記憶。把 case 連到業務規則，影響範圍自己浮現。 S06 ：同一類 bug 每季重來，團隊學不到教訓。把 bug 整理成下次設計測試時用得上的經驗法則。 S07 ：新人接手三個月還在問基本邏輯。第二大腦當 onboarding 資產。 S08 ：知識囤一堆卻用不出來。輸出導向：讓知識可行動，測試計畫由零件組起來。 S09 ：系統建好但沒人維護，三個月後又爛回去。輕量維護、定期回顧、讓系統長在工作流裡。 每篇讀完能直接動手做一件事。不需要全部做完才有用，每一篇都是獨立的改善。 如果今天只想做一件事：挑一個只有你知道的業務邏輯，例如某個特殊驗證規則、某個歷史遺留的邊界條件，寫下來，放進一個固定的地方。就一條。我自己也是從這種最笨的手動整理開始，架構是後來才長出來的。 下一篇：需求散落在各處，怎麼建蒐集漏斗讓知識進來有地方落？