把 Case 連到業務規則，讓影響範圍自己浮現

把 Case 連到業務規則，讓影響範圍自己浮現 PM 在 Slack 丟了一句話：「結帳流程的折扣計算邏輯改了一下，這週要上線。」 你打開 case 清單，開始憑記憶圈範圍。折扣相關的 case，有，大概在這幾條。運費有沒有折扣？記得有，找一下。會員等級折扣呢？等一下，這個折扣是在結帳算的還是在購物車就算了？稅金的計算順序會不會受影響？ 圈了二十分鐘，有了一份清單。心裡還是不踏實：萬一漏了一個？上線後最怕的就是「啊那個地方原來也會受影響，當時沒想到」。這跟能力無關，這件事本來就不該靠記憶算。 算不出回歸範圍，根源在 case 各自為政 每條 case 都在驗某件事，但「在驗哪件事」這個資訊沒有被記錄下來。 case 清單通常長這樣：按功能分資料夾，或按模組加 tag，每一條描述的是「怎麼驗」。但很少有地方記著：「這條 case 對應的是哪一條業務規則」「這條業務規則牽動了哪些功能流程」。 這層關係只活在資深成員的腦袋裡。改動一發生，沒有任何結構幫你把受影響的 case 找出來，只能靠人腦回想。人腦回想有兩個問題：它慢，而且它會漏。越是「看起來不相關但其實依賴同一條規則」的邊緣情況，越容易在回想裡消失。 其實需求分析時，很多團隊已經把業務規則拆出來了。只是拆完就停在需求文件裡，沒有帶進 case 的設計，也沒有帶進 case 的存放方式，兩邊一直沒連起來。 解法：把 case 跟業務規則連起來 想像有三種節點： 業務規則 ：那些不常改、但改了就牽動很廣的邏輯核心。折扣怎麼算、免運門檻是多少、VIP 享什麼額外權益、退款能退幾天內的訂單。 功能 / 流程 ：使用者實際操作的路徑。結帳流程、購物車頁、會員中心、訂單查詢。一條業務規則通常在多個功能裡都有體現：「折扣計算」不只在結帳出現，購物車也會預覽、訂單詳頁也會顯示。 case ：具體怎麼驗。這一層大家都熟悉，通常也是數量最多的。 連結的方向很直覺： case 指向它在驗的業務規則；業務規則關聯到它影響的功能流程 。 於是當「折扣計算邏輯」這條規則改了，你順著連結就能找到：這條規則影響了購物車、結帳、訂單詳頁三個功能流程，這三個流程對應了以下這些 case。影響範圍不用再靠回想，順著連結就查得到。 我自己的知識庫累積到一定程度之後，有過這種經驗：讓 AI 讀知識庫產測試情境，它會主動提到「這裡以前出過類似的問題」，也會把不同模組串起來，講出我自己沒想到的影響範圍。它做得到，是因為規則、bug、模組之間本來就連在一起。 不需要一開始就完整 連結網不用第一天就全部建好，從最痛的地方開始連。 連結網稀疏的時候幾乎沒用，某條規則周圍的連結夠多之後，才開始派上用場。所以從哪裡開始連很重要。 不用把所有 case 都補上「對應規則」欄位。先問：「哪些業務規則改得最頻繁？哪些規則一改，影響範圍最廣、最容易踩到沒預期到的地方？」從那裡開始。電商系統先從折扣、庫存、付款狀態轉換連起來；金融系統從計息邏輯、手續費計算先連。高風險、高改動頻率的核心規則先連上去，這幾個節點連得夠密，每次改動你就會感覺到差別：以前是「我猜大概這幾條要測」，現在是「連結列出這幾條，我再依自己的判斷補幾條」。 需求分析時拆業務規則、用 user story mapping 攤開功能流程，其實都已經在找這些節點，只是結果沒有被帶進後面的 case 設計。 怎麼落地 工具不重要，能交叉查詢就行。 最輕量的起點：幫每條核心 case 加一個「對應規則」欄位或標籤。TestRail 可以用 custom field，Notion 可以用 relation，Excel 加一欄，Jira 用 label 加前綴，形式不限。 重點只有一個： 每條核心 case 都答得出它在驗哪條業務規則。 不一定需要建一張專門的「業務規則表」；一開始可以只是在 case 的備註欄寫一句「驗：折扣計算規則 v3」，或在規則的筆記裡列一個「對應 case 清單」。先做單向連結。有了第一條，查詢和維護就能開始，雙向、完整是之後慢慢補的。 連結網帶來的附帶好處 建連結的過程，會讓兩種問題自然浮出來： 覆蓋漏洞。 一條業務規則，沒有任何 case 指向它，代表這條規則可能從來沒被測過，或是之前的 case 已經被刪了、改了，但連結沒人清。這個缺口，不建連結的情況下，可能永遠不會被發現。 過期或目的不明的 case。 一條 case，指不出它在驗哪條業務規則，它可能是過期的（規則已經不存在了，case 忘了跟著刪）；也可能是當初設計時就沒想清楚為什麼要測（只是「感覺要測」）。有了連結，一條 case 該不該留就有判斷標準了。 case 清單的信任度，從「不知道裡面有多少過期的，不敢刪」，慢慢變成「每條我都知道它為什麼在這裡、對應哪條規則」。 可以先挑一條最近改過、或即將要改的業務規則，把你覺得對應的 case 列出來，看看有沒有斷掉的連結、沒覆蓋到的地方，以及列了半天卻指不出任何規則的 case。 下一篇：影響範圍找得到了，但有一類問題更難防：同一類 bug 每季在不同地方重演，每次都讓你覺得「怎麼又是這個」。怎麼把踩過的 bug 整理成下次測試用得上的經驗法則？