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

Question

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

因此，我们的QA没有足够的时间在迭代结束之前完成测试。您如何处理这种情况 - 在迭代期间无法预料的问题会影响任务？

Answer 1

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

如果是，我会让他们完成测试 继续使用您已经拥有的数据进行下一次迭代。你真的不想因为一个瓶颈而阻止一些人。您可以在下一次迭代中添加一些额外的松弛来修复尚未报告的错误，通过为每个开发人员分配比完整迭代更少的工作量。

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

Answer 2

如果你不能以同意的方式测试迭代输出，我们通常会为sprint（或任何可以测试的点）取零点。在那里感觉很艰难＆amp;但事实证明这是明智之举。

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

Answer 3

通过在开发和QA之间进行单次切换，您在迭代中创建了单点故障。你已经让这个迭代过了一天，没有及时交付QA。通过推动质量保证来弥补时间不是答案。

您可以通过更频繁地提供给QA来改善这种情况，理想情况下，每次功能完成时都会执行此操作。如果最后一次构建失败，QA可以只测试以前的构建，并且您必须将之后实现的功能移动到下一次迭代。

Answer 4

敏捷佳能是指您只计算那些已完成的故事/积压项目 - 通常您对DONE的定义应包括“正在测试”。所以，你根本没有得到未经测试的故事的信任。毕竟，下一次迭代也可能出现类似的问题。

关于QA如何集成到您的流程中的问题，您并不完全清楚。一般来说，你应该确保错误无法逃脱冲刺，否则你的速度变得非常不可靠。