組織：讓活的浮上來、死的下沉

組織：讓活的浮上來、死的下沉 那份 case 庫上次認真整理是兩年前的事了。 有人離職之前把自己的 case 全丟進去，說「以後可能用到」。之後每次 sprint 有人加幾條，有人把舊的 copy 過來改，有人在標題後面加「v2」或「（新）」。慢慢地，幾百條 case 堆在同一個地方，按功能模組分好幾個資料夾，看起來很整齊。 但沒有人知道哪些還準。 「這條 case 說要檢查 A 欄位是否必填，但我記得上個版本就拿掉了？」「這個 checklist 是哪個版本的？」沒人能回答。大家開始各做各的副本，因為原始的那份信不過。案例庫仍然存在，只是沒有人真的在用它。打開只是為了複製幾條貼到自己的試算表，然後手動比對哪些還有效。 想清理又不敢動：萬一刪掉的那條剛好有人要用怎麼辦？於是就這樣繼續積著。 我自己的知識庫也差點走到這一步。產品一直在改，同一件事寫著兩三種說法，有的是舊的，有的只是某次測試環境的假資料。後來我定了一條規則：發現跟實際行為對不上，就直接改原文，不另開新的一份，不然很快就會有三份互相打架的說明。 真正的問題：分類軸用錯了 案例庫會爛，是因為現在的分法讓你看不出「這條現在還算不算數」。 多數人按功能模組或測試類型來分：登入模組、購物車、付款流程、回歸測試、冒煙測試。這種分法直覺，搜尋起來也順。但它有個盲點：功能模組是永遠存在的分類，不管那個模組現在是不是你的工作重點，case 都靜靜躺在那裡，看不出新舊，看不出活躍度。 比較好用的軸是 行動性 ：這條知識跟我現在的工作有多近。離工作越近，越該放在手邊；越遠的，自然下沉。不同的距離，需要的操作也不一樣。我第一次用這個軸整理測試知識的過程，寫在這篇。 四層，讓東西按距離自己站好 把知識的位置想成同心圓，從最近到最遠分四層。 本版任務層。 這個 sprint 或這個版本要測的東西。測試計畫、本次新增的 case、這版特別要注意的驗收條件。最近、最常開、每天都會碰到。數量刻意壓小，只放這版真正要動的東西。 常駐領域層。 長期存在、需要持續維護的測試知識。核心模組的 case、常規回歸範圍、業務規則筆記。不是每天都碰，但每個版本都會回來看一次。這裡放的是「這個產品我一直在負責」的知識。 通用參考層。 不綁特定任務或模組的知識。測試啟發清單、邊界值技巧、歷史 bug 摘要、跨專案都能套的共用 checklist。不知道什麼時候會需要，但需要的時候能找到就好。 封存層。 過期了、不再適用了，但還不到刪掉的東西。功能被砍的 case、三個版本前的測試計畫、已關閉的邊界條件。下沉到這裡，不干擾現在的工作，但保留可查的歷史。 要注意的是， 同一條知識會隨時間移動 。本版任務做完，測試計畫移進常駐領域；業務規則大改，舊版的 case 下沉進封存。所以分層不是分一次就結束，要定期把東西挪到它現在該在的位置。 不要在蒐集的當下分類 那每寫一條 case，都要先想它屬於哪一層嗎？這樣蒐集的門檻又變高，S02 好不容易降下來的摩擦又會回來。 別在收資訊的當下做分類決定。 先進收件位置，定期批次處理。 每週或每個版本收尾，專門抽一段時間坐下來整理。對每條問一串問題：這條服務於正在進行的任務嗎？是，放本版任務層。不是的話，它屬於某個長期要顧的領域嗎？是，進常駐領域層。都不是的話，是不特定任務都可能用到的參考知識嗎？是，進通用參考層。三個問題都答否，進封存層。 批次做的好處是不用一直切換腦袋。集中一個時段、用同一套標準掃過去，判斷比較一致。邊蒐集邊分類最慢，兩件事會互相打斷。 封存，不要刪 最反直覺的部分：過期的 case，不刪，下沉。 心理門檻。 「刪掉萬一以後要用」的焦慮是真實的，它讓人根本不敢動手清理。封存之後，東西還在，只是退場了。知道找得回來，就敢把它移走。活的東西才浮得上來。 歷史可追溯。 那條過期的 case 裡可能藏著「當時為什麼這樣測」的邏輯。業務規則的邊界為什麼定在這裡、某個不常見的 flow 為什麼要特別測。理由常常沒寫在 case 裡，要回頭看當時的情境才知道。刪掉，就再也查不到了。 今天可以先做一件事：打開案例庫，找出一眼就看得出過期的東西，例如三個版本前的測試計畫、已經砍掉的功能的 case，移到封存層。別刪，移走就好。 下一篇：每次規劃測試都從零設計，同樣的 checklist 一直重造輪子。怎麼把反覆用到的知識變成可以直接組裝的零件？