阅读在线资料（例如Fowler、Gerard），似乎通过示例来规范故事不应该是完整的功能规范。
问题 1：从 SBE 开始的人如何决定他们的故事在描述系统的所有功能方面需要多全面？即我什么时候可以停止写故事，因为我已经捕捉到了足够的东西？
问题 2：在测试团队根据产品文档验证产品的组织中，如果商店不是完整的规范，我认为“其他”产品文档需要包含 SBE 未涵盖的所有案例是否正确？
问问题
97 次
1 回答
1
关于问题1：
开发任何系统最重要的部分是开发团队与产品所有者进行对话。首先找出他们需要的功能的症结所在。我将通过一个例子来回答这个问题；假设产品所有者可能想要一个设施来登录他们的新网站。这个要求可以写成：
In order to gain access to the website's facilities
As a user
I want to be able to login to the website
（请注意，我使用Gherkin领域特定语言来编写此答案中的场景和功能）
指定产品所有者的关键要求后，您现在应该与他们讨论您认为应该如何从用户角度实施此功能（保持高水平，不要使用技术术语，与业务讨论以找出他们想要什么）。因此，您可能识别的第一个“幸福路径”场景可能是：
Given a user is on the login screen
When they submit valid login credentials
Then they gain access to the main website
在与产品所有者进一步讨论后，他们告诉您，由于该网站包含极其敏感的信息，因此应将任何失败的登录尝试报告给系统管理员。这将导致另一种情况：
Given a user is on the login screen
When they submit invalid login credentials
Then the system administrator is informed of the failed log-in attempt
And the user is informed that their login attempt failed
此时产品负责人可能会说，这些是他们想要登录系统的唯一场景。所以从开发团队的角度来看，不需要对这个特性进行更多的调查（所以你不需要写更多的用户故事）。当然，在项目开发的后期，产品负责人也可能会告诉你，他们想在用户最后一次登录网站时通知他们，然后再到达主网站，但你只需要担心这个当他们要求时。
关于问题2：
组织应该根据“活”文档验证产品，例如使用Cucumber（例如）从上面详述的场景生成测试。
同样，正如我在问题 1 的答案中所说，您应该确定“足够”的场景/用例以满足产品所有者的需求。产品所有者要求的是完整的规范。不要试图猜测产品所有者可能想要什么，因为这可能会导致成为YAGNI的经典案例。
于 2013-12-02T01:15:30.980 回答