如何将系统测试集成到敏捷流程中？[关闭]

Question

敏捷开发的经典描述在迭代结束时具有可发布的代码。如果需要进行进一步的测试和验证才能创建可发布的产品，您如何将其集成到流程中？

Answer 1

是什么阻止你制定自己的流程？如果你发现某些东西可以做得更好......去做就对了。如果有效的话就坚持下去吧..如果不尝试其他方法。如果您想要敏捷性，就没有一成不变的流程。
最常用的词是‘可运送的' 每次迭代结束时的代码。这意味着您可以将其提供给最终用户（作为一堆 DLL 来复制共享或亲自交付 CD/DVD），他将从使用它中获得价值。这样的代码 已通过所有单元测试（开发人员）和验收测试（客户/QA/分析师） 这被认为是“完成的”是必要的！接受测试是端到端的客户场景模拟。

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

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

你只需将它堆叠在最后一次迭代终点的末尾（如果你像我一样特别悲观......取历史平均值..如果你早点释放。是的！）因此，如果企业决定 Iteration#14 划定了一组可以发布的良好功能..它只是在 Iteration#14 结束后“添加 n 周”。那时没有复杂的数学或不确定性。关键是 如果您定期与利益相关者/客户接触，纳入反馈并保持可接受的质量水平，那么就不应该出现最后一刻的意外。

如果需要的话，你甚至可以 滚动启动..IE。当开发团队进入 Iteration#13 时，培训团队开始工作。假设两周迭代，他们就有一个月的时间。希望您不会在最后一次迭代中输入大量功能。因此，在第 14 次迭代之后最多 2 周，并且根据所有天体/组织的调整，你应该有一个发布和一个当之无愧的休息。

Answer 2

首先认识到您所说的测试的宽度/广度 增加 随着项目的进展和软件的范围和/或复杂性的增加。因此，尝试将这种努力投入到迭代中在一两次迭代之后就行不通了。迭代的良好规则是每次迭代的工作水平保持不变，这由项目速度决定。

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

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

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

像这样的异相工作并不会让不断增加的测试范围/复杂性问题消失，但它确实提供了一种管理这种复杂性的机制，因为团队正在创建待办事项、调整优先级、自动化一些、创建清单等。基于他们集体认为下一步应该做什么。他们很可能会击中大件。

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

Answer 3

每次自动化构建后的自动化测试至少可以帮助您完成部分工作。

Answer 4

将系统测试添加到您的冲刺待办事项（在 Scrum 中）或同等内容中。

同上用户文档。

Answer 5

系统测试的执行通常太慢而无法紧密集成到敏捷开发中。（也有例外，例如一套精心设计的浏览器测试的运行速度不会比典型的单元测试慢很多。）

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