软件行业正在向更加快速交付转型，新的工具和技术对测试人员构成更大的挑战，适应这种快节奏有太多内容需要学习，而且常常带来很大的压力。以我个人的经验，测试人员成为DevOps环境下的瓶颈并不罕见。没有什么比试图为团队提供价值但同时又经常阻断了团队的发布进程更让人沮丧了。
在DevOps领域，甚至对整个行业而言，持续测试的重点几乎毫无例外都集中在自动化测试上，宣称CI/CD流程下，测试用于为团队提供快速反馈。如此定义持续测试过于狭隘，完全无法反映测试工程师可以为团队提供的更多价值。自动化测试对于希望能够频繁发布的团队至关重要，但是在DevOps团队中，测试工程师还可承担更多职责。
参与需求收集
对一个团队来说，知道我们正在做什么以及为什么要做（know what and way）非常重要。新的功能是需要解决什么问题？这些问题最好在产品、测试、开发都在场的澄清会议上得到讨论，整个团队都能参与讨论非常重要！
一旦理解了待解决的问题，我们就能使用实例来尝试找到那些被忽略的需求并和团队分享我们的想法，这是测试人员擅长的领域，在测试时我们会从待测功能外部来考虑测试场景，而在这种前期阶段我们也可利用这种思考方式，从用户的角度思考功能并且和团队分享。
比如：当你设计重置密码功能时，主路径是允许用户重设密码。但“是否允许用户使用之前设置过的密码？”，“一天内用户重设密码的次数是否需要限制？”这样的问题能帮助团队更好的理解需求。
通过在前期讨论这些场景，我们可以减少对于需求的理解偏差。在早期阶段讨论和达成对于功能需求的共识远比实际完成开发并部署到测试后再发现此类分歧更为经济和容易。
和团队分享测试场景
现在你已经和团队就需求理解上达成了共识，那么下一步就可以和团队讨论具体的测试场景了。还以上面的例子来说，如果正在设计一个密码重置功能，并且产品经理已经确认设置密码时不能使用最近的5个已用密码，那么这就是一个已明确的测试场景。
分享计划执行的测试场景的好处在于这可以减少在后期产生预期外bug的几率。告诉团队“这是我打算执行的测试用例，以及它们的预期结果”，那么你就能确保团队都能知晓你会测试的功能路径。团队和产品经理不一定需要完全赞同你的测试场景，但是没关系，越早进行这样的分享和讨论就越能节省团队的工作量和减少浪费。如果是在CI/CD后期执行自动化测试以后再来讨论，会比早期发现这些问题产生更多的重复工作
以我的经验来看，在DevOps环境下，越是需要经常发布的团队，越是应该经常性地进行这些沟通。在需求理解上投入越多，在后期就会越少产生返工和预期外的工作。很多时候，简单地和团队分享对功能的理解就能提升团队高质量产品的发布率。
结对单元测试
写单元测试或者实践TDD经常被视为是开发工程师的工作，很少有测试工程师会参与其中，在我看来，这是一个错失的改进机会。
必须说明，TDD是一项设计活动。TDD中编写的单元测试用于指导开发人员的代码实现和组织，但是，需要写什么样的测试？此类信息从何而来？
需要编写的测试应该来源于之前和团队讨论过的需求。在实践TDD或编写UT时，测试和开发结对会产生巨大的价值。这是一个绝佳的机会来强化对需求的理解。当和开发人员结对时，可以了解到为什么会写那些测试，并且能保证测试代码和需求的匹配。
结对使不同角色都能产生价值，对测试工程师而言，我们能保持对用户视角和需求的关注，而对开发人员，可以更多深入到编码环节。
另一个好处是，在编码环节我们可以更多地考虑到可测试性。诚然，TDD实践是在单元测试层面上的可测，但是结对可以让我们有更多机会加强异常捕捉、响应格式化以至UI层的hook钩子等便于后续API、UI层自动化实现的需求。因为深入了解了细节，我们可以同时着手编写此类测试（API/UI，如果是开发编写这些测试，那么他们已经为他们自己完成了一个可测试的实现）
实践TDD的一个主要优点是我们会有一个包含大量测试的测试集并在每次代码提交时都可执行。通常单元测试会覆盖主要的正常路径，但对于那些边缘用例呢？
回到重置密码这个例子，如果有人希望使用之前用过的第5个密码，那应该是不允许的。但是我们的代码是否处理了这种偏移1位的场景？是否产生了正确的异常捕获？
这些都是测试人员能在TDD或UT中产生价值的例子，为何还要等到构建部署到测试环境再发现此类问题呢？但测试人员参与到这个环节，那么我们就能更早地发现问题，避免后期的返工。在开发环节越早进行探索性的测试越有助于产品的高质量。
发布后的工作
在DevOps环境下，只有产品被成功运行在生产环境上才能说发布完成。一旦完成发布，产品真正呈现在用户面前时，我们就可以开始了解用户是如何使用它的。研发阶段早期就应该考虑检测方式和手段，比如记录用户行为和数据的日志等，能让我们了解产品环境发生了什么。
我们需要确认用户使用的产品在以我们预期的方式运行。类似产品经理可以直接从客户那里得到反馈一样，我们也可以利用不同的监测工具来确保客户问题的解决。
作为测试，我们更多站在客户视角。监测工具使我们可以更容易观察产品的质量数据并确保产品正常运作（没有错误或问题得到解决）。当产品确实发生问题时，我们也能参与到告警生成工作中。
在现有大多数应用的复杂生态下，在产品环境中完成测试对很多团队已经非常必要。测试或预发布环境可以配置得和生产环境尽量一致，但每个环境终究是独有的，数据、环境中的行为甚至微小的配置差异。我们已经见过太多产品环境的bug在测试环境下无法发现的例子了。
尽可能多地在产品环境完成非破坏性的测试。基本的健康检查和UI检查是非常有用的，可以先运行这些检查直到团队有信心在产品环境运行更多的测试。让这些检查结果可以被团队全体都看到，使大家都能掌握系统的健康状态。
结论
在DevOps环境下，测试这个角色要体现在任何可以为团队产生价值的地方，参与到研发的任一环节，和团队全方位协作，在需求收集和单元测试阶段确保问题尽早发现。在发布后，通过监测工具确保产品是高质量的并为客户提供价值。
自然，自动化测试依然是极其重要的，特别是在复杂的解决方案中，它能使我们快速得到变更检查的反馈。但是除此之外，测试工程师还有更多其他途径来呈现价值，本文意在撷取要点述之一二。
