敏捷开发的经典描述在迭代结束时具有可释放的代码。如果需要进一步的测试和验证来创建可释放的产品，那么如何将其集成到流程中？
答案 0 :(得分：3)
是什么阻止你制作自己的流程？如果你发现一些东西可以更好......就这样做吧。如果它有效，坚持下去......如果没有尝试别的。如果你想要灵活性，就没有固定的过程 更常用的术语是每次迭代结束时的“可发送”代码。这意味着您可以将其提供给最终用户（作为一堆DLL来复制共享或亲自发送CD / DVD），并且他将从使用它获得价值。此类代码已通过所有单元测试（开发人员）和验收测试（客户/质量保证/分析师），被认为是“完成”所必需的！验收测试是端到端的客户场景模拟。
我不确定'进一步测试和验证'是什么意思。我可以想到其他'预发布'活动
你只是在最后一次迭代结束时堆叠它（如果你像我一样特别悲观......拿走历史平均值......如果你早点发布。是的！）所以如果业务决定迭代＃14划定一系列可以作为发布的功能。在迭代＃14结束后，它只是'添加n周'。此时没有复杂的数学或不确定性。关键点在于如果您经常与利益相关者/客户互动，纳入反馈并保持可接受的质量水平，那么应该没有最后一分钟的意外。
如果需要，您甚至可以开始滚动 ..即，当开发团队进入迭代＃13时，培训团队开始工作。这给了他们假设2周迭代的一个月..并且希望你不会在最后一次迭代中输入大量的功能..所以在迭代＃14后的最多2周并且受到所有天体/组织对齐的影响，你应该是有释放和当之无愧的休息。
答案 1 :(得分：3)
首先要认识到，当项目进行并且软件获得范围和/或复杂性时，您所说的测试的宽度/宽度会增加。由于这个原因，尝试将这种努力付诸于迭代在一次或两次迭代后不起作用。根据项目速度确定，迭代的感觉良好规则是每个工作的恒定工作水平。
这方面的解决方案可以采取两条道路之一：有或没有自动化。较高测试级别的自动化将减少运行测试的工作量，使工作再次适合迭代，因为每次迭代只关注增量范围/复杂性增加。在所有项目环境中，这并不总是可以实现的，即使这是我们想要的。高估的高级测试自动化是一个你应该认真对待的陷阱，换句话说，避免低估一个经验丰富的探索性测试人员所带来的东西。
如果没有自动化，问题就会转移到基于测试管理的问题。并行，时移测试迭代是一种候选解决方案。例如，您可以选择为系统测试任务建立测试积压，这些测试任务以与开发迭代相同的节奏进行管理，但延迟或时移一个完整的迭代持续时间。这使测试人员能够在他们自己的沙箱中的新版本以及他们自己的优先级中全面工作。
我主张测试迭代积压是与开发人员合作构建的，因为我认为开发人员迭代积压是与测试人员合作构建的。我还提倡拥有自动化经验的测试团队，以便他们能够自动化乏味并以更具探索性的方式工作。他们的自动化测试组合应该随着每次迭代而增加。他们还应该可以访问开发人员单元测试，并能够在测试沙箱中的版本上运行它们。
像这样的异相工作不会使测试范围/复杂性问题日益严重，但它确实提供了一种管理复杂性的机制，因为团队正在创建积压项目，调整优先级，自动化一些，创建清单等等，基于他们认为下一步应该做的事情。他们很可能会击中大件物品。
保持测试人员全面工作的能力，发展他们的理解，并通过自动化测试分享他们对系统的了解，所有这些似乎都值得努力。
答案 2 :(得分：1)
每次自动构建后的自动化测试至少可以让您获得部分成功。
答案 3 :(得分：0)
将系统测试添加到您的sprint backlog（在Scrum中）或等效的。
同上用户文档。
答案 4 :(得分：0)
系统测试的执行通常太慢而无法紧密集成到敏捷开发中。 （有一些例外情况，例如，精心设计的浏览器测试套装可以比典型的单元测试慢得多。）
一种集成方式是进行隔夜构建或持续构建，它始终运行，并且可能需要几个小时来构建和运行所有测试。如果构建通过了所有测试（单元测试+系统测试），它就会变得可释放，您可以提供该二进制文件或源代码的快照。我们的想法是拥有x版本的二进制文件/代码快照，异步验证它们，并提供绿色版本。这应该适用于自动系统测试和手动测试。