不幸的是，并非所有 AK 都可以被明确认定为“不利”。这就是实际的“示例映射”发挥作用的地方。对于每个 AK，至少应定义一个可用于演示实现的示例。如果找不到 AK 的示例，则应删除该 AK 或将其转换为开放问题。
第一个例子应该代表“快乐之路”。如果有多个，您很快就会找到更多示例。经验误情况。所有示例的共同点是它们不会增加实施工作量。如果这样做，则表明这不是示例，而是 AK。
等等，在这里您可能会认为错误处理程序不是示例，因为它们增加了实现工作量。对于原型来说可能是这样。如果没有错误处理，用于生产性使用的功能很少会令人愉快。
一般来说，每个故事都可以根据其 AK 进行剪切，而仅包含错误处理的故事不是故事，而是错误修复！
事实证明，“给定 - 当 - 那么”格式对于描述示 克罗地亚 电话数据 例非常有用，因为“非技术人员”也可以很好地理解它。我们看一下开头提到的AK：“全世界可用的所有支付方式都是可能的”。由于“全部”不可行，因此可以将 AK 更改为“所有常见可用的支付方式都是可能的”。如果您从这里开始，例如“给出 VISA 支付信息（卡号、有效期、卡验证码），确认购买，进行支付并显示支付成功确认信息”，很快就会明白：任何进一步的付款选项都会导致额外的努力。当您开始描述错误处理时，它就变成了一个非常长的细化。因此，人们很快就会将 AK 更改为：“可以使用 VISA 付款”。相关示例现在可以管理了。所有其他具有特定限制的支付选项都成为自己的 AK 或故事。对示例的清晰简单的描述使得利益相关者和我们的产品人员能够达成有效的改进，并且非常清楚应该实施什么。
结论
测试优先意味着从一开始就考虑测试。如果我们与利益相关者找到共同语言，例如通过示例映射，我们就可以通过快速反馈得出更好的要求。所有各方都能理解的要求，其实施是清晰且结构化的，并且从一开始就定义好，以便成功完成实施。没有代码，任何编译器都不会更快。