当您到达迭代结束并且测试尚未完成时，您会怎么做？ [关闭]答案

【问题标题】：What do you do when you reach the end of an iteration and testing is not finished? [closed]当您到达迭代结束并且测试尚未完成时，您会怎么做？ [关闭]
【发布时间】：2008-11-26 10:22:10
【问题描述】：

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

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

【问题讨论】：

标签： testing agile

【解决方案1】：

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

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

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

【讨论】：

如果这是一次性的事情，我会仅同意这一点。否则，您将继续积累债务。承诺应该是整个团队的努力——开发、质量保证和验证。一个部分的失败应该是整体的。
同意——技术债也很痛苦。我实际上在内部培训中强调了这一点：永远，永远不要让进度压力诱使您积累技术债务，除非在非常罕见的情况下，即使这样，也应该非常清楚地记录并标记以供以后修复。

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

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

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

【讨论】：