在开始处理用户故事之前，确定接受标准非常重要。 当您详细说明积压订单或计划下一个冲刺时，可以完成此操作。 为此，一些团队举行了名为3 Amigo的特别会议（在上
一篇文章中有更多关于他们的
信息 ），集会，根据规格的启动或会议研究。
不要这样称呼，对于大多数团队来说这很难。 主要困难在于此类会议是无组织的，其结果令人难以理解。 它们既费时又无聊。 结果，会话变得不规则或完全被放弃。
但是，有一种简单的方法可以使此类会议简短而富有成效。 这种方法称为示例映射或测试用例映射。
如何运作
特定的测试用例（示例）是探索主题领域的好方法。 它们可以作为您进行验收测试的良好基础。 当我们讨论测试用例时，还需要谈到其他方面。
- 总结不同案例或反之亦然的规则限制了测试案例的适用性。
- 当没有人知道真实情况时，会遇到有关场景的问题 。 或我们提出的假设 ，以某种方式推动需求的发展。
- 讨论期间揭示的新用户故事 。
“示例映射”使用一组四种不同颜色的卡片和圆珠笔记录您讲话时的新信息。 在会议期间，如上图所示，信息记录在卡上并放在板上。
首先，在黄色标签上，您需要写下
故事本身并将其放置在面板的顶部。 接下来，在蓝色标签上指示我们先前制定的每个
接受标准或规则 。 我们将蓝卡放在黄色下面。
每个规则通常可以用几个
测试用例说明。 每个测试用例都有自己的绿色标签，该标签位于相应的规则下。
在我们编辑地图和讨论案例时，可能会出现一些
问题 ，这些
问题都无法解决。 我们将它们固定在红色贴纸上，然后继续讨论。
会议持续进行，直到每个人都确信故事已被完全理解或分配的时间结束为止。
即时反馈
在这样的对话过程中，可以轻松快速地建立当前对历史理解的视觉表示。
- 一块布满红色标贴（问题）的木板说，还有很多事情要做。
- 一块布满蓝色标贴（规则）的标牌表示故事大而复杂。 也许您需要分解它。 也许您需要再贴一个黄色标签（故事）并将部分故事放入待办事项列表中。
- 如果一个规则包含太多的测试用例，那么它可能太复杂了，您需要突出显示几个可以单独详细描述的规则。
您可能会发现某些规则是如此明显，以至于它们不需要测试用例。 例如，如果每个人都以相同的方式理解规则，那么您就不需要浪费时间并折磨固定数量的测试用例。
在有限的时间内思考
一群好朋友应该在
25分钟左右完成一个体面的故事。
如果您无法满足分配的时间，则可以选择以下几种方法：
- 您仍在学习使用此方法（这是正常的）；
- 您的故事太大了（绝对不再好了）；
- 您的故事充满不确定性。
该怎么办？ 您可以尝试将故事分为几个故事，或者将产品功课交给所有者，以便稍后在下一个会话中通过示例映射并返回答案一起返回到该故事。
Cucumber的Matt Wynne邀请与会人员在25分钟内投票表决该故事是否已准备好进行开发。 即使仍未解决某些问题，团队也可能会确定不确定性不大，并且可以在此过程中进一步发展。
得益
示例映射有助于更改比例并专注于最小的历史行为。 通过编译地图，您可以选择规则，找到所需行为的本质，然后将其余行为推迟到以后。 由于研究的彻底性，示例映射就像一个过滤器，可以防止大胆的故事进入冲刺，并在最后一分钟给出令人不愉快的惊喜。 此外，这种方法可以节省时间，并有助于保持感兴趣的人在此过程中的参与。
在某些人看来，
在此会议
期间 3位好友应编写接受测试（例如，Cucumber的脚本）。 原则上，在某些情况下这可能是有道理的，但通常这种方法只会分散谈话的真正目的。
很明显，这种观点从何而来：显而易见的目标是获取已经有一些预定义验收标准的用户案例，并找到可以转化为验收测试的测试用例。
真正的目标是对创建故事所需的内容达成
共识 。 您无需高科技即可快速实现此目标。
简化录音
因此，与其使用正式的Gherkin脚本，不如尝试使用命名约定快速编译一系列
测试用例 。
例如：
当不确定性隐藏在该案例名称的后面时，您本能地希望获得详细信息。 但是即使那样，也没有必要坚持当时的刚性结构
。如果结果（“ then”）不清楚，则该示例将不起作用，但问题将是。
已知未知
如果对话开始圈出，则说明信息不足。 也许会议没有合适的人，或者您需要做一些研究或使用
Spike 。
与其听取每个参与者关于他们的结果应该是什么的意见，只需将问题写在红牌上并继续。 因此，
未知将变成
已知的未知 。 这是一个很大的进步。
根据经验，即使是映射示例的这一方面，也可以使3次Amigo会议从无聊变成快速高效。
谁应该参加？
最小值为3位好友：开发人员，测试人员和产品所有者（业务分析师）。 这只是最低要求。 此外，您可以邀请操作人员，UX专家或与正在讨论的故事相关的其他任何人。 在对话期间可以帮助找到新问题或将问题变成答案的任何人都将有所帮助。
当您掌握此技术时，可以很方便地找人担任主持人。 他的正式任务是确保所说的一切立即记录在贴纸上。 在测试过程中，会迅速讨论测试用例和问题，要及时将其写在贴纸上以查看所讲内容是需要纪律的。
那么什么时候写小黄瓜？
不要误会，使用Gherkin具有很大的价值，尤其是在项目的早期，开发通用语言时。 表达方案至关重要，团队中的每个人都应相信它们。
但是以这种方式描述测试用例需要不同的思维方式。 不仅要确定哪些案件属于相关领域，还需要为它们建立一般规则。
对于使用相当成熟的领域语言工作的团队来说，产品所有者将更多的时间和精力花在映射上，而将写Gherkin的任务写给另外两个好友变得更加有利可图。 他们制定了Gherkin规范后，产品所有者将能够提供反馈。 问自己一个问题：“我会这样写吗？” 您可以检查在将产品知识转移到友友方面有效的映射。
多久一次？
在实践中，建议
隔天开会。 只需选择一个用户案例并给予25分钟的关注，然后重新开始工作即可。 如果您尝试做更多的事情，那就浪费您的精力。
但是我有一个分散的团队！
为此，我们已经提出了解决方案，例如Google Keep上的贴纸列表或带有彩色贴纸的在线留言板。 您可以使用思维导图。 最主要的是
您应该能够简单快速地进行工作，
以便您可以专注于对话 。
最后几点提示
在使用示例映射之前，清楚地区分
规则和测试用例很重要。 有一个
有趣的练习 。
请记住，这样的会议的最终目的是
发现您尚不了解的东西 。 没有愚蠢的问题，它们都有助于真正调查问题。
使用这种技术，您会发现规则为您的故事创造了自然的发展路线。 尝试冷静地与问题联系起来，将它们分开并放在一边。 然后，您可以专注于解决主要问题。 您可以使复杂化，并在以后实现理想。
我们将在QualityConf会议上讨论3 Amigo制定要求和构建测试用例卡的实践。 此外，已接受报告的列表还包含用于创建高质量IT产品的其他非常有趣的实用方法。 作为5月27日至28日RIT ++节的一部分，QualityConf会议将首次举行。