这篇文章分为两部分，探讨质量保证(QA) 在数字化转型时代如何发展。关键点包括：

　　1、数字化转型是一种文化转变，而不仅仅是技术升级

　　2、质量保证从感知瓶颈转变为战略推动因素

　　3、对 QA 的新期望：自动化、适应性和主动洞察

　　4、质量保证向跨职能团队和 T 型技能转变

　　5、质量保证专业人员在整个组织内建立影响力的策略

　　6、质量保证的未来趋势以及如何做好准备

　　我在科技行业工作了很长时间，亲眼目睹“数字化转型”从一个流行口号演变为一项关键的商业要务。但它在 2024 年到底意味着什么呢?

　　让我们从基础开始并建立一个基线：

　　数字化转型不仅仅是升级你的技术堆栈——它是对企业如何运作以及如何通过数字技术为客户提供价值的根本性重新构想。

　　在 2000 年代初期到 2010 年代中期，许多公司认为，只要将旧系统替换为更先进、更现代化的替代方案，就可以实现“转型”。但作为亲眼目睹这些转变的人，我可以告诉你，真正的转型远不止新软件。

　　随着 IT 行业的成熟和敏捷方法的势不可挡，我们逐渐认识到数字化转型主要是文化变革与技术升级相结合。数字化转型需要培养一种组织思维模式：

　　不断挑战现状、拥抱实验、接受失败作为创新的垫脚石

　　随着组织经历数字化转型，QA 既成为响应元素，适应新技术和方法，也成为驱动力量，塑造软件的构思、开发和交付方式。

　　在这篇文章中，我将更多地关注人的因素，而不是技术。

　　从外到内：工程界如何看待 QA

　　传统观点：QA 是瓶颈还是必要之恶

　　从历史上看，QA 一直被视为一个障碍。许多工程领导者将其视为发布前的最后一道障碍。QA 经常(通常是不公平的)被指责拖慢了开发速度。“如果没有 QA，我们可以更快地发布”，这是咖啡角里常见的闲话。

　　量化 QA 的价值带来了挑战。与功能开发不同，QA 的影响并不是立即可见的。怀疑论者很难超越错误数量和无限大的测试集。这种看法导致了紧张局势。QA 团队感到被低估了。开发人员将 QA 视为需要克服的障碍，而不是创作的合作伙伴。

　　质量保证观念的演变：从成本中心到价值创造者

　　数字化转型(以及组织拥抱敏捷性)正在改变这些观点。工程团队认识到 QA 的战略重要性，并开始将 QA 视为盟友，而不是对手。

　　许多工程领导者现在也认识到 QA 是一项关键技能，与分析或编码一样重要(有时并没有他们需要的那么大声)。

　　数字化转型本质上往往成本高昂、复杂度高。在这样的环境中，失败(和延迟)的成本很高。虽然几乎每个人都同意在开发环境中修复错误比在生产环境中修复错误要便宜得多，但大多数工程主管并不欣赏 QA 在实际工作中的作用。

　　然而，随着世界发展速度加快，产品质量已成为一个差异化因素，工程领导者不再能够将 QA 推到一边(或推到流程的最后)。

　　QA 参与开发过程的早期阶段。然而，这种额外的影响并非毫无意义，QA 团队现在必须满足不同的期望。

　　200 多万开发人员和 QA 依赖 LambdaTest

　　利用下一代移动应用程序和跨浏览器测试云提供沉浸式数字体验

　　使用 Google 注册使用电子邮件注册数字化转型中对 QA 的期望

　　虽然 QA 在决策层中占据了一席之地，但期望也在不断变化。QA 领导者也有望成为思想领袖，帮助推动软件工程的发展。阅读此博客了解更多信息：数字化转型质量的重要性

　　数字化转型的步伐也要求不断演进，QA 也有望跟上步伐。更快、更高效的测试流程现已成为常态。

　　QA 专业人员应该期待以下变化的一些领域，这不是一个详尽的清单，而是一个谈话的开始。

　　自动化不再是可选项：工程师希望 QA 能够利用自动化测试工具。这有助于加快反馈循环并提高测试覆盖率。此外，如果没有巧妙的自动化(和回归测试)策略，增量范围的更快交付根本行不通。

　　适应性至关重要： QA 专业人员必须了解并适应新技术。云计算、人工智能、物联网 — QA 需要精通测试这些复杂的系统。所有行业都在合并(或发展)为科技行业，而技术的融合不断突破传统上被视为“测试”的界限。

　　主动的质量洞察是新的目标：被动地查找错误是不够的。工程师希望 QA 能够在问题发生之前预测到潜在问题。这需要对产品及其生态系统有深入的了解。例如，QA 团队可以使用 LambdaTest Test Intelligence等工具来预测和缓解未来问题，避免问题扎根。

　　需要数据驱动的决策： QA 必须提供有意义的指标和见解。这些有助于就产品准备情况和发布时间做出明智的决策。延迟的成本可能很大，但投入生产后失败的成本可能是无法容忍的——这就是 QA 专业人员需要帮助组织做出平衡决策的地方。

　　DevOps 环境中的持续测试正在成为标准： QA 有望无缝集成到 CI/CD 管道中。这可确保开发每个阶段的质量。QA 专业人员需要考虑从设计到部署，而不仅仅是 QA 阶段。

　　这些都是伟大的期望，但它们如何变成现实呢?让我们更深入地探讨 QA 社区在哪些方面需要进行自我转变。

　　转变 QA 团队结构

　　随着数字化转型对 QA 的期望不断变化，QA 团队的结构和能力也必须不断改进。从传统的测试角色转变为战略质量推动者需要从根本上改变 QA 团队的运作方式。让我们来探索转型的关键领域。

　　由于组织在大规模转型中采用更敏捷的交付模式，孤立的 QA 团队时代正在逐渐消逝。根据定义，敏捷模型重申需要拥有跨职能团队，以便在同一团队内处理从设计到部署的所有事务。

　　虽然我们并不要求每个团队成员都精通所有技能，但每个人都应该成为某一领域的专家，并在另一个领域为团队做出贡献。当然，这也意味着 QA 专业人员现在需要具备 T 型技能：深厚的测试专业知识以及跨开发、运营和业务领域的广泛知识。

　　跨职能团队(QA 与开发和运营并肩工作)正在成为常态。这种密切关系促进了更快的反馈循环、更快的问题解决以及对质量的共同责任。QA 参与代码审查、冲刺规划和部署策略等活动已不再是例外，而是预期。

　　T 型 QA 工程师还充当学科之间的桥梁。他们可以有效地与开发人员沟通代码，与运营部门讨论部署策略，并将技术问题转化为利益相关者的业务影响。这种多才多艺不仅是一种优势，也是一种要求。

　　深入了解QA 和 SDET角色的演变：

　　质量保证 (QA) 作为顾问和推动者：日常生活中的一天

　　QA 的角色正在从守门人转变为质量倡导者和推动者。希望我之前已经说服了你。但你问我——这在实践中意味着什么?如果我采用这种工作方式，我的生活明天会发生怎样的变化?

　　让我们来看看担任这一新顾问角色的 QA 专业人员的典型一天(这些是一些启发性的例子，请停下来思考一下在您的日常生活中可以应用这种思维方式的情况)。

　　晨间站立会议：您正在积极讨论新功能对质量的影响。例如：“我已经审查了新的结帐流程。我们是否考虑过它如何处理多种货币?我可以与开发人员合作为此创建测试场景。”

　　需求审查：您正在与产品经理合作制定验收标准。例如：“对于新的搜索功能，让我们添加性能标准。‘95% 的查询结果应在 2 秒内加载’怎么样?”

　　设计会议：您提供有关设计选择如何影响可测试性的意见。例如：“如果我们模块化此组件，我们就可以轻松地在自动化测试中模拟其依赖项，从而使其更可靠且运行速度更快。”

　　结对编程会议：您正在与开发人员结对，帮助编写单元测试。示例：“让我们编写一个测试，用于测试 API 何时返回空响应。这将帮助我们更优雅地处理边缘情况。”

　　CI/CD 管道审查：您建议在管道中添加新的自动检查。示例：“我们可以在这里添加静态代码分析步骤。它可以在代码审查之前发现潜在的安全漏洞。”

　　创建指标仪表板：您正在构建一个仪表板，将技术质量指标转化为业务影响。示例：“此图表显示了我们改进的测试覆盖率与上一季度客户报告的错误减少 30% 之间的关系。”

　　辅导课程：您正在举办一场关于左移测试实践的研讨会。示例：“今天，我们将练习编写可测试的用户故事。这将帮助我们尽早发现歧义并减少开发过程中的反复。”

　　生产问题分析：您正在深入研究生产问题，并建议更改测试策略。例如：“此次中断是由数据迁移中的极端情况引起的。让我们为迁移场景添加一个特定的测试套件，以防止将来再次发生这种情况。”

　　在这个新角色中，您不再只是发现错误，而是要预防错误。您不仅要执行测试，还要塑造整个组织对质量的认知和实现方式。在开发的每个阶段，您的专业知识都备受追捧，您正在推动一种让质量真正成为每个人的责任的文化。

　　这种转变需要改变思维方式和技能。您需要培养更强的沟通技巧，深化整个堆栈的技术知识，并培养在没有直接权力的情况下施加影响的能力。但您对产品质量和团队效率的影响将是变革性的。

       卓码软件测评是一家[ 具备CMA、CNAS双重资质 ]的专业做软件测试的第三方软件测试服务机构, 可根据您的需求提供各类软件测试服务，并出具合格有效的软件测试报告。点击→→可了解测试报价

        部分文字、图片来自网络，如涉及侵权，请及时与我们联系，我们会在第一时间删除或处理侵权内容。负责人：曾菲       电话：4006070568