當這些被實現出來時，第一個用戶故事可以讓我們從干系人那里得到美學方面的反饋，讓他們考慮其他用戶故事，例如放置相關商品的廣告，這可以為項目愿景的實現添加一些不同點。其余的story可以晚一些再添加進來，我們可以從這些用戶故事中分別得到反饋。
不是一定非要讓BA來編寫這些用戶故事，不過通常他們對此比較在行。
用戶故事促使QA創建場景
當QA測試一個特性時，他們通常會做三件事：
設置應用程序運行的初始狀態、數據等
在測試環境中執行一些步驟
檢查輸出結果
然后他們設置不同的環境，檢查不同的輸出。
當需要自動化這些場景時，我們可以使用行為驅動開發(BDD)和場景語言Given、When、Then來定義這些(場景)。
“領域驅動開發”的作者Eric Evans有一次被問到，場景和用例之間有什么分別�！澳銦o法向業務人員要用例”，我回答，“除非他們懂技術，知道用例是什么。但是你可以管他們要例子， 你可以說‘給我一個場景’”。BDD使用的語言，和DDD中的通用語言，都是為了能夠讓業務人員和開發人員可以進行交流。
“有一個滿足免費送貨標準的購物籃，當我結賬時，屏幕上應該顯示什么?”
“嗯……這個訂單免費配送!”
從對話中，我們發現了新的信息，我們可以用這些信息來寫一個例子：
有一個購物籃，里面的商品總價為150歐元
當我進入結賬界面后
屏幕上應該顯示“此訂單免費配送”
QA可以將它作為一個驗收測試，QA或開發人員可以將它自動化。
不是一定非要QA來寫這些場景，不過根據我的經驗，他們在這方面極為擅長。
所有這一切幫助我們確信，當我們開始實現時，我們的代碼將有最大的機會為客戶帶來價值。
不是一定非要讓QA來編寫這些場景，不過通常他們對此比較在行。
場景促使UI專家設計UI
在我主持的一次回顧中，開發人員識別出，UI專家是阻礙他們完成故事的最大障礙�！皬奈覀兊谝淮我姷竭@個故事，到我們可以開始工作，足足用了三天時間�！币粋�開發人員說道。
“定義頁面的樣子就需要這么長時間”，我們的UI專家回答道。
“嗯，”我沉思了一會，“有沒有辦法縮短這個時間?或許只做到開發人員可以工作就行了?”
“可能吧，你需要什么?”
一個開發人員拿起一張卡片，在上面畫了一個草圖�！熬拖襁@個樣子”，他說，“只要能表達網站上顯示什么就行了。一旦我們得到了內容，就可以開始寫代碼，使格式易于修改�！�
“很好，”UI專家笑道，“因為我們通常沒法一次做對�！�
這樣，當UI專家忙于創建界面時，開發人員可以做一些簡單但是可以工作的東西。界面的觀感甚至可以作為一個單獨的故事。那些內容-頁面上應該顯示哪些東西，用戶應該點哪個按鈕-定義了開發人員可以開始編寫的第一塊代碼。
UI不一定是圖形化的。例如，一個應用程序可以被另一個系統使用，甚至沒有人會直接查看它的輸出。使用它的系統成為了用戶，UI專家需要知道什么樣的數據才是消費系統需要的。
不一定非要讓UI專家來設計UI，不過通常他們對此比較在行。
UI促使開發人員編寫代碼
一個剛畢業的開發人員，Jerry，問我：“我怎么才能知道我的代碼是正確的?”
“你怎么知道它不正確呢?”我問道。
“會有人報告一個bug，”他看著QA回答道，“可能是他們，也可能是用戶�！�
“他們怎么知道那是一個bug呢?”
“他們會使用系統，但是系統沒有按著他們需要的那樣去做�！�
“是的。所以，我們判斷你的代碼是不是正確的唯一方式，就是通過用戶界面。不管背后有什么，都是支持UI行為，并讓我們可以在需要時易于修改這些行為。
”UI是用戶體驗軟件價值的唯一途徑。創建代碼可以使用的界面，是讓代碼有意義的本質�！�
通過首先創建UI，并將所有它需要的類打樁，我們可以快速獲得UI是否滿足商業需求的反饋。我們可以討論可能需要修改的東西，我們有更大的機會來創建有價值的軟件。如果是另一個系統使用這個UI，我們可以檢查兩個系統是否能夠通信。
代碼促使開發人員編寫更多的代碼
Jerry編寫了界面的代碼，他盡力讓這一層很薄，并將界面使用的其他類stub out出去。然后，他思考下一步做什么�！拔倚枰粋�數據庫表，表中包含三個列……”
“等一等，” 我建議他，“我們現在就需要數據庫表么?我們有什么東西會使用數據庫表么?”
“嗯，我們需要使用用戶名、郵件地址和用戶id來創建用戶�！�
“做什么呢?”
“這樣用戶就能通過注冊界面在網站上注冊了�！�
“注冊界面需要什么東西來幫助它完成注冊新用戶么?是不是要在界面里做所有的工作?”
Jerry搖了搖頭�！澳且馕吨谝粋�地方放很多的代碼，會讓修改和維護變得異常艱難，而且UI的類也會難以測試，所以我們需要盡量讓它短小。我知道我們需要使用其他的類，在設計模式中通�？梢苑Q之為controller或者presenter�！�
我們知道我們將來需要修改某些代碼，因為Chris說過：“人們總是想要其他的東西”，或者因為業務上的差異性已經變化了�！耙簿褪钦f，UI需要將實際的工作分配給其他的類。我們現在能否知道我們的Controller將會使用一個數據庫中的表?”
“不能……”
“好的，”我說，“讓我們想想controller需要做些什么�！�
我們將代碼分解到不同的類或模塊中。單一職責原則是一個好方法。我們可以問問自己，“這段代碼應該做什么?不應該做什么?哪些東西是其他類的職責?我們將會如何使用這個類?”如果我們對每一行代碼都考慮這些問題，那么所有的代碼都會變得易于修改。
在單元級別，BDD語言仍然有用。我們可以使用“應該(should)”來幫助我們將職責拉出來。
“現在，我們知道controller的行為是什么，它如何使用其他的類-user repository和user information，”Jerry說，“我們還知道它應該響應UI的事件�！�
我說，“我們可以使用我們的controller寫一個fake UI類示例，來描述我們希望從controller中得到的東西。這可以幫助我們寫出能給UI帶來價值的最少的代碼。作為一個有用的副作用，它還能為我們帶來代碼的單元測試和說明文檔�！�
文章來源于領測軟件測試網 http://www.kjueaiud.com/
