當客戶提了一個需求，老闆指派了一個任務，我們要怎麼定義這個需求已經完成、任務已經做完了呢？
舉個例子來說，客戶提了一個需求叫做：網站要有中英雙語言，我們該如何確認雙方對於這個需求有一致的理解呢？
整理一份驗收清單就是一個很好的方法，讓用戶確認這份清單，並在產品交付之後照著做，通過了就將這個項目打勾。
但是要如何寫好一份驗收清單，其實有一些重點需要注意。
先來看看反例，以「中英雙語言」的需求出發，如果我們清單內的項目長的如下所示，會有什麼問題？
使用者可以選擇網站的語言，有中文及英文可供選擇
→ 沒有提供更多資訊，僅僅是將「中英雙語言」這個需求換句話說
切換語言後，使用者體驗能保持一致
→ 模糊且無法測試，並沒有定義「使用者體驗」為何
兩種語言透過 I18n 切換，原始資料以 JSON 格式儲存，方便後續修改
→ 此為實作細節，和驗收無關
一些過於模糊、沒有提供更多資訊、沒有詳細定義的語句，就不適合當成一個驗收項目，因為我們看著這些文字，也不知道該如何下手驗收。
一個好的驗收項目，應該列出「我們怎麼做」，就會「得到怎麼樣的結果」，簡單來說就是給定一樣的 Input，就會有一樣的 Output。
而這樣的項目及清單，一般稱作 Acceptance Criteria，簡稱 AC，中譯為驗收標準。
雖然 AC 在不同公司、不同團隊有著不一樣的寫法，但是其中心思想其實就是訂下一個標準，讓提需求的人和完成需求的人能夠有共識。因此，描述 AC 的語言就需要可以表達得足夠準確、能夠量化。
回到例子中，針對「中英雙語言」，我們可以這樣撰寫 AC：
AC1: 根據瀏覽器的設定，使用者第一次使用時會自動設置語言，除了瀏覽器語言為英文外，其餘語系的預設皆為中文
AC2: 使用者在語言設定後，切換頁面時會維持當前語言設定
AC3: 使用者在網站 Header 上可以點擊語言按鈕切換中英文；切換語言後，使用者會停留在相同頁面
每個項目的主要結構基本上都是給定 Input，得到 Output。例如 AC1 的 Input 是瀏覽器的設定，Output 是網站呈現的語言；AC2 是給定使用者的語言設定，在切換後得到維持當前語言的行為。
透過這樣的結構，便可以拿來當基本驗收項目來和客戶或老闆討論。
前期的 Acceptance Criteria
那麼需不需要寫的更細一些呢？像是 AC1 的瀏覽器是否要指定、AC3 的按鈕是圓的方的等等，更詳細的條列出來不是驗收起來能更精確嗎？
的確如此，但在實務上還是得看客戶。有的客戶可能會很在乎按鈕的形狀及顏色甚至點擊後的樣子，但有的客戶卻連用什麼瀏覽器、裝置來瀏覽網站都不在意。
因此，在前期的討論階段，抓到一個平衡點讓客戶能夠看得懂我們要表達的內容，可能就足矣。
但在實際驗收時，準確的操作步驟還是必須的。每個 AC 都應該要列出有哪些前置作業、要實行的動作，以及期望的內容有哪些。
我們可以參考一個叫做 3A 模式的測試 Model 來列出一個 AC 的操作層級內容，而所謂的 3A 是 Arrange, Act, Assert 三個英文單字的首字母集合。
Arrange - 準備，有哪些事前準備，例如用什麼作業系統、資料要準備什麼
Act - 執行，做什麼動作，例如點擊切換成英文的按鈕
Assert - 斷言，期望得到什麼結果，例如畫面顯示的內容為英文
根據此結構延伸前面 AC1「根據瀏覽器的設定，使用者第一次使用時會自動設置語言，除了瀏覽器語言為英文外，其餘語系的預設皆為中文」的內容來寫詳細步驟，可以這樣條列：
Arrange
硬體及瀏覽器：使用 x86 CPU >= 2 Cores，RAM >= 4GB；使用 > Windows 10 版本、 Chrome > 129.0 版本
瀏覽器預設語言、Cache、目標網站：瀏覽器預設「繁體中文」，無目標網站 https://my.website.com/ 之瀏覽記錄及 Cache
使用者資料：使用帳號 tester 為登入 User
Act
Assert
頁面 HTML 之 <html lang= 為 zh-TW
CSS Selector body > div.header > div.content 的內容為 我的網站
大方向還是一樣，把 Arrange 和 Act 這邊的 Input 準備完成，並且期望 Assert 這邊的 Output 會有什麼，只是寫的更將精準，把實際操作的步驟條列出來。
除了上面寫的這個 Case，針對 AC1 還可以寫更多的 Cases，例如將前置條件改變，把瀏覽器的預設語言改成「英文」。
有了這些驗收的詳細步驟，當我們一個功能開發完畢後，就能夠精確的說「已經做完了」。
iThome鐵人賽
看影片追技術