iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 14
0

https://ithelp.ithome.com.tw/upload/images/20190915/20106486JQu7ha4AJq.jpg

前兩篇聊到了『完成的定義』與『使用者故事』,其實只是為了講解『驗收條件』(Acceptance Criteria)打底。一個工作項目是否達到客戶對需求的期待?答案就是足『通過』所有驗收條件才算是真正的產生價值。

完成的定義關注的點是『衝刺』中對所有『工作項目』/『使用者故事』的基本要求,而『驗收條件』則是對『工作項目』/『使用者故事』的需求細節進行逐一驗證。一個工作項目是否能如質如期的完成,最重要的一部分就取決於開工前是否有明確的『驗收條件』。

驗收條件的目的

  • 描述明確的需求範圍:透過驗收條件的討論,讓團隊了解產品負責人與利益關係人對這個需求的期待,也能讓團隊更明確的了解這個需求的範圍,也方便估計時程與測試涵蓋範圍。
  • 描述錯誤的案例處理:透過驗收條件條例出現有需求可以會遇到的限制與錯誤處理方式,開發過程完成期待中的需求比較沒問題,大多數遺漏的部分都是『錯誤/例外處理』。
  • 增加共識的討論模式:透過驗收條件的討論,產品負責人與開發團隊,一次又一次的理解需求的目的,確保對需求有相同的了解,才能在最後的展示階段完整的呈現結果。
  • 提早列舉出測試案例:驗收條件也是讓測試人員、產品負責人對開發團隊說明之後將進行的測試案例的過程,才不會發生開發團隊做的東西都沒被測試到,需要測試的部分都沒被完整開發。
  • 時程工期的有效估計:透過驗收條件討論之後才能更明確的瞭解需求與測試範圍,開發團隊才能對這個需求有更有信心的估計,無論是時間、人力的絕對估計或是點數、大小的相對估計。

驗收條件的寫法

常見驗收條件的寫法有下列幾種

情境式寫法(Scenario-based)

『情境式寫法』的結構包含了五個元素:

  1. 情境(Scenario):描述這個驗收條件的情境
  2. 假定(Given):描述這個驗收條件的預先設定的條件
  3. 當(When):描述這個驗收條件在什麼情況下
  4. 然後(Then):描述這個驗收條件預期會發生的結果
  5. 而且(And):描述這個驗收條件預期會發生的更多結果

舉例來說:

  • 『情境』是使用者帳號登入
  • 『假定』使用者開啟帳號登入頁面
  • 『當』使用者存在的帳號、錯誤的密碼時
  • 『然後』登入頁面會秀出提示訊息『密碼錯誤』
  • 『而且』登入頁面也會呈現『忘記密碼』的連結

規則式寫法(Rule-based)

所謂的『規則式寫法』是用條列式的方式列出所以需要驗證的測試案例
『測試案例』是使用者帳號登入,驗證規則如下:

  1. 使用者輸入正確的帳號、密碼時,可以登入帳號頁面查看帳號資訊。
  2. 使用者輸入存在的帳號、但錯誤密碼時,需要秀出提示訊息『密碼錯誤』
  3. 使用者輸入不存在的帳號時,需要秀出提示訊息『不存在的帳號』
  4. 使用者輸入錯誤的密碼超過三次時,需要秀出提示訊息『密碼已錯誤三次,需要重設密碼(附連結)』

客戶習慣的寫法(Customer-based)

有些客戶可能會用流程圖的方式、心智圖、檢核表的方式寫完成驗收條件,但寫法不是重點,能清楚呈現『驗收條件』的就是好方法。

驗收條件怪味道的七八點

  1. 完成後才寫驗收條件:工作項目完成後才進行驗收條件的討論。
  2. 鉅細靡遺的驗收條件:驗收條件太過仔細,單一功能就有不同組合的測試。
  3. 超出範圍的驗收條件:驗收條件太廣已經超過本次要進行的範圍。
  4. 技術細節的驗收條件:驗收條件的不是使用者看到的情境,而是底層的技術細節。
  5. 沒有共識的驗收條件:團隊對驗收條件還沒有共識就開工。
  6. 無法獨立的驗收條件:這個驗收條件需要其他驗收條件的配合才能進行測試。
  7. 充滿變數的驗收條件:測試的條件是充滿變數的,無法模擬的。
  8. 單向定義的驗收條件:只由測試人員或產品負責人設計出的驗收條件,開發團隊都事前不知情。

【文思不藏私】敏捷 30 天養成計劃~搶先看


上一篇
敏捷小班~Scrum 使用者故事
下一篇
敏捷小班~時間限制
系列文
敏捷 30 天養成計劃30

1 則留言

0
zivtor
iT邦新手 4 級 ‧ 2019-10-04 12:25:15

"驗收條件的目的"重複了?

謝謝,已修正 /images/emoticon/emoticon12.gif

我要留言

立即登入留言