testing - 当您到达迭代结束并且测试尚未完成时，您会怎么做？

Question

我们正在尝试遵循我工作的软件开发的敏捷方法。到目前为止它运行良好，但是，在迭代结束时，我们遇到了构建问题，并且花费了一天的时间来修复：应该专门用于测试的时间。

结果，我们的 QA 没有足够的时间在迭代结束之前完成测试。您如何处理这种情况——在迭代过程中不可预见的问题会影响任务？

Answer 1

这取决于您的 QA 的安排——您是否可以让他们在开发人员已经在进行下一次迭代时继续测试？

如果是，我会让他们完成测试。
只需使用您已经拥有的数据继续下一次迭代。您真的不想因为一个瓶颈而阻止许多人。您可以在下一次迭代中增加一点额外的时间来修复尚未报告的错误，方法是为每个开发人员分配比完整迭代的价值略少的工作。

如果不是，只需像任何正常迭代一样计划下一次迭代，并像以前一样在迭代结束时进行测试。

Answer 2

如果您无法以约定的方式测试迭代输出，我们通常会为 sprint 取零分（或任何可以测试的点）。当时感觉很艰难，但事实证明这是一件明智的事情。

（项目的最后一个 sprint 显然是不同的）

Answer 3

通过在您的开发和 QA 之间进行一次切换，您已经在迭代中创建了一个单点故障。由于没有及时交付给 QA，您已经让这个迭代溜走了一天。通过匆忙进行质量检查来弥补时间并不是解决办法。

您可以通过更频繁地向 QA 交付来改善这种情况，理想情况下，您应该在每次完成功能时都这样做。如果最后一次构建失败，QA 可以只测试以前的构建，您必须将自那时以来实现的功能移动到下一次迭代。

Answer 4

敏捷规范是您仅将那些已完成的故事/积压项目计为已完成 - 通常您对已完成的定义应包括“正在测试”。因此，您根本不会因为尚未测试的故事而受到赞誉。毕竟，下一次迭代也可能出现类似的问题。

您对质量检查如何集成到您的流程中的问题并不完全清楚。一般来说，您应该确保错误无法逃脱 sprint，否则您的速度会变得非常不可靠。