测试人员应接受持续交付和持续部署，因为它们提供了成长和学习新技能的机会。

  开发实践在一直在变化，作为测试人员，我们一定要拥抱变化。我们大家可以体验到的变化之一是从每月或每季度发布到持续交付或持续部署的转变。此外，这种向持续交付或部署的转变为测试人员提供了学习新技能的机会。

  每月或每季度发布的项目都有熟悉的节奏，并且团队会朝着发布日期进行构建。测试人员一定测试所有的卡并进行手动回归测试。手动脚本中的每个测试都需要执行，并且在大多数情况下要对这些测试的结果进行报告。发布后，发布中有几率存在需要修复的错误。测试人员还需要在下一个版本上开始运行相同的手动回归测试并再次报告。每月或每季度发布的测试是一个重复的过程。这样的一个过程被比作希腊神话中的西西弗斯，他必须将一块石头滚到山顶，然后当石头滚到山脚下时，他必须再次将它滚到山顶.

  持续交付可以定义为“当所有研发人员都在主干上进行小批量工作时，......当主干保持在可发布状态时，以及当我们按下按钮就可以发布时”。与我合作的一个团队从每月发布版本转变为持续交付。该团队将主要分支保持在能够准确的通过需要进行部署的状态，并且该团队每周会进行一次发布。持续部署可以定义为，除了支持持续交付的实践之外，“我们通过自助服务（由 Dev 或 Ops 部署）定期将良好的构建部署到生产中”。每次代码合并到主分支时，实践持续部署的团队都会部署到生产环境。

  实践持续交付或持续部署的团队使用小批量。这在某种程度上预示着部署的“批次”代码很小。“批量大小的理论下限是单件流，其中每个单元一次执行一个”；这就是在持续部署中发生的情况，其中每次合并到主分支都会部署到生产环境中。

  实践持续交付和持续部署的团队试图以可持续的速度创建工作流程，因此应该“在日常工作中启用和注入学习”。另一方面，每月发布版本的团队都是为了发布而构建的，因此无法以可持续的速度创建这种持续的工作流程。

  当团队从每月发布转向持续交付或持续部署时，发生的变化是没有发布候选。未在候选发布版上来测试；相反，它是在从主分支中取出的特性分支上完成的，当它们被合并回主分支时，它们必须准备好发布到生产环境中。主分支保持在可以发布到生产环境的状态。对于测试人员来说，这在某种程度上预示着在功能分支上的测试与在发布候选上的测试具有不一样的模式。

  在功能分支上来测试时，您需要确信功能分支中的新功能或修复会执行它应该执行的操作并且不会导致任何回归。测试月度发布时，你可以有时间执行手动回归测试，但如果主分支要保持可以部署到生产的状态，这是不可能的。如果您使用持续交付或持续部署，回归测试需要自动化。

  每月发布的回归测试通常包括运行大量手动测试；但是，如果您的团队正在使用持续交付或持续部署，回归测试通常会通过持续集成自动进行。持续集成 (CI)“意味着每次有人对代码进行任何更改”，更改都会集成到代码库中。这需要在将代码合并到主分支之前和之后运行自动化测试。这为测试人员提供了一个学习怎么样理解 CI 的机会。测试人员一定了解 CI，包括哪些测试作为 CI 的一部分运行。在 CI 上运行的测试总是会有差距。如果测试人员知道 CI 中的差距是什么，他们就可以想出如何自动化测试来填补这些差距，并在需要时执行手动测试来弥补差距。

  测试人员也能自己参与自动化回归测试，通过这一种方式，测试人能帮助防止错误而不是发现错误。有很多免费资源，例如测试自动化大学、LambdaTest 认证和 Exercism，它们能够在一定程度上帮助测试人员获得自动化测试所需的技能。还有很多资源可以学习如何使用 javascript 来辅助测试。

  回归测试是自动化的，为测试人员创造了时间，他们可以花时间进行探索性测试。探索性测试是发现问题的有力方式，因此它将有助于测试人员正在进行的项目。有额外的时间做探索性测试也将帮助测试人员发展他们的探索性测试技能。

  使用持续交付和持续部署的项目也往往具有微服务架构。微服务是有独立测试和部署的服务，每个服务都很简单。测试人员有机会了解微服务，方法包括与开发人员交谈、研究现有的架构图、阅读 GitHub 中每个服务的自述文件以及参加开发人员会议。

  测试人员可以通过帮助开发人员测试他们的代码来建立他们与开发人员的关系。此外，测试人员可以与开发人员分享他们的测试技术知识，例如边界值分析，因为这将有助于他们测试和生产质量更好的软件。

  每月发布的发布过程可能会给测试人员带来一定的痛苦。有时我们被要求负责做出发布决定，即使测试人员通常是团队中的初级成员；其他时候，测试人员必须参加由利益相关者组成的大型委员会会议，以决定是否可以发布软件。持续部署和持续交付的发布过程应该是自动化的；这意味着发布不会给测试人员带来压力。测试人员在持续交付和持续部署中对发布的输入是他们的测试；这意味着我们可以专注于测试并学习新的测试技能。

  开发团队不是自治的；它们是开放系统，其工作会影响其他团队并受到其他团队的影响。这就是系统思维，而系统思维有助于持续交付和持续部署。测试人员可以学习使用系统思维来增强他们的测试并支持他们的团队。这能够在一定程度上帮助测试人员跳出他们的角色思考，以了解哪些其他系统受其团队工作的影响以及哪些系统影响其团队的工作。

  系统思考的教训之一是每个人都有责任，所以当出现问题时，任何人都不应受到指责。这个观点也应该是每个实施持续交付或持续部署的敏捷和精益开发团队的核心。这是测试人员应该学习并牢记在心的事情。当出现失败时，我们需要从中吸取教训，而不是责怪某人。

  每月发布的团队会发现，在每次发布之后，都会有一系列活动修复发布中部署的回归错误。实践持续交付或持续部署的团队不会发生这种情况。发布将使用持续部署每天多次部署，软件将通过持续交付定期部署。这些定期发布使开发团队有机会快速从错误和事件中恢复，因为可以快速部署修复程序。部署修复程序后，测试人员可以主动提出带头进行根本原因分析，以找出错误或事件的根本原因。测试人员能学习使用五个为什么和石川图来进行根本原因分析。

  测试人员还能够最终靠生成有助于团队衡量质量改进的指标来支持团队的工作。DORA 指标由 DORA 的 Accelerate State of DevOps 调查报告确定。这些指标旨在帮助实践持续交付和持续部署的团队找到需要改进的地方并了解他们的表现。这些与每月发布的指标不同，因为它们不是关于有多少错误已投入生产，而是关于团队从错误中恢复的速度。

  持续交付和持续部署为测试人员提供了成长和学习新技能的机会，因此当他们的团队转向持续交付和持续部署时，测试人员应该抓住机会。

  「持续集成(ContinuousIntegration)」、「持续交付(ContinuousDelivery)」和「持续部署(ContinuousDeployment)」提供了一个优秀的DevOps环境，对于整个团队来说，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。

  通常持续集成(CI)意味着代码被不断地测试，与其他的代码修改进行整合与合并。持续交付(CD)则意味着不断将带有补丁的代码部署到整个代码库中。在文档案例中，这在某种程度上预示着内容被不断地测试，不断合并每个补丁，并进行部署。对于文档来说，部署就意味着发布。部署文档意味着输出文件被拷贝到了Web服务器上供所有人查阅。