传统测试被认为是SDLC中的一个瓶颈，它会导致交付延迟。长期以来，各组织都采用了敏捷/DevOps模型，但并非没有它的陷阱和绊脚石，特别是在实现理想的速度/质量平衡方面。
对于企业DevOps来说，重新考虑测试方法以实现规模上的敏捷性至关重要。角色之间有很大的重叠，例如业务分析人员和QA测试人员之间的角色重叠。是测试人员的角色减少是因为是因为这种重叠还是因为自动化？
由于每个组织都是独一无二的，在DevOps的采用方面有自己的期望和挑战，因此在DevOps中没有测试的断断续续的方法。相反，确实有一些广泛认可的使用多工具DevOps管道进行持续测试和取得最佳结果的最佳实践。
让我们深入探讨在DevOps中进行测试的现实：
Qa挑战
在瀑布式进场，QA团队获得部署在指定环境中的构建。然后测试员启动功能测试和回归测试。在团队签署该构建之前，构建将在团队中保留几天。
DevOps方式
测试员现在，他们的测试工作与CI/CD中的开发团队保持一致。该团队确保所有适合自动化的测试用例都是自动化的，并实现最佳覆盖。环境是标准化的，QA盒上的部署是自动化的。
另外，所有的预测试任务，和后测试任务也是自动化的，并与CI周期保持一致.
DevOps需要在交付链的功能之间进行高度的协作。这就模糊了这个链中参与者的许多角色之间的界限。最重要的是，每个人都必须为这一链条作出贡献。因此，业务分析师可以对QA流程做出重大贡献。部署工程师可以将测试用例添加到存储库，QA工程师可以配置自动化。
你能取消QA角色吗？
虽然每个人都能为建立更高质量的产品做出贡献，但没有人能完全取代QA角色。QAS对DevOps至关重要是有原因的。这里有一个角色，重点关注所有不同的测试策略和总体测试设计。有一个专门的QA工程师或团队使您能够全面地测试并涵盖测试的所有方面。手动回归功能, 探索性测试、性能测试、自动化测试等。
DevOps的理想开发/测试组合是什么？
为DevOps选择理想的dev/Team测试方法：
因为链条上的每个人都有责任为这个交付品的质量和及时性，DevOps测试策略不会除非全队都参与。
例如，要实现每个拉请求和代码更改的规模自动化:
- 让业务测试人员利用无代码测试自动化执行手动和探索性测试。
包括软件开发商如测试SDET使用框架设计功能性和非功能性测试自动化脚本。
- 开发人员还可以创建单元测试和构建验收测试。
- 质量保证和开发需要协作和识别受特定构建影响的领域，并执行相关的测试用例，此外还要通过一张健全的测试通行证。
- 配置代码是很重要的。分析和覆盖工具到确保最大限度代码覆盖。
腾出时间进行手工/探索性测试
有一个特定的期望，即DevOps允许每周、每天甚至几次部署代码。手工测试或探索性测试适合于这个节奏吗？
理想的做法是测试较小的代码更改，并允许测试人员使用工具在自己的环境中验证这些更改，并使用特性标志。理想情况下，手动测试应该在某种程度上发生在每个小的代码更改上。在不影响时间表和敏捷性的情况下实现这一目标的最佳方法是围绕自动化测试可能错过的内容确定有针对性的测试。
可以在生产前级别或集成级别环境上进行探索性测试，也可以使用功能标志来防止破坏生产经验。
使用正确的测试管理工具
测试管理工具通过让DevOps团队协作并加速高质量软件的发布，在测试成功中发挥着至关重要的作用。正确的工具在DevOps工具链中提供了与您的项目管理、问题跟踪和自动化工具的高级集成。
T“DevOps”中事物的连续性有时引向 a缺乏透明度和可见度。使用质量分析、报告小工具和仪表板可以使关键团队成员和涉众能够密切监视进度，即使在测试量增加时也是如此。从这些数据中获得的可采取行动的洞察力和情报帮助缩短反馈回路，并提供质量的实时可见度.
每个人都必须适应
人们普遍认为，在新的范式中，测试人员和QA必须进行调整。正如质量必须从独立的功能调整到整个开发链的组成部分一样，其他功能也是如此。
同时，DevOps中的测试需要一个更分布式的、协商性的测试专家模型。这意味着新QA的作用更少的事务性和更具战略性，尽可能在SDLC中增加最大的价值。测试人员现在是有关测试和质量的高层决策的顾问。一种理想的方法是将QA直接嵌入sprint或Scrum团队，并创建一个英才中心或咨询小组，就具体的和战略性的质量问题提供建议。
在DevOps和敏捷时代，您不能接近测试在……里面一种传统的方式。为了为企业DevOps充分扩展和加速QA，业务需要重新考虑它们的总体测试目标和结果。
