接著上篇 "估算故事"講，故事估算完成以後就要開始考慮如何進行驗收測試了，只有驗收通過故事才算開發完成.
對於乙個故事，開發人員和客戶可能會討論很多，討論的內容可以以測試用例的形式記錄下來，這樣就為我們故事測試做了鋪墊，目前敏捷開發中測試大約有如下2個步驟
1、將測試要點記錄到敏捷的故事卡的背面，任何時候發現新的測試，都可以記錄到故事卡背面
2、將測試要點變成全面測試，這些測試用來演示故事已正確、完整的實現
下面說一下什麼時候寫測試用例，以及測試的方法。
在編寫**之前寫測試
驗收測試可以為程式設計師提供大量的有用的資訊，經常的看驗收測試說明可以保證程式設計師不去寫那些不符合測試說明的**,應該在如下時候寫測試
1、開發人員和客戶討論故事且需要記錄明確的細節時
2、在迭代開始時候、在寫**前作為一項專門的任務
3、在開發中或者任何時候發現新的測試時
可以使用如下提問的方法來收集測試用例
1、關於這個故事、程式設計師還想知道什麼？
2、對怎麼實現這個故事，我的想法是什麼？
3、有沒有特殊情況會使這個故事有不一樣的行為？
4、這個故事什麼情況下回出錯？
客戶定義測試
客戶可以和程式設計師與測試人員合作建立測試、但是客戶至少應該給我們詳細的指出一些測試，用以驗證故事的實現是正確的
1、測試是過程的一部分
測試是開發過程的一部分，而不是編碼完成後要做的事，這點對使用使用者故事非常的重要。
2、多少測試才算多?
只要這些測試還在繼續為故事增加價值和是它更加清晰，客戶就應當繼續寫測試。
3、測試型別
1、使用者互動測試，保證所有的使用者互動元件如期工作
2、可用性測試，確保程式好用
3、效能測試，測試應用程式在各種負荷下的工作狀態
4、壓力測試，使應用程式在使用者和事物的極限值情況或其他任何讓應用程式處在壓力下的運**況執行
驗收測試總結
1、驗收測試可以用來記錄客戶和開發人員討論的工作細節
2、驗收測試即可了有關故事的一些假設，這些假設可能還沒有和開發人員討論過
3、驗收測試提供可檢查故事是否被完整實現的基本標準
4、驗收測試應有客戶來寫而不是開發人員
5、驗收測試應該在程式寫**之前就寫好
6、如果新的驗收測試對闡明故事的細節活意圖沒有任何幫助，就不用再寫
開發人員的職責
若團隊覺得有需要，則負責實現自動化驗收測試
開始開發乙個新的故事時，負責考慮更多的驗收測試
負責為**做單元測試，使驗收測試就不必估計故事的每個細節
客戶職責
敏捷開發（四） 故事驗收測試
接著上篇 估算故事 講，故事估算完成以後就要開始考慮如何進行驗收測試了，只有驗收通過故事才算開發完成.對於乙個故事，開發人員和客戶可能會討論很多，討論的內容可以以測試用例的形式記錄下來，這樣就為我們故事測試做了鋪墊，目前敏捷開發中測試大約有如下2個步驟 1 將測試要點記錄到敏捷的故事卡的背面，任何時...
敏捷開發的使用者故事怎麼寫？
以下是近期對敏捷開發中由以往 調研 文件 討論 文件 開發 文件 向新的開發方式的學習一些總結，和大家分享，有任何好的想法歡迎和我溝通。如何編寫使用者故事？1 使用者故事不要用技術語言來描述，要使用使用者可以理解的業務語言來描述 不要提及任何有關語言邏輯，資料庫，軟體，欄位的客戶無關描述。2 格式 ...
敏捷 即時驗收
即時驗收也叫ba sigeoff 指在迭代過程中，story開發完成以後，開發人員並不馬上開發下乙個story，而是由ba快速驗收，如果驗收時發現了一些明顯的bug，或者驗收條件沒有達到，開發人員可以立即進行修改，如此反覆，知道ba驗收通過為止 具體步驟 1.開發人員從待開發列表中拿到story 2...