通过sprint工作流程作为QA

Question

我最近一直在阅读关于短跑（敏捷方法）的内容，并且在工作流程中有一个关于测试的问题。我知道你有PBI（产品积压项目），它们被分解为任务。我也知道你应该一次关注一个PBI，而不是从不同的PBI中选择不同的任务。

我可能会错误地假设这一点，但是在PBI的所有任务准备就绪或者应该彼此独立测试的任务之后，是否应该对PBI进行测试？此外，如果您单独测试任务，那么您是否在所有任务完成后再测试PBI？

可能没有正确答案，我只是好奇其他人可能会这样做。

Answer 1

我多年来一直在使用敏捷和冲刺进行开发，测试总是在故事（PBI）完成时完成，而不是在PBI中的任务。原因主要是因为PBI应该具有可观察和可测量的所谓接受标准，并允许产品所有者或测试者验证故事是否已完成。

这些标准是在我们敏捷的短跑组织中完成/关闭的故事。对我来说，在完成所有任务后进行测试是有道理的，这样您就可以确保测试覆盖并完美地完成验收标准。

话虽如此，敏捷方法很灵活，而且，在您的上下文中，完成后测试每个任务会更有意义。

我希望这会对你的问题有所了解。我相信其他人会有不同的方法。

Answer 2

正在进行的测试对开发团队非常有帮助，因为反馈很早就会发生。然而，这是以测试资源的额外回归为代价的，以及潜在的“哦，我没有完成那部分”会话，因为工作不完整而发现问题。

如果您有额外的带宽，我希望让团队获得早期反馈，但是如果您按照计划按下，那么将自己应用于完全准备好先测试的PBI可能更有效率之后继续部分完成。

此外，您可能有创建PBI测试用例的文档要求，这可以在没有完成所有任务的情况下完成。在等待PBI完成时，这是您可以处理的sprint的另一个元素，因为它会向您的产品所有者和开发团队提出问题，并可能突出显示潜在问题或缺少尚未显示的详细信息团队的其他成员。