在 GenAI 的時代，程式編寫的速度和效率已經大大提高，但需求的理解和確認程式能夠正確運作的測試，依然是關鍵的挑戰。
這就是為什麼「Specification by Example」（透過範例來描述需求）變得格外重要的原因。
透過明確且具體的範例來定義需求，不僅能幫助開發團隊理解需求，還能幫助測試團隊確保程式正確運行，避免 GenAI 所生成的程式碼與實際需求不符的問題。
📌 案例故事：GenAI 旅遊推薦系統
讓我們用一個實際的案例來講解這個問題。
背景
某旅遊公司開發了一款新型的行程推薦系統，目的是利用 GenAI 生成的程式碼，讓系統自動為使用者推薦最佳的旅行行程。PM 艾倫向開發團隊描述需求：
「當使用者輸入他們想要去的國家和旅遊天數時，系統應該推薦合適的行程。」
由於需求描述很簡單，團隊相信這樣交給 GenAI 就能夠快速生成程式碼。
GenAI 生成了代碼並快速交付給開發團隊，開發人員也覺得程式碼是正確的，於是直接將系統上線。
但發生了什麼問題？
系統上線後，使用者的反饋卻出現了問題。數據顯示：
60% 的使用者反映推薦的行程與他們的需求並不匹配。例如，某位使用者輸入「日本」和「3天」，系統推薦的行程卻從北海道一路到沖繩，根本不符合實際情況。
40% 的使用者在輸入「法國」和「5天」時，系統只是推薦了巴黎市區的行程，完全忽略了其他城市和景點的多樣性。
經過分析，團隊發現問題出在需求描述上太過模糊，並未具體定義「合適的行程」是什麼，這使得 GenAI 無法準確地理解需求，結果生成的程式碼並未符合使用者的期望。
轉變：Specification by Example 的引入
在這個情境中，PM 艾倫決定採用 Specification by Example 的方法來明確定義需求。艾倫和開發團隊根據不同的場景給出了具體的範例，這些範例不僅描述了需求，還能作為測試的基礎，確保開發的程式能夠正確運行。
🔍 PM 艾倫的需求定義過程： PM 艾倫決定使用 Given-When-Then 格式來描述需求，這樣不僅能清楚地表達需求，還能提供可驗證的測試用例。
具體範例：
- 日本 3 天行程
Given：使用者輸入「日本」和「3天」作為旅遊需求。
When：系統處理該需求並生成推薦行程。
Then：系統應該推薦單一城市（例如東京或大阪），並避免跨城市行程，推薦的行程不應超過 2 小時的交通時間。
- 法國 5 天行程
Given：使用者輸入「法國」和「5天」作為旅遊需求。
When：系統處理該需求並生成推薦行程。
Then：系統應推薦巴黎和至少一個近郊城市的行程（例如凡爾賽、里昂），避免只推薦單一城市的行程。
- 美國 7 天行程
Given：使用者輸入「美國」和「7天」作為旅遊需求。
When：系統處理該需求並生成推薦行程。
Then：系統應該推薦東西岸兩大城市（例如紐約、洛杉磯），並且每段交通時間應該不超過 5 小時。
- 澳洲 7 天行程
Given：使用者輸入「澳洲」和「7天」作為旅遊需求。
When：系統處理該需求並生成推薦行程。
Then：系統應推薦跨城市行程，且每段交通時間應該不超過 3 小時，並避免過度集中的行程。
👨💻 開發人員的工作：根據 Given-When-Then 格式進行開發
開發人員根據 PM 艾倫提供的具體範例，開始編寫程式碼。
這樣的需求定義幫助開發人員明確理解每個情境應該如何處理，並根據此邏輯來開發系統。
具體範例對開發的幫助：
日本 3 天的行程：
開發人員能夠知道：當「日本」和「3天」作為需求時，程式必須過濾掉跨城市的推薦，並且僅推薦東京或大阪等單一城市行程。
法國 5 天的行程：
開發人員會設計邏輯來處理巴黎和其他城市（如凡爾賽或里昂）的行程組合，並且確保每段交通時間在合理範圍內。
美國 7 天的行程：
開發人員將根據需求來限制交通時間，確保東西岸城市的行程合理安排，且不會產生過多的交通問題。
🧪 測試人員的測試過程：基於 Given-When-Then 格式進行測試
測試人員使用 Given-When-Then 格式來設計具體的測試用例，並確保每個情境下的行為都能夠達到預期的結果。
具體測試範例：
日本 3 天行程測試：
Given：使用者輸入「日本」和「3天」。
When：系統生成行程推薦。
Then：驗證系統推薦的是東京或大阪，且無跨城市行程，且每段交通時間不超過 2 小時。
法國 5 天行程測試：
Given：使用者輸入「法國」和「5天」。
When：系統生成行程推薦。
Then：系統應推薦巴黎和至少一個近郊城市的行程，並且交通安排合理。
澳洲 7 天行程測試：
Given：使用者輸入「澳洲」和「7天」。
When：系統生成行程推薦。
Then：系統應推薦跨城市行程，並確保每段交通時間不超過 3 小時，且避免過度集中的行程。
📊 不同角色的協同過程：Given-When-Then 格式的價值
PM（需求定義）：通過具體的範例，PM 艾倫能夠清楚地定義需求，並確保所有團隊成員對需求有一致的理解。
開發人員（實現程式）：根據具體的 Given-When-Then 範例，開發人員能夠清晰地知道每個情境應該如何實現，確保程式碼能夠精確符合需求。
測試人員（驗證需求）：測試人員能夠直接將 Given-When-Then 的範例轉化為測試用例，進行有效的功能驗證，確保產品質量。
🚨 如果缺乏 Given-When-Then 的技能，會帶來哪些風險？
- 需求不明確，開發困難：
如果需求沒有具體的範例來支撐，開發人員可能會對需求理解不一致，導致程式碼無法滿足使用者需求。
- 測試無法有效進行：
測試人員無法準確地設計測試場景，可能漏測一些關鍵場景，導致產品質量無法保障。
- 開發進度延誤，成本上升：
需求模糊會導致不必要的需求調整和溝通，增加專案成本，並可能延遲交付時間。
📗 結論
在 GenAI 的時代，使用 Given-When-Then 格式來描述需求，能夠清晰地定義需求並有效支援開發和測試。
這不僅幫助開發人員精確地實現需求，也讓測試能夠進行有效的驗證，確保系統符合預期的行為。
缺乏這項技能將可能導致需求理解不一致、錯誤增多，進而影響專案的成功。
發表迴響