我们由三名开发人员组成的 Scrum 团队有一名专门的测试人员。目前，在我们为期 2 周的 sprint 的第一周的大部分时间里，测试人员表面上都在等待要测试的东西。我们通常在 sprint 第 1 周的周四或周五发布第一个 sprint 可交付成果。此时，我们的测试人员可以“测试”初期软件。
这引出了我心中的一个问题——在可交付成果开发的早期，像这样的功能测试增加了多少价值？
在开发的这个阶段（sprint 第 1 周结束），通常存在重大错误/功能遗漏，如果测试仅推迟几天（比如 sprint 的第 2 周），这些错误/功能遗漏将得到纠正。
在这种情况下，最佳做法是什么？
测试人员可能正在检查规范并编写测试脚本/验收标准步骤。
作为开发人员即将完成一项任务，但在签入之前，他们还可以进行小型测试审查，即在开发人员完成工作时与他们进行 5 分钟的眼球检查通常会发现一些错误。
总是在测试现有的应用程序（假设这不是新产品的第一个 sprint）总是有 bug 可以找到。
然后对现有的错误进行分类，它们是高优先级还是低优先级。
然后是测试和关闭开发人员已修复的错误。
当然，最重要的是煮咖啡并擦拭任何举手的开发人员发烧的额头。
当您提到 Scrum，一种良好的管理实践时，您并没有描述您正在使用哪种测试实践。
如果您使用最佳实践，您应该使用测试驱动开发。
测试驱动开发意味着必须从一开始就进行测试。程序员必须编写测试并填写通过这些测试的类。
测试人员应该在第 1 天编写应用程序在第 1 天绝对无法通过的功能测试。最终，应用程序开始通过这些测试，您可以称您的 sprint 已完成。
如果您不进行测试驱动开发，那么您应该这样做，并且您的测试人员应该编写集成测试用例。
如果您的测试人员不会编码，请教他们编码。您必须有一个可以编码的测试人员。并让他们在第一天开始编写功能测试。
我同意以上所述。当您为春季选择用户故事时，您应该开始定义如何测试它们
您发现了产品待办列表的问题。如果您有 3 名开发人员在 3 天内编写代码而没有可测试/可发布的代码，那么您的故事就太大了。你应该注意到这反映了你的燃尽图；flatline-> sprint 结束时的大跌幅。集成应该成为日常工作，新功能始终可用于测试。
怎么样：
将最后一个 sprint 中手动测试的一些故事测试自动化
自动设置测试数据（和/或机器），以便更快地进行下一轮回归测试。
为一些故事编写测试规范，以便开发人员在完成这些故事时获得更好的信息。