什麼是使用者故事（User Story）和驗收標準（Acceptance Criteria）
一個非常完美的基於現實場景的使用者故事驗收標準指南：
在軟體開發行業中，“需求”一詞決定了我們的目標是什麼，客戶真正的需求是什麼，以及是什麼可以使公司業務快速增長。
無論是作為開發軟體產品的產品型公司還是以提供各種領域服務為主的服務型公司，最基本的、最主要的是需求，對於成功的定義就是如何更好滿足需求。
在不同的專案方法論中，“需求”一詞都有不同的名字。
在瀑布模式，它指的是“需求和spec文件”，在敏捷、SCRUM中它被定義為“Epic”,"使用者故事"。
在瀑布模式下，需求文件是很多的，在一個產品階段都有200頁甚至更多。但是敏捷是不同的，因為需求都是小的功能或者模組（feature）的，產品都是循序漸進一步一步的方式去準備的（sprint）。
在這邊文章中，我將以一種相對簡單且容易理解的方式分享有關使用者故事和他們驗收標準的一些經驗。
那麼什麼是使用者故事呢？
一個使用者故事就是一個功能或者feature的需求（requirement），被寫出了也就一兩行字，最多5行。一個使用者故事通常是最簡單的可能性需求，有且只能是一個功能或feature。
最常見使用的標準格式的使用者故事如下：
作為一個使用者/客戶角色，我想要達到的目標是什麼，以及達到目標的原因
e.g:
作為社交工具微信的使用者，我想要在聊天對話方塊中有一個拍照圖示去自拍和發照片，那麼我就可以和朋友一起相互發照片。
什麼是驗收標準？
驗收標準就是一系列可以接受的條件或者業務規則，且與功能或feature相互匹配和滿足，同時也能被產品負責人和相關人接受。
這是使用者故事完成很重要的一部分，它需要被產品負責人和業務分析人員認真的學習，因為錯失一個很小的標準都會損失慘重。這是簡單的編號或者編號列表。
格式如下：
在我做某些動作（action）之前請賜給一些先決條件，然後期望結果發生。
舉個栗子：
1. 假設我正在和朋友聊天，我應該能夠拍照
2. 當我點選照片時，我應該可以在照片上新增一些文字，然後發給朋友
3. 如果我的手機照相機有問題，一條錯誤資訊，如“攝像頭無法開啟”...，相應的也應該出現
因此，使用者故事為任何功能或feature定義了需求，另一方面，驗收標準為使用者故事或需求定義了“完成標準的定義”。
作為QA，理解使用者故事非常重要，同時深刻理解驗收標準，並且在測試開始前沒有一點的疑惑。
深度挖掘的使用者故事：
開始之前，讓我們理解對一個基本的事情“深度”學習的重要性，比如使用者故事
案例#1：
三年前，我當時在為一個手機app專案工作，這個app是一個快遞系統的應用。
你當然會想到有人來寄快遞，然後會要求在他們手機app上簽名。這些簽名會反映在快遞服務商的網站上，比如順豐。
問題：在某個衝刺（sprint）裡，產品負責人對這個app有個使用者故事是：“作為網站管理員，我應該能夠在網站上看到使用者寄快遞的簽名”。而這個網站相應做出變化和更新的以反映這些簽名。
作為一名QA，你不得不去驗證手機app的簽名是否如期望的反映到網站上。
如果你看到這個使用者故事，覺得很簡單但是，這裡有個隱藏的需求“對應歷史的快遞簽名，沒有簽名反映功能，因此如果網站管理人員看到歷史快遞記錄會發生什麼呢？” 歷史資料被清除嗎？還是遇到這些資料報錯？
當然不是，這些都應該被和諧的處理。
解決方案：當相應的資料表格被更新而為簽名的位置增加一列，那些舊的資料應該變成NULL或者0值，而這些值需要被檢查，一條資訊“沒有簽名存在”被顯示出來。
這個就被叫做來自產品負責人或者商業分析師的失誤，但是必須做。成功完成一個功能但打破了一些東西就會令客戶不滿意。這些都是需要在一個相同的使用者故事和衝刺中完成。
案例#2
6年前，我當時工作是關於“退休計劃的金融軟體”，這是個國際化的軟體，金融顧問可以用它為不同的貨幣去做投資計劃、儲蓄等，服務很多的顧客。
問題：產品負責人給你的使用者故事是：“作為金融顧問，我想要看到根據我的客戶提供的金融資產詳情的報告”。
這裡有2個隱藏的需求，我稱之為一個未完整的故事，因為：
a.這個報告應該考慮每天的匯率而不是歷史的已經被檢視過的報告
b.如果在提供詳細的使用者資產資訊後，匯率變化，報告應該顯示變化的匯率
解決方案：我直接跟產品負責人提出了這個擔憂，使他意識到這2個必須儘快做的需求。他同意我的意見並且為即將到來的衝刺建立了2個不同的高優先順序使用者故事。
獲取需求：這些需求被發現是因為我們很好的關注了產品、設計、結構等等。這些知識能夠完成只有在徹底理解產品，理解模組間的互動，以及對即使只有2行文字說明的使用者故事的深刻學習。
請注意，想使事情變得簡單化就和商業分析師以及開發多討論他們的想法。
深度看待驗收標準
理解驗收標準以及其他所有的條件&規則是特別重要的，比理解一個使用者故事更重要。因為，如果一個需求是不完整的或是模糊的，需求可以在下個衝刺被開發，但是驗收標準就會有缺失，進而導致使用者故事不能上線。
假設我們都在用網上銀行，甚至每一天都在使用它並且檢視下載交易記錄。如果你仔細觀察的話，當你下載這些記錄的時候有很多選項供你選擇。比如有這麼個選項信用卡/借款/所有。
現在假如產品負責人給你這麼個使用者故事“作為一個使用者，我想下載我的賬單以至於我可以看到我某個特定時間段的所有的交易”。
下面的是驗收標準：
* 假設我在歷史賬單頁面，我應該可以選擇我需要下載賬單的時間段
* 假設我在歷史賬單頁面，我應該選擇一個我需要下載賬單的賬戶
* 假設我在歷史賬單頁面，我不應該被允許選擇一個將來的時間節點來下載賬單
* 假設我在歷史賬單頁面，我不應該被允許選擇一個超過過去10年的時間節點來下載賬單
* 假設我在下載賬單，我應該能夠看到下載的檔案
* 假設我在歷史賬單頁面，我應該可以選擇下載不同格式的檔案（Excel、pdf等）
如果你瀏覽這些標準，你發現3個事情丟失：
* 命名和下載檔名字的格式
* 有什麼資訊在檔案裡，每行都顯示什麼
* 交易的選項是哪個，信用卡、借款還是全部
像這些案例可能會在一段時間內發生，但是仍然需要很好的學習每個驗收標準並且參考使用者故事使其更加形象化。關於條件和業務你學的越深入，你的知識也會越多。
bug在初始階段所帶來的成本是難以和“測試”階段相比較的。
發現使用者故事和驗收標準差異的重要性
在開發和測試開始之前的早期階段，做一個深入的使用者故事和驗收標準的研究總是非常重要的。
因為涉及到：
#1) 時間的浪費：
如果是在開發或者測試進行中的時候，在使用者故事/驗收標準中發現一個差異或者錯誤，那麼在剩餘的衝刺時間內可能大量工作需要返工。
即使產品負責人有一些事情被遺失，返工也不會發生，他們會把使用者故事移到下個衝刺。但是95%的概率是他們要求團隊完成必要的東西以及在同個衝刺釋出。
因此，就變成了整個團隊的噩夢因為不得不花費額外的時間，週末加班或工作到深夜。在最早可能的階段通過學習和討論使用者故事、驗收標準就可以避免這種情況。
#1)工作努力（efforts）被浪費：
開發和測試不得不再一次重新審查完成的程式碼和測試用例。更新、增加以及刪減，每個需求都不是一件容易的任務。這種情況就變得特別痛苦，再加上已存在的交付的壓力。
在這種情況下，在開發和測試階段就有可能出現一些錯誤。如果你遇到這種情況繼續用“DevQA”配對，那麼額外的工作也無法彌補。
結論：
深刻理解使用者故事和驗收標準只能通過花費巨大的時間去學習。
在市場上也沒有特定的工具或課程去幫助你，因為一切都是關於產品的邏輯思維、經驗、知識。
積極參與預先計劃會議，和商業分析師探討、自己學習都能夠幫你完成。你花的努力越多，你學到和成長的越多。
作為QA還是開發，關於使用者故事和驗收標準每個人都必須在達成共識，然後來滿足客戶的期望來獲得成功。