在我们的团队中，我们在整理/计划用户故事时努力定义明确的接受标准。这使我们的质量检查成员感到疏远，因为他们对测试内容的了解并不完全。通常，我们的接受标准定义了我们期望故事不应该出现的内容，而不是应该的故事，这让人感觉很错误。关于如何编写有效的用户故事，我已经找到了很多东西，但是没有什么可以接受的。有人对如何解决问题或可以使用的资源有任何想法吗？
#1 楼
有一个“钢线”的概念，我们在我以前的工作中曾经使用过，其中用户故事本身是一个特殊的要求，并且具有非常特殊的期望。该特定期望之外的任何内容都应该是其自己的用户故事。然后，可以将接受测试的重点和目标放在验证用户故事的“钢线”已被验证。这并不意味着只有一个验收测试，而是编写的验收测试不能超出“钢线”的有限范围。当您进行验收测试时，定义了不应该发生的事情，我认为实际上应该是它自己的用户故事。
例如，某个用户故事可能为：
“作为网站管理员，我可以将小部件B配置为以蓝色，红色，和黄色”
一组验收测试将是：
Web管理员可以访问小部件B的配置选项
有一个选择列表，其中有蓝色，红色和黄色这三种原色
当网站管理员将小部件B设置为蓝色时，它显示为蓝色
当网站管理员将小部件B设置为红色时，它会显示以红色
当网站管理员将小部件B设置为黄色时，它显示为黄色
网站管理员除了蓝色，红色或黄色以外没有其他选择
。但是，如果您需要检查并确保没有其他人具有这些功能，则应该写一个不同的用户故事来说：
“作为网络用户，我无权访问小部件B的配置选项”
，然后编写适当的验收测试。
这种方法的好处是可以满足要求的粒度，因此您可以轻松地确定必须执行的故事的优先级，并积压可以等待的故事，然后在开发人员，测试人员和产品所有者中保持关注，以确保在任何特定情况下都能完成用户故事迭代而没有任何不必要的出血。
编辑：添加了验收测试6，作为“应不这样做”在用户故事中有效的一项验收测试的示例。用户故事指出了三种原色。应该没有其他可用的选项。用户故事未提及任何其他用户，任何其他小部件的配置选项或类似内容，因此它们被归类为不同的用户故事。
评论
我喜欢“钢线”的想法。我开始假设我们的用户故事足够好，但是也许我们需要从那里开始。如果用户的故事很好，那么接受就容易了。谢谢，以它为答案，这给了我一些帮助。
–ale
2011年5月13日在16:42
我发现，当使用这种软件开发和设计方法时，用户故事绝对是关键。处理好这一点，一切都准备就绪。如果用户故事过于笼统，您最终会陷入困境并拖延开发。如果过于具体，那么您会陷入很多小细节的故事中。找到平衡是关键。
– TristaanOgre
2011年5月13日在16:54
@TristaanOgre，什么是“钢线”？
–起搏器
2015年10月8日，下午6:51
#2 楼
我们保持简单：我要么询问支持经理，要么通过客户错误来解决。听起来他们会应用到80％的客户（我尝试在验收（或冒烟）测试中进入我的测试场景）。评论
对于为新功能创建验收测试，我不确定研究过去的错误将如何对创建那些验收测试大有帮助。虽然它可能有助于理解过去经历的陷阱，因此，可以将流程的其他信息（设计，其他用户案例等）告知其他方面，但为特定用户案例编写验收测试，我认为应该与以下方面的期望联系起来该用户故事。
– TristaanOgre
2011年5月13日在15:48
同意新功能。我通常指的是测试场景。
–劳拉·亨斯利（Laura Hensley）
2011年5月13日15:57
评论
作为担任此职位的质量检查人员，我写下我对接受标准的最佳猜测，然后由开发人员运行以进行验证。您的质量检查成员现在这样做了吗？如果是，他们会得到什么反馈？他们现在不这样做。我会为即将到来的冲刺推荐它。听起来很容易上手。