本週閱讀了以下三篇關於驗收準則的文章：
- ACCEPTANCE CRITERIA：https://www.leadingagile.com/2014/09/acceptance-criteria/
- What Characteristics Make Good Agile Acceptance Criteria?：http://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/
- On Acceptance criteria for user stories：https://nomad8.com/acceptance_criteria/
以下做了些重點整理，以便往後參考
什麼是驗收準則
驗收測試回答了兩個問題：
我們建造了正確的產品了嗎？，而我們又是否使產品正確無誤地被建造了？
(Did we build the right product? And, Did we build the product right?)
- 驗收準則定義了使用者故事的失敗與通過
- 驗收準則是一組滿足條件，載明了軟體產品必須滿足使用者, 客戶以及利害關係人所能接受的完成條件。
- 驗收準則定義了使用者故事, 功能的範圍與相關參數，並決定何時故事才算是完成並且如預期的運作。
原則
- 避免在開發之後才去撰寫驗收準則
- 驗收準則應該去捕捉客戶的意圖而不是開發的實踐
- 驗收準則應該告知的是意圖而不是解決方案：舉例，"使用者可選擇貨到付款來進行結帳”會優於”使用者點擊下拉式選單展開付款方式清單，並從中挑選貨到付款”
- 討論什麼是預期的成果而不是如何去實作某個功能
細節
像是”要有哪些欄位“，”數字的呈現應該包含幾位數“等等這樣的細節，通常是在對話中完成的，通常是在規劃會議(planning meeting）或者開始撰寫程式時才會被討論
在開始撰寫程式前，這樣的細節應該記錄在兩個地方
- 團隊內部文件：這個文件通常是作為提醒用，避免忘記對話時所討論出來的相關細節
- 自動化測試：驗收測試所能提供的價值就如同需求文件一般
格式
包含三個元素：先決條件、動作、結果
例如：在手機裝置上進入優惠卷頁面，能自動調整頁面排版，並放大字體，先決條件為"在手機裝置上”，動作為“進入優惠卷頁面”，結果為”能自動調整頁面排版，並放大字體“
範例
User Story：身為使用者，我希望能夠查看我的優惠卷有效期限，以便能夠在期限使用折價卷
Acceptance Criteria：
- 進入優惠卷頁面時，使用者能瀏覽折價卷清單，並且看到每個折價券的使用期限
- 在手機裝置上進入優惠卷頁面，能自動調整頁面排版，並放大字體
- 進入優惠卷頁面時，載入頁面須在0.5秒內完成
以上三個Acceptance Criteria分別是可歸類成功能性標準(Functional Criteria)、非功能性標準(Non-functional Criteria)、效能標準(Performance Criteria)，功能性標準載明了要完成的任務、商業流程；非功能性標準載明了UI設計、使用者經驗等等；效能標準載明系統的效能要求。
沒有留言:
張貼留言