從寫自動化到經營知識庫：QA 的時間怎麼變成複利

從寫自動化到經營知識庫：QA 的時間怎麼變成複利 今年三月，我停下手上的自動化開發，轉去支援手動測試、協助正式發版。八月之後，公司不再需要自動化測試，我的崗位也正式換了。 那時候我手上剛好有一個累積了幾個月的測試知識庫。這篇講這半年怎麼走過來，包括差點放棄的那個月和崗位換掉時的焦慮。知識庫的架構在 QA Brain：讓 AI 真的懂你的產品 寫過，這裡不重複。 三月：停下自動化，回到手動測試 三月的時候，專案多、測試人力有限，RD 又開始用 AI 寫程式，功能做出來的速度越來越快，要測的東西只會更多。發版總要有人測，我就停下自動化開發，轉去支援手動測試，協助正式發版。 寫自動化那段時間，我就隱約覺得腳本只能把「已經知道要測什麼」的東西跑得更快。回到手動測試之後，這件事變得很具體。人手不夠的時候，真正卡住的是前面那一步：這個功能要測哪些情境？哪裡以前出過事？這次改動會影響到哪些地方？這些問題沒有答案，每次都只能從頭想。 那些答案散在各個地方：我的筆記、舊的 bug 單、會議紀錄、某個同事的腦袋裡。每次測新功能都要重新翻一遍，翻完下次又忘了。 所以三月到五月，我做了最笨的事：手動整理。把散落的文件、筆記、bug 經驗一份一份收起來。那時候還沒想到要做知識庫，只是覺得這些東西不該每次都重找。 五月：讓 AI 讀這些東西 五月我把整理好的東西放進一個 git repo，開始讓 AI 讀它。 起因是一次失敗。我讓 AI 產測試案例，它給了一份格式漂亮、但有一大半在測我們系統不存在功能的清單（經過寫在 AI 測試案例生成實戰）。我才意識到，AI 缺的不是能力，是我手上這些散落的產品知識。 思路在這裡轉了第一次。以前我把時間投資在腳本上，腳本只會照著跑；如果把時間投資在知識上，AI 可以拿它去思考。同樣是寫東西，寫進知識庫的每一筆，下一次 AI 都用得上。 這些都不是停下手邊工作專心做的。專案測試一直同時在進行，知識庫是一邊測、一邊長出來的。 七月：懷疑這件事值不值得 七月我幾乎沒碰這個 repo，因為我開始懷疑它值不值得。整理知識很花時間，每寫一筆 bug、每補一條模組規則，當下都看不到回報。AI 的產出有變好一點，但沒有好到讓我覺得「就是這個」。 最後沒放棄，老實說有一半是因為沒有別條路：資源還是不夠，不做這個，人力的問題一樣無解。另一半是有東西在推我。新的模型和工具出來，同樣的知識庫，AI 讀完的效果明顯變好。同事也開始給我反饋，甚至自己動手更新裡面的測試知識文件。 有人願意幫你改文件，代表這東西對他有用。那是我第一次覺得，這件事可能不只是我自己在忙。 八月：幾件事同時接上了 八月開始，事情突然變快了。原因有好幾個，剛好在同一段時間接上。 第一，展列測試的流程跑通了。以前拿到新需求，要自己從頭想測試情境。現在是先填一張固定格式的需求單，讓 AI 讀知識庫產出情境草稿，我審過才變成正式的測試案例。草稿會分開標示哪些是確認過的規則、哪些是 AI 推的、哪些還要問 PM。 第二，bug 開始自動寫回知識庫。新的 bug 結案後，會整理成知識寫回來。 第三，同事正式加入。他用知識庫展列測試情境、查產品規則，也把自己負責的知識補進來。 第四，知識累積過了門檻。AI 產情境的時候，會主動提到「這裡以前出過類似的問題」；會把不同模組串起來，講出我自己沒想到的影響範圍。最讓我意外的是有一天，草稿裡開始出現我們團隊內部才會用的詞。那一刻它讀起來不像 AI 寫的，像同事寫的。 四件事互相推著走：流程順了，用的人就多；用的人多，寫回來的知識就多；知識多了，AI 產出更好，大家更願意用。 八月之後：自動化不被需要了 就在知識庫開始轉起來的時候，公司不再需要自動化測試，我的崗位也換了。 第一個反應是焦慮。自動化是我花了很多時間累積的技能，突然不被需要，我很怕這些技能從此沒用了。一開始我有點抗拒，覺得放掉自動化就像在退步。 後來想通，是因為我發現那些經驗一點都沒浪費，只是換了地方用。 管程式碼的方法，我直接拿來管知識：用 git 留版本，用 schema 規定格式，用檢查腳本抓壞掉的連結和不合格的頁面。寫自動化的習慣，變成寫腳本自動化知識流程，bug 入庫、重建索引都不用手動做。以前為了寫自動化去想測試情境的那套思維，現在用在審 AI 展列出來的草稿：哪裡漏了邊界、哪個狀態轉換沒測到。 想通之後，我把崗位轉換當成一個機會：終於可以把力氣全部放在這件事上。 分享給同事，卡在三個地方 同事是我主動分享、一步一步教的。過程中卡最久的有三個地方。 工具門檻。git、terminal、AI agent 這些環境，對沒碰過的人來說每一個都是一道牆。 不信任 AI 的產出。這很合理，我自己一開始也被 AI 騙過。自己寫比較放心，是 QA 的本能。 不知道要補什麼。知識庫是開的，但「什麼東西值得寫回來、要寫成什麼樣子」，沒有人教就不知道從哪裡下手。 走錯的方向 第一個錯，是把什麼都塞進去。一開始我覺得知識越多越好，看到相關的就收。結果文件越來越雜，AI 反而抓不到重點，讀了一堆，回答更模糊。 第二個是知識過時、互相矛盾。產品一直在改，知識庫裡同一件事可能有兩三種說法，有的是舊的，有的只是某次測試環境的假資料。後來我定了兩條規則：每一條知識都要分「已確認」和「待確認」，不確定的就標出來去問；發現和實際行為對不上，就直接改原文，不另開一份新的，不然很快就會有三份互相打架的說明。 這就是複利 回頭看這半年，「複利」這個詞很準。 前期很平。前三個月幾乎看不到回報，七月甚至讓我想放棄。如果只看那段，很容易下結論說不划算。 本金會累積。每一筆整理進去的知識，之後每一次都會被 AI 讀到、被用到。寫一次，用很多次。 有東西在放大它。一般的知識庫，價值取決於有多少人願意去翻。接上 AI 之後，翻的這件事不用人做了，每次展列情境、查規則、分析 bug，AI 都會自己去讀。再加上同事一起補，本金累積的速度也變快了。 我的時間花到哪裡去了 這半年最大的改變，是我對 QA 時間該花在哪裡的看法。 以前我覺得資源不夠，就要讓執行變快。現在我覺得，最該省的是「想」的起點：要測什麼、哪裡會壞、這次改動影響誰。 我的時間分配也跟著變了。花在想測試案例的時間少了，花在確認資訊的時間多了：AC 有沒有漏、RD 怎麼實作、後台設定會影響什麼。這些問清楚、寫回知識庫，AI 下一次就知道了。 如果你也想開始 如果你也想試，從手動整理開始就好，架構是之後才長出來的。bug 一定要寫回來，那是 AI 從任何公開資料都學不到的東西。能找到一個人一起用，它才會真的活起來。開始之前，先確認公司的 AI 使用政策。具體怎麼蒐集、分層、維護，我整理成了一個系列：QA 的第二大腦。 這半年我寫的腳本變少了，但我開始相信，QA 花的每一個小時，可以不只用一次。