如何将系统测试集成到敏捷过程中？ [关闭]
How do you integrate system testing into an agile process? [closed]

什么阻止你制作自己的过程？ 如果你发现一些东西可以更好......就这样做吧。 如果它有效，坚持下去......如果没有尝试别的。 如果你想要敏捷，没有固定的过程。
被更频繁地使用的术语是在每次迭代结束“ 可交付的 ”代码。 这意味着您可以将其提供给最终用户（作为一堆DLL来复制共享或亲自发送CD / DVD），并且他将从使用它获得价值。 此类代码已通过所有单元测试（开发人员）和验收测试（客户/ QA /分析师） ，这些测试被认为是“完成”所必需的！ 验收测试是端到端的客户场景模拟。

我不确定你的'进一步测试和验证'是什么意思。我可以想到其他'预发布'活动

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

你只是在最后一次迭代终点结束时堆叠它（如果你像我一样特别悲观......采取历史平均值......如果你提前发布。是的！）所以，如果企业已经决定Iteration＃14划定一个好的一组可以发布的功能..在迭代＃14结束后只是'添加n周'..此时没有复杂的数学或不确定性。 关键点在于， 如果您定期与利益相关者/客户互动，纳入反馈并保持可接受的质量水平，那么最后一刻应该没有意外。

如果需要，你甚至可以开始 ......也就是说，当开发团队进入迭代＃13时，训练团队开始工作。 这给了他们假设2周迭代的一个月..并且希望你不会在最后一次迭代中输入大量的特征..所以在迭代＃14后的最多2周并且受到所有天体/组织对齐的影响，你应该是有释放和当之无愧的休息。

首先要认识到，您所说的测试的宽度/宽度随着项目的进行而增加 ，并且软件会增加范围和/或复杂性。 由于这个原因，尝试将这种努力付诸于迭代在一次或两次迭代后不起作用。 迭代的感觉良好规则是每个工作的一个恒定工作水平，由项目速度决定。

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

没有自动化，问题就会转移到基于测试管理的问题。 并行，时移测试迭代是一种候选解决方案。 例如，您可以选择为系统测试任务建立测试积压，这些测试任务以与开发迭代相同的节奏进行管理，但延迟或时移一个完整的迭代持续时间。 这使测试人员能够在他们自己的沙箱中的新版本以及他们自己的优先级上全面工作。

我主张测试迭代积压是与开发人员合作构建的，因为我认为开发人员迭代积压是与测试人员合作构建的。 我还提倡拥有自动化经验的测试团队，以便他们能够自动化乏味并以更具探索性的方式工作。 他们的自动化测试组合应该随着每次迭代而增加。 他们还应该可以访问开发人员单元测试，并能够在测试沙箱中的版本上运行它们。

像这样的异相工作不会使增加的测试范围/复杂性问题消失，但它确实提供了一种管理复杂性的机制，因为团队正在创建积压项目，调整优先级，自动化一些，创建清单等。基于他们认为下一步应该做的事情。 他们有机会击中大件物品。

保持测试人员整体工作的能力，发展他们的理解，并通过自动化测试分享他们对系统的了解，所有这些似乎都值得努力。

每次自动构建后的自动化测试至少可以让您获得部分成功。

将系统测试添加到您的sprint backlog（在Scrum中）或等效的。

同上用户文档。

系统测试的执行通常太慢而无法紧密集成到敏捷开发中。 （有一些例外情况，例如，精心设计的浏览器测试套件可以比典型的单元测试慢得多。）

一种集成方式是进行隔夜构建或持续构建，它始终运行，并且可能需要几个小时来构建和运行所有测试。 如果构建通过了所有测试（单元测试+系统测试），它就会变得可释放，您可以提供该二进制文件或源代码的快照。 我们的想法是拥有x版本的二进制文件/代码快照，异步验证它们，并提供绿色版本。 这应该适用于自动系统测试和手动测试。