Testing 在Scrum中，从哪里获取详细需求？

我总是听说，一个用户的故事应该非常简短和清晰，所以它可以写在笔记上等。作为一个用户，我希望能够进入，修改和删除目录中的人

但对于测试，我们需要知道：

int16-32中的字段、边界和范围是什么？ 验证消息是什么？ 弦的长度等。

---

在Scrum中如何解决这个问题？

Scrum/Agile的思想是关注所编写功能的业务价值，而不是在故事开始之前就迷失在详细的实现细节中。因此，我们的建议是让故事信息尽可能简短。但是，当故事发展起来时，开发团队将创建/发现一些功能/技术限制，并与产品负责人核实它们是否正常，并将它们记录在您用来跟踪故事的任何系统中—另一个post-it便笺或Jira中的评论。然后，作为测试人员，您将有更多信息来检查边界/范围，例如。现在，一些其他信息，如验证消息，可以留待常识处理。你真的想要这方面的规格吗？如果这对开发人员有意义，并且作为一名测试人员，您发现消息是OK，那么您就完成了OK。

它们将成为验收标准的一部分。您可能应该让PO回答这些问题，这通常是由每个scrum团队成员在提交之前都必须同意的“完成”的通用定义来实现的

用户故事验收标准应阐明用户故事中涉及的所有要求。产品所有者需要轻松验证这些标准，以允许用户故事完成，例如，您可以在文本字段中键入多少字符。团队中的每个人都需要了解必须做什么，但是在Scrum活动会议期间，您可以只使用用户故事标题

---

将技术内容放入任务中，例如用于存储字符串的db字段大小、其他技术假设等，不要以此干扰产品负责人和QA人员。

在团队使用自动测试这些验收标准的情况下也会更好。我投票将此问题作为离题题结束，因为它与编程无关。