QA 的第二大腦：用 PARA 把散落的測試知識收成系統

QA 的第二大腦：用 PARA 把散落的測試知識收成系統 目錄 1. 測試知識，總是散落在十個地方 2. 為什麼「按主題分類」註定失敗 3. PARA：按可行動性分類 4. QA 早就有自己的筆記傳統 5. 把 PARA 套進 QA 的四個抽屜 6. 明天就能開始的三個動作 7. 結尾 測試知識，總是散落在十個地方 「這個訂閱還原的流程，之前是不是踩過什麼坑？」 PM 在群組丟出這句話時，我正在測別的東西。我盯著螢幕，腦中浮起一個很確定卻很模糊的感覺： 踩過。大概一年前。好像跟跨裝置的時間戳有關。 但細節呢？ 接下來二十分鐘，我像在考古：翻 Jira 的舊票、往上爬一年前的 Slack 對話、打開那個塞滿隨手記的 Obsidian，最後在一個叫「臨時筆記 3」的檔案裡，找到半句當時的結論。 最讓我不舒服的不是那二十分鐘。是我意識到—— 這個坑我一年前就踩過、解過、還寫下來過。我不是不知道，我是找不到。 對 QA 來說，這幾乎是最虧的一種浪費：知識明明已經生產出來了，卻在最需要的那一刻調不出來。而它每天都在發生。 因為我們每天都在生產知識，但這些知識 散落在十個彼此不相通的地方 ：測試案例在 TestRail、bug 在 Jira、探索測試的隨手筆記在 Obsidian、模組的隱藏邏輯在腦中、跟 PM 吵需求吵出來的共識在會議記錄、heuristics 在某篇收藏了卻沒再打開的部落格。 知識沒有不見。但 需要的時候找不到，等於沒有。 更現實的痛點是：當我開始用 AI 幫忙生測試案例，這個問題被放大了。AI 不知道我們產品踩過的坑，因為那些坑根本沒有被好好收在一個 AI 拿得到的地方。我餵不出好的 context，它就只能給我「正常流程、空值、超長字串」這種誰都想得到的東西。 要餵好 AI，得先把自己的知識收好。問題是—— 怎麼收？ 為什麼「按主題分類」註定失敗 最直覺的做法是按主題建資料夾：效能測試、API 測試、安全測試、登入模組、訂閱模組…… 我試過。半年後它變成一個墳場。 知識管理專家 Tiago Forte 點出了原因： 按主題分類的最大問題是它沒有「可行動性」 。一則筆記放進「API 測試」資料夾後，它就躺在那裡，跟我「這禮拜要做什麼」完全脫節。我永遠不會主動打開「API 測試」資料夾——因為那不是我工作的方式。我工作的單位是「 這個版本要測的東西 」，不是「某個抽象主題」。 主題分類還有個更隱蔽的問題： 很多知識天生跨主題 。一個「訂閱還原在 iOS 跨裝置會時間戳錯亂」的 bug，到底該放 訂閱模組、iOS、還是 跨裝置同步？放哪都對，於是放哪都找不到。 分類的標準錯了。不該問「這則筆記是什麼主題」，該問「 這則筆記離我的行動有多近 」。 PARA：按可行動性分類 Forte 提出的 PARA 框架，把所有知識只分成四類，標準是「 距離行動的遠近 」： Projects（專案） ——有明確產出和截止點的事。例：「3.2.0 版的回歸測試」。 Areas（領域） ——需要長期維持、沒有結束點的責任。例：「訂閱模組的品質」。 Resources（資源） ——現在用不到、但未來可能參考的主題。例：「各種 heuristics 清單」。 Archives（封存） ——已結束的專案、放棄的東西、舊版本。 關鍵的洞見是： 同一則知識會隨著「它現在離行動多近」而在四個抽屜之間移動 。 「訂閱還原的時間戳 bug」這則筆記，在我正在測訂閱改版時，它屬於 Project （這版要驗的重點）；版本上線後，它沉澱成 Area （訂閱模組長期要顧的已知風險）；當這個功能整個被砍掉，它進 Archive 。同一則知識，位置隨行動改變——這正是主題分類做不到的事。 PARA 厲害的地方在於它不要求你想「這是什麼」，只要求你想「 我接下來要拿它做什麼 」。對每天被版本進度推著走的 QA 來說，這個分類標準天生合拍。 QA 早就有自己的筆記傳統 PARA 來自生產力圈，直接套到 QA 會有點水土不服——因為 測試這一行，其實老早就有自己的一套筆記學 ，只是很多人沒意識到。 2007 年，Michael Bolton 在 PNSQC 發表過一篇〈An Exploratory Tester's Notebook〉，整篇就在講一件事： 好的測試員怎麼記筆記 。他把測試筆記分成幾種角色——關於產品的事實、關於測試的想法、關於問題的線索、關於下一步的點子。這跟 PARA 的精神是同一件事： 筆記的價值取決於它能驅動什麼行動 。 再往前，2000 年 Jonathan 與 James Bach 提出的 SBTM（Session Based Test Management） ，更是一套結構化的知識生產法：每次測試是一個有 charter（這次要探索什麼）的 session，結束後做 debrief，把過程拆成 TBS——測試設計、bug 調查、環境設定。每個 session 都是一個迷你 Project，產出的筆記自然帶著「可行動」的格式。 還有 Bach 的 HTSM（Heuristic Test Strategy Model） ——它本質就是一套「測試該想到什麼」的分類法，是 QA 版的 Resource 抽屜。 所以對 QA 來說，第二大腦不是憑空套一個 PM 的框架，而是： 用 PARA 的可行動性原則，去整理我們本來就在產生的測試知識 。兩條傳統接起來，才是專屬 QA 的版本。 把 PARA 套進 QA 的四個抽屜 這是我自己的 QA 知識庫（一個 Obsidian vault，我叫它 qa brain）實際的分法： Projects——這個版本要測的東西 正在進行的測試。3.2.0 回歸清單、訂閱改版的測試 charter、這週要驗的 hotfix。特徵是有截止點，測完就移走。這裡的筆記直接對應我每天打開電腦要做的事。 Areas——每個模組的長期知識 不會結束的責任。每個核心模組一個檔：已知風險、歷史 bug、隱藏邏輯、跟 RD 確認過的邊界。訂閱模組 這個檔裡，就躺著那個害我翻二十分鐘的時間戳 bug——如果它一年前就在這，今天 PM 一問我十秒就能答。 這層也是餵給 AI 的黃金 context ：要 AI 生出有用的測試案例，就是把對應 Area 的內容丟給它——我把這套「讓 AI 真的懂產品」的做法，另外寫成了 QA Brain。 Resources——可複用的測試彈藥 跨專案的方法論。heuristics 清單、各類測試的 checklist、好用的工具筆記、收藏的文章。需要設計新測試時來這裡翻彈藥。HTSM、各種 test heuristics 都住這層。 Archives——舊版與已砍功能 上線很久的版本、被砍掉的功能、過時的測試計畫。不刪（哪天功能復活或要追溯歷史會用到），但搬出視線，讓前三層保持乾淨。 四個抽屜的判斷標準永遠只有一個問題： 這則知識，現在離我的行動多近？ 近到這週要用 → Project；長期要顧 → Area；可能會參考 → Resource；用不到了 → Archive。 明天就能開始的三個動作 不用一次重建整個系統，從這三步開始： 1. 先建四個資料夾 ，名字就叫 Projects / Areas / Resources / Archives（或中文）。先有抽屜，再慢慢往裡放。 2. 幫每個核心模組開一個 Area 檔 。下次發現一個跟產品歷史有關的 bug、或跟 RD 確認了一條沒寫在文件裡的邏輯，就丟進對應的 Area。這層會慢慢長成你最值錢的資產。 3. 每個版本測試開一個 Project 檔 ，charter、清單、過程筆記都放這。版本結束後，把裡面值得長期留的洞見「升級」進 Area，其餘整包丟 Archive。 關鍵心法只有一句： 整理的時候，不要問「這是什麼主題」，問「我接下來要拿它做什麼」。 結尾 QA 是一個高度依賴累積的職業。同一個產品測三年，你腦中那張「哪裡容易壞、為什麼壞、上次怎麼壞」的地圖，就是你最難被取代的價值。但這張地圖如果只存在腦子裡、或散落在十個工具裡，它就會隨著時間和離職一起蒸發。 PARA 給的不是一套要你多花時間的儀式，而是一個換掉分類標準的視角—— 從「按主題收納」改成「按行動收納」 。配上測試這行本來就有的筆記傳統，它能把你每天散落的測試知識，慢慢收成一個會增值、而且 AI 也讀得懂的第二大腦。 從建四個資料夾開始就好。 參考資料 1. The PARA Method — Forte Labs — Tiago Forte 提出的按「可行動性」分類的知識管理框架原文 2. The PARA Method — Building a Second Brain — PARA 四分類的官方說明 3. Building a Second Brain: The Definitive Introductory Guide — 第二大腦方法論的完整概覽 4. An Exploratory Tester's Notebook — Michael Bolton (PNSQC 2007) — 探索式測試的筆記方法經典 5. Session Based Test Management — Satisfice — Jonathan & James Bach 的 SBTM 原始文件 6. Session based testing — Wikipedia — SBTM 與 charter／TBS metrics 的概念整理 7. Zettelkasten — Wikipedia — 以連結而非資料夾組織知識的另一種主張，可與 PARA 對照