在每次自动构建之后进行自动测试，至少可以帮助您完成部分工作。

将系统测试添加到sprint backlog中(在Scrum中)或类似的工作中。

用户文档也是如此。

是什么阻止了你制定自己的流程?如果你发现还有更好的地方……尽管去做。如果成功了，就坚持下去。如果不行，试试别的。如果您想要敏捷性，就没有固定不变的过程。
更常用的术语是每次迭代结束时的“可交付”代码。这意味着您可以将它提供给最终用户(作为一堆dll复制共享或亲自交付CD/DVD)，他将从使用它中获得价值。这样的代码已经通过了“完成”所必需的所有单元测试(开发人员)和验收测试(客户/QA/分析师)。验收测试是端到端的客户场景模拟。

我不确定你说的“进一步测试和验证”是什么意思…我还能想到其他“预发布”活动

• 某些活动，如“培训会议”和相关内容的创作。
• 如果客户部署很少或不可能频繁进行，则在发布前一个月进行演示或部署到测试版站点。
• 潜在客户/专家/服务可以亲身体验他们听说过的新产品。

你只需要在最后一次迭代结束时将其堆叠起来(如果你像我一样特别悲观的话)。取历史平均值…如果你提前释放。耶!)因此，如果业务部门已经决定迭代#14划分了一组可以作为发布的良好特性。这只是在第14次迭代结束后“添加n周”。在这一点上没有复杂的数学或不确定性。关键的一点是，如果你经常与利益相关者/客户接触，吸收反馈并保持可接受的质量水平，就不应该在最后一分钟出现意外。

如果需要，你甚至可以做滚动起步。例如，当开发团队进入迭代#13时，培训团队开始工作。这给了他们一个月的时间，假设迭代时间为2周。希望你不会在最后的迭代中加入大量的特性。所以在第14次迭代后最多2周，并且在所有天体/组织对齐的情况下，你应该有一个发布和应得的休息。

系统测试的执行通常太慢，无法紧密地集成到敏捷开发中。(当然也有例外，例如，一套设计良好的浏览器测试的运行速度不会比典型的单元测试慢多少。)

集成的一种方法是拥有一个通宵构建或持续构建，它会一直运行，并且可能需要几个小时来构建和运行所有的测试。如果一个构建通过了所有的测试(单元测试+系统测试)，它就可以发布了，您可以交付二进制代码或源代码的快照。其思想是拥有二进制文件/代码快照的x个版本，异步验证它们，并交付绿色构建。这应该既适用于自动系统测试，也适用于手动测试。

首先要认识到，您所说的测试的宽度会随着项目的进行而增加，软件的范围和/或复杂性也会增加。因此，在一两次迭代之后，尝试将此工作投入到迭代中是行不通的。对于迭代来说，感觉良好的规则是每个迭代都有一个恒定的工作水平，这是由项目速度决定的。

解决这个问题的方法有两条:有或没有自动化。较高测试级别的自动化将减少运行测试的工作，使工作再次适合于迭代，因为每次迭代只关注增量范围/复杂性的增加。即使这是我们想要的，但在所有项目环境中并不总是可以实现。高估高级测试自动化是您应该认真对待的一个陷阱，换句话说，避免低估一个相当有经验的探索性测试人员所带来的东西。

如果没有自动化，问题将转移到基于测试管理的问题上。并行、时移测试迭代是一种候选解决方案。例如，您可以选择为系统测试任务建立一个测试backlog，该测试任务以与开发迭代相同的节奏进行管理，但是被延迟，或者时间转移，最多可以延迟一个完整的迭代持续时间。这使得测试人员能够在他们自己的沙盒中按照自己的优先级整体地开发新版本。

我主张测试迭代backlog是在与开发人员合作的情况下构建的，正如我主张开发人员迭代backlog是在与测试人员合作的情况下构建的一样。我还提倡有自动化经验的测试团队，这样他们就可以自动化单调的工作，并以一种更具探索性的方式工作。他们的自动化测试组合应该随着每次迭代而增加。他们还应该能够访问开发人员单元测试，并能够在测试沙箱中的发行版上运行它们。

像这样脱离阶段的工作并不能消除不断增加的测试范围/复杂性问题，但它确实提供了一种管理复杂性的机制，因为团队正在创建待办事项项、调整优先级、自动化一些项目、创建检查表等等，这些都是基于他们共同认为下一步应该做的事情。他们很有可能会碰到大项目。

保留测试人员整体工作的能力，并通过自动化测试发展他们的理解和分享他们关于系统的知识，这些似乎都是值得争取的。