BDD（20）使用者介面細節放哪裡

March 24 08:20~10:32

 

昨晚C. C. Agile活動Teddy分享「SBE、BDD、ATDD、TDD、DDD大亂鬥」，Teddy提到Scenario應該避免描述太多使用者介面的細節，會後有好幾位朋友都問到BDD和使用者介面描述的問題。今天先把時間倒轉，回憶N年前Teddy還在用Use Case描述需求的時候，遇到關於使用者介面的問題。

 

怎樣算使用者介面細節？

首先看一個ATM提款的例子：

Use Case: 提款

1. 系統顯示歡迎畫面
2. 使用者放入提款卡
3. 系統驗證提款卡
4. 系統顯示輸入密碼畫面
5. 使用者輸入密碼
6. 系統驗證密碼
7. 系統顯示交易選單
8. 使用者選擇提款
9. 系統顯示提款金額畫面
10. 使用者輸入提款金額
11. 系統驗證使用者存款餘額，確認使用者存款大於提款金額
12. 系統詢問提款後是否繼續交易
13. 使用者選擇否
14. 系統退出提款卡
15. 使用者拿取提款卡
16. 系統扣除使用者帳戶內的提款金額
17. 系統吐出鈔票
18. 使用者拿取鈔票

Use Case描述系統與使用者的互動關係，上面這個Use Case有18個步驟，請問它有包含使用者介面細節的描述嗎？

提款Use Case的確描述了使用者介面，例如「歡迎畫面」、「輸入密碼畫面」、「交易選單」、「提款金額畫面」，這些使用者介面有些扮演「操作流程串接」的角色，有些則是負責接收使用者提供的資料當作系統的輸入，但Use Case中並沒有提到特定的使用者介面元件，例如按鈕、文字框、顏色、元件位置、元件的ID等資料，初步看起來並沒有描述「使用者介面細節」。

但是，有些人卻認為光是「使用者放入提款卡」這個敘述就是一種使用者介面細節。What The Fxxx…李組長眉頭一皺，為什麼放入提款卡算是介面細節哩？

因為這個描述背後的目的其實是「使用者出示可代表其身分的辨識物」，這個物品可以是提款卡、指紋、眼睛虹膜、臉部辨識、聲紋辨識、QR Code、甚至是一串代碼，而提款卡只是其中一種選項，所以算是實作細節。當然也有人認為這樣子太吹毛求疵了，我家的提款機打死就只支援提款卡，其他的方法一概都不支援。Use Case裡面直接寫出示提款卡不是清楚明白多了，搞什麼抽象化描述哩。

***

需求 VS 設計

雖然提款這個Use Case清楚交代使用者與系統的互動流程，但並沒有包含詳細的畫面。不是都說用戶體驗很重要嗎，如果不提供UI畫面讓Product Owner或stakeholder確認，到時候系統出來才來打槍那不是浪費大家的時間。N年前Teddy的作法是寫好Use Case（需求）之後用VB拉出假畫面（設計），跟客戶討論需求的時候一邊讀Use Case內容一邊對照著假畫面，這樣子客戶比較有「即視感」。Teddy第一次用這種方式做案子的客戶是「洗衣業」，客戶以前從來沒有遇過這種討論需求的方式，但他們卻非常接受這種方式，透過Use Case與假畫面來驗證他們內心對於產品的期望。

使用者介面是一種設計，依據「規格」或「需求」所產生的設計。規格來自於目標，目標定義專案範圍，必須先釐清目標、協作探索規格與範例，再依據規格產生介面設計。如果用相反的方式來產生需求，也就是透過使用者介面來「規範需求」，很可能導致疏於探索使用者需要系統的真正目的（沒有做到do the right thing），而且商業邏輯和介面邏輯混在一起，無助於建立豐富的領域模型（domain model）。

需求與設計的界線經常並不是那麼黑白分明，回顧一下《Specification By Example》書中的這張圖，步驟1~4屬於需求探索的階段，步驟5~6屬於實作。雖然思考實作的時候很可能會回頭調整需求，這是一個迭代的過程，但大體來說還是必須從使用者的目的開始思考，由上往下展開。直接從使用者介面（而不是從使用者目的）思考，因為這已經是在討論一種設計方式，很容易卡在介面細節上，例如，icon美不美觀、字要大一點、小一點、畫面layout與配色怎麼安排，而忘了原本想達到的目的是什麼。最後就算是產品的品質很高，畫面精美，但因為需求搞錯方向，變成do the wrong thing right也是白搭。

***

啊不然介面細節要放哪裡？

下圖節錄自《BDD in Action》，軟體開發的規格依據需求與實作可分成：

• 需求規格：在BDD中用Feature檔案與Scenario來表達，這也對應到specification by example的概念，可以使用Cucumber或SpecFlow這類的工具來表達。
• 實作規格：用單元測試或RSpec、Spock來記錄。

 

但是以上都沒提到使用者介面細節。沒錯，Teddy認為BDD與OOAD對於規範與紀錄使用者介面細節的助益不大，它主要關注系統行為與實作（domain model）的規格，而非使用者介面。使用者介面怎麼設計，應該用它自己的規格或設計方式與文件，這種文件的目的並不是期望開發人員撰寫類似Cucumber的step definition將其自動化，而是提供給人機介面設計師實作參考。至於驗證使用者介面的目的，則應思考：

• 系統中大部分的自動化測試案例應該是單元測試，約佔70%。
• 自動化GUI測試應該是最少的，介於1%~5%之間。
• GUI儘量不要包含複雜的邏輯，可以簡單到不太可能出錯就不需要太多自動化測試。
• 當人工測試的投資報酬率大於自動化GUI測試的時候，採用人工測試即可。

***

友藏內心獨白：是行為驅動（behavior driven）不是介面驅動（GUI driven）。