当这些被实现出来时，第一个用户故事可以让我们从干系人那里得到美学方面的反馈，让他们考虑其他用户故事，例如放置相关商品的广告，这可以为项目愿景的实现添加一些不同点。其余的story可以晚一些再添加进来，我们可以从这些用户故事中分别得到反馈。
不是一定非要让BA来编写这些用户故事，不过通常他们对此比较在行。
用户故事促使QA创建场景
当QA测试一个特性时，他们通常会做三件事：
设置应用程序运行的初始状态、数据等
在测试环境中执行一些步骤
检查输出结果
然后他们设置不同的环境，检查不同的输出。
当需要自动化这些场景时，我们可以使用行为驱动开发(BDD)和场景语言Given、When、Then来定义这些(场景)。
“领域驱动开发”的作者Eric Evans有一次被问到，场景和用例之间有什么分别。“你无法向业务人员要用例”，我回答，“除非他们懂技术，知道用例是什么。但是你可以管他们要例子， 你可以说‘给我一个场景’”。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的类也会难以测试，所以我们需要尽量让它短小。我知道我们需要使用其他的类，在设计模式中通常可以称之为controller或者presenter。”
我们知道我们将来需要修改某些代码，因为Chris说过：“人们总是想要其他的东西”，或者因为业务上的差异性已经变化了。“也就是说，UI需要将实际的工作分配给其他的类。我们现在能否知道我们的Controller将会使用一个数据库中的表?”
“不能……”
“好的，”我说，“让我们想想controller需要做些什么。”
我们将代码分解到不同的类或模块中。单一职责原则是一个好方法。我们可以问问自己，“这段代码应该做什么?不应该做什么?哪些东西是其他类的职责?我们将会如何使用这个类?”如果我们对每一行代码都考虑这些问题，那么所有的代码都会变得易于修改。
在单元级别，BDD语言仍然有用。我们可以使用“应该(should)”来帮助我们将职责拉出来。
“现在，我们知道controller的行为是什么，它如何使用其他的类-user repository和user information，”Jerry说，“我们还知道它应该响应UI的事件。”
我说，“我们可以使用我们的controller写一个fake UI类示例，来描述我们希望从controller中得到的东西。这可以帮助我们写出能给UI带来价值的最少的代码。作为一个有用的副作用，它还能为我们带来代码的单元测试和说明文档。”
文章来源于领测软件测试网 https://www.ltesting.net/
