17、支持团队的面向业务测试

支持团队的面向业务测试

在软件开发过程中，敏捷团队常常面临如何获取需求的诸多问题，比如如何确定代码的功能、怎样获取足够的编码信息、让客户清晰表达需求、明确每个故事的起点、获取客户示例以及编写故事测试等。接下来将深入探讨创建面向业务测试的策略，以支持团队开发每个故事。

需求困境

几乎所有开发团队，无论是否采用敏捷方法，都在需求方面面临挑战。传统瀑布项目团队可能花费数月收集需求，结果却发现需求有误或很快过时；处于混乱模式的团队可能根本没有需求，程序员只能自行猜测功能的实现方式。

在敏捷开发中，新功能通常以客户团队编写的故事或故事组形式出现。编写故事并非要确定实现细节，尽管高层讨论可能会影响依赖关系和故事数量。若技术团队成员能参与故事编写会议，就能为功能故事提供意见，确保技术故事纳入待办事项。程序员和测试人员还能帮助客户将故事拆分成合适的大小，提出更可行的替代方案，并讨论故事间的依赖关系。

故事本身对所需功能的描述并不详细，通常只是一句话，说明谁需要该功能、功能是什么以及为什么需要。例如“作为网购者，我需要一种从购物车中删除商品的方法，以免购买不需要的物品”，这留下了很多想象空间。故事只是业务专家与开发团队持续对话的起点。如果团队成员理解客户试图解决的问题，就能提出更简单易用和实现的替代方案。

在客户与开发人员的对话中，敏捷团队会不断扩展故事，直到获得足够信息来编写合适的代码。测试人员帮助引出每个故事的示例和背景，协助客户编写故事测试。这些测试指导程序员编写代码，并帮助团队确定何时满足了客户的满意度条件。如果团队有用例，它们可以补充示例或指导测试，以明确所需功能。

在敏捷开发中，我们承认无法提前了解一个故事的所有需求。完成使故