本文同步刊載於個人連載網站

上一篇寫到，我開始把重要工程決策背後的理由留下來。

但再往前追一步，這些決策之前還有一個更基本的問題：

我到底怎麼理解這個需求？

現在看到一句：

「我要這個功能。」

我已經不只會問它要怎麼做。

還會繼續往下問：

這個功能如果真的成立，系統必須一直保證哪些事情？

一個「切換功能」，背後有很多不能被破壞的條件

有一個很適合說明這件事的例子，是 QA 測試帳號。

開發和 Debug 時，我常常需要切換不同業務情境，確認不同情況下會看到哪些資料、可以做哪些操作。

如果每一種情境都另外準備一組帳號，帳號管理本身就會變得很麻煩。

所以我的需求很簡單：

能不能只用同一個 QA 帳號，就切換不同業務情境？

單看功能表面，可能只是一個選單。

但我真正要的不是：

讓 QA 直接變成另一個正式使用者。

也不是：

讓畫面換一組假資料就算完成。

QA 還是原本的 QA。

只是這一次測試，要站在不同業務情境裡看系統。

這個差別一拆開，原本一句「切換情境」，背後就會長出一整組條件。

身分不能因為測試方便就被改掉

第一個不能被破壞的是：

QA 自己是誰。

QA 可以切換測試情境。

但不能因為測試方便，就真的冒充某個正式使用者。

也不能修改帳號原本真正綁定的身分。

否則測試情境和真實身分就混在一起了。

所以「目前站在哪個業務情境」和「這個帳號真正是誰」，必須是兩件不同的事。

權限也不能因為是 QA 就全部放行

第二個不能被破壞的是權限。

如果 QA 切換到某個情境，只代表它現在要用那個情境來測試。

不代表它可以繞過正式系統的限制。

某一筆案件如果不屬於目前業務範圍，不能只是從列表上消失。

就算直接輸入網址，也還是應該被擋住。

畫面上看不到某個功能，也不代表真正的限制已經存在。

真正不能做的事情，還是要由系統原本的權限規則守住。

所以我真正想測的是：

在不同情境下，正式規則是不是仍然成立。

而不是：

測試帳號能不能什麼都做。

不同頁面也必須站在同一個情境裡

第三個不能被破壞的是一致性。

如果 QA 現在切換到某個業務情境：

工作台看到的案件要跟著變。

案件列表也要站在同一個情境。

統計結果不能又用另一套範圍。

同一筆資料在不同頁面裡，也不能各自用不同理解來決定要不要出現。

所以「目前正在測哪個情境」不能只存在某一個畫面裡。

只要系統裡其他地方也需要這個資訊，就必須用同一個理解。

功能需求開始變成一組「必須一直成立的條件」

把這些放在一起之後，我才看清楚：

原本表面上只是一個很簡單的功能：

QA 可以切換業務情境。

真正需要成立的是：

• QA 的真實身分不能被改掉。
• 測試不能繞過正式權限。
• 不同頁面要使用同一個業務情境。
• 同一個情境下，看到的資料與可以做的操作要彼此一致。

到這裡，問題已經不再只是：

「切換選單要怎麼做？」

而是：

「這個功能存在之後，有哪些事情不能因此變錯？」

這些條件會直接影響後面的工程設計

一旦這些不能被破壞的條件變清楚，工程上的問題也會跟著出現。

目前的業務情境要放在哪裡？

哪些地方需要讀到它？

真正的權限限制要在哪一層執行？

不同頁面怎麼確保用的是同一個情境？

這些都不是功能做完後才補的問題。

而是從需求本身一路長出來的。

需求怎麼被理解，會直接影響系統最後需要保證什麼。

而那些要被保證的事情，又會繼續影響：

由哪個部分負責。

資料怎麼流。

不同系統之間怎麼維持一致。

這也會影響我怎麼看「功能做對了」

如果只看表面結果：

QA 可以切換情境。

功能就好像已經完成。

但如果切換之後：

身分被改掉了。

權限被繞過了。

不同頁面看到不同範圍。

那個「切換功能」其實根本沒有真的成立。

所以現在我比較少只用：

「畫面上有沒有這個功能？」

來理解需求。

我會多問一層：

這個功能存在之後，哪些事情必須一直保持正確？

功能是最外面看得到的結果。

那些不能被破壞的條件，才會一路影響後面的系統設計。

而這些條件一旦變清楚，下一個工程問題自然就是：

誰應該負責把它們守住？