我写质量工程是有原因的。虽然我经常提到软件测试，但很少使用术语“质量保证”ーー这是有意为之。如果你想知道为什么，那是因为我的经验表明，我们使用的语言决定了我们如何工作，如何理解我们的角色。
在我上一份工作中，有一场关于术语的持续辩论ーー在我们的团队之外，我们经常被称为 QA，而我们更喜欢被称为 QE。为什么？因为我们认识到我们的价值来自于在整个过程中提高质量，而不仅仅是在最后确保质量。让我来解释一下为什么术语和思维方式的这种转变很重要。
让我们从一些定义开始。
- 软件测试是直截了当的: 它包括任何旨在验证软件或特定功能是否按预期工作的活动。这可能涉及手动、自动、探索性或特别测试、 UAT 等。测试不仅限于测试人员、开发人员(通过 TDD、单元测试等)、产品经理、项目经理，甚至 CEO 都可以参与。在某些情况下，用户被认为是测试人员，特别是当他们是第一个在代码中导航特定路径的时候。
-
质量保证来自制造业背景，通常可与质量控制互换。随着时间的推移，QA 已经成为软件测试及其相关角色的代表。两者之间的关键区别在于，QA 通常指的是特定的角色或阶段，而测试指的是任何人都可以做的活动。
-
作为一个角色，QA 通常是一个独立于开发人员角色的角色，通常在不同的团队中。
- 它也可能指 SDLC 中的一个单独的阶段，比如开发→ QA →发布。在这种情况下，QA 是在发布周期的末尾完成的，可以看作是一个看门人或瓶颈活动。
- 质量保证的一个小小的重新架构带给我们质量协助。这包括向左转移测试，使测试人员和开发人员之间能够进行更多的协作，以及对质量和测试的更全面的看法。
- 质量工程作为一个总括性的术语，涵盖了整个公司对质量和测试的文化和态度，包括过程、最佳实践、指标和 KPI。质量保证的目的是从头到尾保证质量，而不是最终确保质量。
术语为何重要
我们使用的术语定义角色、形成认知，并影响工作的结构和执行方式。让我们来看看术语影响公司质量方法的几个关键方面。
- 限制质量活动和范围
当一个组织将 QA 作为一个单独的团队来构建时，质量活动可能会变得孤立。这种设置可能无意中限制了质量工作的范围，因为它表明质量是特定团队的责任，而不是整个组织的共同责任。这种分离也会产生瓶颈，因为 QA 团队成为了质量的看门人而不是推动者。
- 影响公司文化
术语直接影响公司文化。当我们谈论质量保证时，它可能意味着一种被动的方法ーー只有在事后才确保质量。另一方面，质量工程建议采取更加积极主动的态度，质量被建立在开发过程的每个阶段。从 QA 向 QE 的转变鼓励了一种每个人ーー开发人员、测试人员和产品经理ーー都对质量负责的文化。这种转变促进了协作、持续改进和更全面的产品开发方法。
- 单元测试、代码检查工具和其他实践的落脚点是什么？
像单元测试和静态程序分析测试这样的实践常常超出了传统的质量保证的范围。这些被看作是开发人员的责任，可以创建另一个竖井。然而，在质量工程框架下，这些实践对于从头到尾确保质量是不可或缺的。它们代表了测试中的左移，即质量检查嵌入到整个开发周期中，从编写第一行代码到部署最终产品。
通过将术语和思维方式从 QA 转向 QE，我们不仅仅是在玩文字游戏; 我们正在重新定义构建高质量软件意味着什么。这种转变反映了对卓越的更深层次的承诺，其中质量不是事后才考虑的问题，而是整个开发过程不可或缺的一部分。这是关于从看门人到质量促进者的转变，培育一种每个人都有责任提供尽可能好的产品的文化。这种术语上的演变不仅提高了产品质量，而且使整个组织围绕着一个共同的卓越愿景——一个从我们如何定义我们的角色开始，到我们交付的软件结束的愿景。
