2022-23 世界质量报告(World Quality Report)

2202-23 世界质量报告(World Quality Report 简称 WQR)是一项全球研究,不论是作为软件测试、开发工程师,关注这类软件质量报告可以帮助我们快速了解软件行业的现状和趋势。

七个主题

今年的 WQR 的关键趋势和推荐包括包括以下七个关键建议:

  • 敏捷质量调配 (DONE)
  • 质量自动化 (DONE)
  • 测试基础设施测试和配置 (DONE)
  • 测试数据提供和数据验证 (WIP)
  • 质量和可持续的 IT (NOT START)
  • 新兴技术趋势的质量工程 (NOT START)
  • 价值流管理 (NOT START)

敏捷在组织中的质量调配

敏捷和 DevOps 已经存在了一段时间,它们仍在不断发展。它们的采用率每年都在增长,推动了高质量软件的交付方式。在在过去的十年中,随着敏捷实践,并将重点转向更新的实践、技术和趋势。在本章中,我们将探讨所有这些趋势。

自从你的组织采用 Agile/DevOps 以来,以下每个领域有多少改进

敏捷缩短了交付周期、 实现高质量软件且允许频繁部署。

1

敏捷和 DevOps 正在以多种方式影响组织。从调查结果可以清楚地看出,敏捷方法导致上市时间显着改善,并且提高驾驶时的软件质量和可预测性,同时改善客户体验。上图显示了组织的百分比经历了超过 20% 的改善自从他们采用以来提到的改进领域敏捷/开发运营。

准时交货、可预测性、改进客户体验和生产力提升是关键敏捷实践实施的结果。这使更好的客户体验,同时部署更快的版本。有趣的是,只有 54% 的受访者实现了业务驱动的更快发布目标,这意味着它应该获得更多关注。

你的团队在企业系统测试中使用下列质量和测试方法的频率如何?

2

企业系统的 “稳妥 “选择

在企业系统领域,敏捷流程的采用最近才刚刚开始。企业系统非常复杂,运行着关键的业务流程,因此在采用敏捷流程方面起步较晚。企业系统较晚采用敏捷流程的一个原因是,很难将端到端业务流程通常非常庞大的工作流程拆分成较小的块,以便在较短的开发冲刺阶段独立处理。

然而,在过去几年中,企业系统采用敏捷方法的情况出现了积极的转变,我们预计这种情况将继续下去。今年,我们调查了企业系统最主要的质量和测试方法。

今年,我们调查了企业系统采用的最主要的质量和测试方法。大多数团队(65%)使用特定软件包工具来实现自动化,63% 的团队使用预建测试用例库来认证冲刺,61% 的团队将测试集成为 CI/CD 管道中的自动质量关。

在成功执行敏捷开发项目时,以下质量保证技能有多重要?

3

全栈质量工程师的概念正在演变

今年的数据显示,敏捷 Scrum 团队中质量工程师的技术和跨职能技能融合程度有所提高。

上图显示,”采用工程思维”,同时 “掌握多种技能和提高技能 “正在成为新的规范。

业务领域知识和跨职能技能是今年超过 60% 的受访者认为最重要的两个项目。

质量工程师是敏捷团队的组成部分

今年的数据显示,敏捷Scrum团队中质量工程师的人数有所增加。

你们团队中专业质量工程师的比例是多少?

上图显示,平均而言,大多数 IT 组织的敏捷团队中质量工程师的比例低于 30%。有 28% 的组织的质量工程师比例高达 36-45%,有 20% 的组织的敏捷团队中质量工程师比例为 16-25%。

在敏捷企业中协调质量的关键建议

敏捷团队在很大程度上依赖于团队成员之间的有效协作和高效沟通。由于需求变化频繁,交付周期短,开发人员、业务分析师和质量工程师需要携手合作,共同完成发布任务。他们需要协作、接受 变化并快速适应。

在今年的调查中,我们发现了以下与敏捷质量协调相关的主要发现和最佳实践:

  • 灵活性、自主性和适应性是敏捷项目的关键团队特质。
  • 跨职能技能和业务知识对敏捷项目的成功至关重要。
  • 持续交付的速度要求更高水平的自动化和质量流程。
  • 敏捷/DevOps 需要更广泛的质量观,包括左移和右移。
  • 敏捷团队中的质量工程师正进一步向全栈质量工程师发展。这些工程师融合了丰富的技术和业务技能。这将继续发展,以满足敏捷环境所需的灵活性。

各组织应关注什么?

4

关于敏捷质量方法、流程和协调,我们有六项建议:

  • 让质量工程师成为敏捷开发项目不可或缺的一部分。合适的人才以及技术与业务技能的融合对于敏捷开发中的质量工程师至关重要。虽然 SDET 角色已成为常态,但业务领域知识也是一项基本技能。
  • 发展端到端测试自动化,通过自动化持续测试提高整个 CI/CD 流程的测试自动化水平,从而提高代码质量。这将提高产品质量,同时降低质量成本。
  • 确保自动化测试作为常规 CI 管道的一部分运行,这样它们就能很容易地与日常工作集成。
  • 随着企业主越来越多地参与测试活动,应确保他们拥有正确的工具和流程,以便有效地进行测试。
  • 针对企业系统使用特定的软件包工具,并利用适合敏捷方法使用的预建库提高自动化水平。
  • 跟踪和监控贯穿整个开发生命周期的整体质量指标。例如:部署失败指标可全面反映各团队的质量。

质量自动化

介绍

测试自动化已有几十年的历史,其工具也有了长足的发展。当我们从《世界质量报告》的角度来看待测试自动化时,我们会发现它大有可为的前景。然而,我们也看到,企业仍在在努力实现自动化。

企业在测试自动化方面面临的两个非常普遍的挑战:

  • 测试自动化并不总是自然而然地融入开发流程,而是作为一项独立的活动组织起来、独立于开发和测试本身。
  • 团队优先选择测试自动化工具,却忘记制定适当的测试自动化计划和策略。

要使测试自动化取得成功,至少需要良好的需求、合适的专家、合适的工具(通常不止一种工具工具)、稳定的测试环境和足够质量的测试数据。

如今,所有组织都需要适当水平的测试自动化,因为敏捷方法正在加快开发速度。
因此,测试需要更快地完成,但不应失去任何严谨性。简单地说,过多的手动测试将无法跟上开发的步伐。

决定测试自动化方法最重要的三个因素是什么?

5

我们询问了调查对象,什么是决定他们测试自动化方法的最重要因素。 我们本以为投资回报率(ROI)会高居榜首,但可维护性却名列前茅,这让我们欣喜地认识到,要想在自动化领域取得成功,就必须将其视为一种资产来加以维护和开发。

人们认识到,业务需求也是关键,同时还要适应需要测试的新技术–我们认为,部分原因是不断向云技术转变。

我们发现,大多数组织的首要任务是满足业务需求,而不是证明自动化的技术投资回报率,组织中的对话已经从测试工具的成本变成了它能为业务带来多少价值。

测试自动化团队没有很好地兑现承诺效益

令人失望的是,实现自动化预期效益的团队比例只有一半左右。甚至连 CI/CD 和自动化的整合也低于预期,尽管长期以来,敏捷实践推动了向 CI/CD 的转变。

你的团队中有多大比例的人目前从测试自动化中获得了以下好处?

6

为什么是这样?

这是工具的失败吗?开放源码工具和商业工具都是成熟的工具。它们的能力和局限性都是众所周知的–至少在每天使用它们的人当中是这样。从一些深入的后续访谈中可以看出,关于什么可以做,什么不可以做的沟通似乎仍未得到很好的管理,尤其是在寻求合理的投资回报时。将手动测试的百分比称为自动化测试的诱惑会让团队走上一条自动化的道路,而不考虑手动测试是否适合自动化并能带来价值。

关键问题是:您能确定解决方案的所有部分吗?即使您的团队实现了承诺的效益,但考虑到现代 IT 世界的全球性和云/应用程序接口互联世界的复杂性,有些部分可能会被忽视。

多年来,我们一直在研究测试自动化这一主题,但令人失望的是,企业仍在努力使测试自动化发挥作用。调查结果表明,拥有成熟敏捷流程的团队通常能从测试自动化活动中获得更多益处。这个信息很明确:正确的流程、明确的期望、良好的需求以及能够支持这些流程的团队,都能增加在现代世界中取得成功所需的收益。

自动化在哪些方面能为您带来最大效益?

自动化所能提供的远不止前端测试或单元测试中的下拉测试。多年来,单元测试和功能测试一直主导着自动化工作。

现在,由于需要加快构建速度、获取大量数据、构建环境和部署高质量代码,自动化解决方案为所有这些领域带来了价值。

在测试周期的哪些关键阶段,您目前能从测试自动化中获得最大收益?

盘点

低代码解决方案越来越受欢迎。开放源代码每周都有新工具问世。成熟的商业工具也在不断推出。这意味着,自动化工具包比以往任何时候都更加丰富和强大。我们可以从大量工具中看到这一点,这些工具利用人工智能和机器学习的爆炸式增长,为工具集带来了额外的价值、可用性和功能。

但有些看法需要加以解决。很多时候,人们认为自动化无法兑现其承诺。作为一个行业,我们需要解决自动化问题,因为它对于在现代世界中以我们所有人都需要的速度和质量交付成功至关重要。

组织应该关注什么?

通过研究,我们得出以下建议,以提高质量自动化计划的价值:

  • 尽早与质量自动化专家合作。
  • 在创建需求时就开始自动化;在需求和故事中构建自动化优先的方法。
  • 在开始自动化之前,先就自动化需求达成一致。
  • 关注什么能为客户和企业带来最大利益,而不是投资回报率。
  • 定期审查工具和框架。
  • 规划至少未来三年的路线图。
  • 一种工具不能包打天下。选择最适合工作的工具。不要试图让一种工具包办一切。
  • 投资于人。不要再追逐独角兽,要与你的员工合作,他们了解你的业务。

变革的好处不是立竿见影的。你必须留出时间,让变革在你的项目管道中进行,让思维方式得到调整和改变。当它们发生变化时,自动化就能实现它所承诺的价值 —— 不仅仅是一半时间,而是大部分时间!

最后一个想法:可持续发展是一个日益增长的重要趋势,不仅在 IT 领域,在所有领域都是如此。我们现在就需要开始思考自动化如何向世界展示其效益和成本。您知道自动化测试的碳足迹是多少吗?您还需要多久才能为您的组织报告碳足迹?现在是时候开始考虑如何以及如何做了,这样当有人提出这个问题时,您就已经做好了准备。

质量基础设施测试和供应

测试环境管理一直是《世界质量报告》调查的重要组成部分。
今年,我们分析了测试环境调配是如何调整的,以及非生产环境的云供应是如何起飞的。云测试是如何兴起的。
云测试在软件开发生命周期中占据越来越重要的位置。云测试在软件开发生命周期中占据了更重要的位置,因为越来越多的环境和云测试在软件开发生命周期中占据越来越重要的位置。在《世界质量报告》的本章中,我们将探讨云测试的现状和采用情况。

云测试环境配置

随着越来越多的工作负载迁移到云中,我们询问了企业在云中调配非生产环境的比例。
结果显示了明显的进步,但在这一领域仍有很长的路要走,因为近一半的企业只在云上配置了最多 25% 的非生产环境。总体而言,49% 的企业在云上部署了 50% 以上的非生产环境。

在云上配置的非生产环境的比例是多少

8

我们注意到非生产性工作负载正越来越多地转移到云中,因此我们还调查了非生产性环境的云平台策略。结果发现,许多企业(44%)目前使用混合(内部部署加单一云提供商)环境战略。约有 38% 的企业实施了多云战略。此外,平均 30% 的受访者已开始认真考虑将测试环境迁移到多企业内部(企业内部加多云提供商)模式。

这些数据表明,非生产环境向云的迁移远未结束。我们预计在非生产环境中采用多云、多内部部署战略的情况会越来越多,因为这些解决方案对灾难恢复、安全性和成本效率都有积极的影响。

你云平台配置非生产环境的策略是什么

9

测试环境配置自动化

将非生产环境迁移到云中的一大优势是,云解决方案能让测试环境的自动调配变得更加容易。我们调查了企业使用哪些工具来实现测试环境的自动配置。结果显示,不同的可用选项分布均匀。多达 41% 的受访者使用混合工具策略,其中既有现成的商用工具,也有开源选项。说到云原生工具或内部供应商构建的工具组合偏好,我们观察到的前景是相似的。

从这项分析中可以看出,企业还没有准备好把所有鸡蛋都放在同一个篮子里。因此,目前采取的是多种工具组合策略。我们看到,由于许多工具都是这一领域的新工具,因此企业在工具使用方面采取了一种平衡的方法。

你当前自动化端到端非生产环境配置的工具策略是什么?

10

云和基础设施测试

随着组织部署更多的环境进入云,我们也希望看到云测试在重要性。通过云测试,组织可以验证可扩展性、性能、安全性、可靠性、灾难恢复、环境的互操作性和多租户和云上的应用程序。迁移应用程序时到云,功能和非功能方面应用程序必须进行测试,以确保整体功能和性能保持所需。在我们今年的调查中,我们问如果组织将云和基础设施测试作为一部分他们的开发生命周期。结果表明,大约 96% 的所有受访者都提到现在包括云测试作为测试生命周期的一部分,57% 的人已经将云纳入其中对大多数项目进行测试,39% 的人声称已将其包含在内至少对于某些项目。

在将云测试功能纳入软件开发生命周期方面,这是一个积极的上升趋势。我们强烈建议继续保持这一趋势,并将云测试和基础设施测试作为生命周期的必经阶段。

你的组织是否将云和基础架构测试作为开发生命周期的一部分?

11

我们还询问了受访者云测试和基础设施测试包括哪些类型的项目。与往年相比,我们看到了一个重大转变,今年约有 40% 的受访者提到他们的所有项目现在都将云测试作为软件开发生命周期的一部分。约 27% 的受访者认为这只适用于云迁移项目。

这一趋势令人鼓舞,因为云计算和基础设施测试曾经是在数据中心典型的软件开发生命周期之外进行的一个阶段。

什么类型的项目(如果有)将云测试作为开发生命周期的一个组成部分?

12

我们将云测试视为一种将获得认可的趋势并在未来几年增加采用,我们是肯定会看到更多的组织订阅云和基础设施测试与往年相比。这甚至由于越来越多地采用云和更加关注潜在的安全和性能问题

云测试策略

如果云测试越来越重要,那么了解组织在定义云方面的成熟程度他们项目的测试策略也同样重要。在这项调查中发现云测试策略仍远未奏效,需要更成熟。整整一半(50%)的受访者提到他们的云测试策略只是有些有效,而 37% 的受访者提到它适度有效。

这一结果标志着云测试的整体概念和云测试的相关自动化还处于起步阶段在大多数组织中。这一观察的主要收获是组织应该紧急开始创建一个端到端的符合的云和基础设施测试策略组织的整体云采用战略。

你组织的端到端云测试策略的有效性如何?

13

云测试自动化

我们还调查了组织采取的方法走向云测试的自动化以及什么类型的他们用于云测试自动化的工具。大约 33% 的人受访者回答说:云测试工具是依据项目具体而决定的。目前相同比例 (33%) 的人更喜欢开源工具,而 31% 的人更喜欢云原生工具。

我们观察到跨组织的工具策略非常相似,这也表明没有哪一个工具或是策略是一枝独秀的,因此对于组织,所有选项(开源、现成、混合、等)均可考虑。

我们的建议,考虑到各种趋势,包括采用多前提云采用策略,组织应认真考虑集成商业现成的和开源的工具选项来解决各种云架构和项目特定需求,这还可以在跨项目中通过标准化减少工具 license 的支出。

你的云测试工具采用策略是什么

14

组织应该做什么专注于什么?

总体而言,我们看到围绕测试环境的积极趋势管理:

  • 越来越多的组织正在将测试环境迁移到云端,在多云或多前提模型中。
  • 组织使用混合工具集来实现自动化提供测试环境,包括云原生,商业现成的供应商或内部内置工具。

我们对测试环境的建议管理和配置如下:

  • 加快采用多场所(本地 + 多云提供商)测试环境的策略提高成本效率、安全性、冗余和数据恢复选项。
  • 考虑智能集成(包括自定义具体功能),以充分利用商业 off-the-shelf 和开源工具作为混合策略
    测试环境配置。
  • 进一步利用非生产转移的成本效益趋势通过高效的方式将工作负载转移到云端非生产环境的设计和架构。

在本章中,我们还讨论了积极的趋势到云的测试:

  • 大多数组织都将云测试视为一种软件开发生命周期的组成部分。
  • 与开源工具有很强的联系,尽管有其他选择,例如现成的商业工具也被用于云测试的自动化。

我们关于云测试的主要建议是下列:

  • 在所有项目中纳入云和基础设施测试策略。
  • 通过考虑所有云平台和集成环境架构,改进端到端云测试策略,以确保环境的性能、可扩展性和功能性。
  • 随着越来越多的数据托管到云上,与第三方云应用程序的集成也在增加,因此要更加关注安全测试。

测试数据供应和数据验证 (WIP)

介绍

测试数据提供是软件测试生命周期的重要组成部分。多年来,随着对数据的严格监管和安全要求的提高,组织对安全、可靠地提供测试数据的关注不断增加。在本章中,我们将探讨测试数据提供的现状和趋势。此外,由于我们认为数据使用的重要性不断增长,今年我们首次对数据验证这一主题进行了调查。

测试数据供应策略

今年我们调查了组织正在使用的测试数据提供策略。一个明显的结果是,许多组织(41%)仍然采用项目为中心的方法进行测试数据提供。令人鼓舞的是,31%的组织已经定义了企业范围的测试数据提供策略,但在有效实施上存在困难。只有20%的受访者表示他们已经完全实施了企业范围的测试数据提供策略。
组织需要查看其地区的当前数据法规,并加速创建端到端的企业范围测试数据提供策略。这也应该包括对数据安全的充分关注。

贵组织是否已在所有业务线/项目中采用企业级数据供应战略作为标准?

15

在云上部署测试数据

在今年的调查中,92%的受访者声称他们使用云来存储脱敏的测试数据。在云中拥有脱敏测试数据的黄金拷贝或仓库是确保测试数据按需可用的一大步。然而,更深入地探讨时,我们发现89%的受访者中有83%提到他们组织的政策是将所有测试数据保存在本地。对于83%的受访者,他们的云数据战略还在进行中。相当数量的组织(82%)提到他们要么使用安全的云平台来存储测试数据,要么将数据存储在云中,但不会保留很长时间(78%)。有数据显示,66%的组织正在合成生成存储在云中的数据。

使用在云中存储的脱敏和合成生成的测试数据是一个积极的趋势。然而,正确的方法始终将受特定项目需求驱动。我们推荐采用混合方法在云中部署测试数据。这可能是基于项目需求和测试数据敏感性的本地和云的组合。

请告诉我们您是否同意或不同意目前将脱敏测试数据部署到云存储库的以下方式

16

将测试数据提供给 CI/CD 管道

虽然组织在提供安全的按需测试数据方面有着先见之明,但测试数据管道与CI/CD(持续集成/持续交付)管道的整合仍然远未完成。在49%的组织中,测试数据提供的过程是自动化的,但这种自动化独立于整体的CI/CD管道自动化。对于42%的组织来说,手动提供测试数据仍然是将测试数据提供整合到CI/CD管道中的主要障碍之一。近三分之一(31%)的受访者认为将测试数据整合到CI/CD管道中经常被忽视。
从这一分析中得出的关键结论是,组织需要将自动化的测试数据提供视为持续集成和交付管道的一个组成部分。我们认为,与价值流管理相关的工具可以帮助将测试数据提供整合到CI/CD管道中。这种方法还有助于确保正确的测试数据被部署到云中的正确非生产环境。

贵组织在将测试数据的提供整合到持续集成和交付管道方面有哪些障碍?和交付管道的障碍是什么?

17


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」