在许多大型组织中，软件质量主要被视为测试团队的责任。当错误溜到生产中，或者产品无法满足客户的期望时，测试人员就是罪魁祸首。然而，仔细观察，质量——同样，失败——远远超出了任何一个学科。

        质量是整个组织共同承担的责任。当出现质量问题时，根本原因很少是仅靠测试可以预防的。通常，存在沟通中断、不切实际的截止日期、设计规范不足、培训不足或公司治理政策，这些都激励了匆忙。

        换句话说，质量失败往往源于更广泛的组织和领导失败。将系统性问题的测试人员作为替罪羊会适得其反。它掩盖了真正的问题，阻碍了对质量缺陷的有意义的解决方案。

隔离测试

        在实践中，测试团队仍然与产品开发生命周期的其余部分隔离开来。他们最后被带进来，得到有限的信息，并被要求验证别人的工作。在这种情况下，它们防止缺陷的能力受到严重限制。

        例如，如果无法访问产品需求文档，测试用例可能会忽略需要验证的关键功能。由于测试时间较短，广泛的测试覆盖范围进一步变得不可能。如果没有对设计决策的深入了解或与开发人员的联系，在测试中发现的一些缺陷就无法有效诊断。

如果软件质量是每个人的责任，那么失败也是每个人的责任_测试人员

当修复缺陷的时间和成本变得不可行时，测试人员通常会空降。

在这种孤立的模型中，测试只不过是发布前的最终安全检查。质量的负担几乎完全转嫁给了测试人员。当不可避免的错误仍然溜走时，测试人员就会很容易成为替罪羊。

谁拥有软件质量？

事实上，产品质量的责任是在整个组织中分配的。那么，你能做些什么呢？

如果软件质量是每个人的责任，那么失败也是每个人的责任_测试人员_02

  • 高管和领导团队 — 围绕质量设定基调和政策，适当地平衡质量与成本和进度等其他优先事项。同时，提供成熟的测试工作所需的人员、资源和时间范围。
  • 产品经理 — 收集用户需求，定义预期功能，并支持测试计划。
  • 开发人员 — 遵循安全编码实践，执行单元测试，启用自动化测试，并对测试中发现的缺陷做出响应。
  • 用户体验设计师 — 在 UX 设计过程中考虑质量和可测试性。对原型进行用户验收测试。
  • 信息安全 — 对代码、体系结构和配置进行安全审查。指导与测试相关的安全用例。
  • 测试人员 — 根据用户情景开发测试用例，执行测试，记录缺陷，执行回归测试修复，并向利益相关者报告质量。
  • 运营 — 在部署后监控系统，收集生产问题并报告数据，以便为未来的测试提供信息。
  • 客户 — 表达您的真实质量期望，参与 UAT，并在发布后报告实际问题。

由此可见，没有一个职能领域只拥有质量。测试人员贡献了必要的验证，但质量确实是每个人的责任。

导致质量失败

        在 2023 年的“你为什么不测试”播客中，Marcus Merrell、Huw Price 和我讨论了测试如何仍然被视为“清洁”工作和成本中心，以及如何使测试和质量保持一致。

        当组织未能承认软件质量的共享所有权时，就会出现治理问题，从而导致质量失败：

  • 不切实际的最后期限 — 试图实现过于激进的时间表通常以牺牲质量和足够的测试时间表为代价。领导团队必须在市场需求与发布准备之间取得平衡。
  • 投资不足 — 成功需要为影响质量的所有领域配备适当的人员和支持。这些范围从设计和开发到开发再到测试。投资不足会导致不健康的权衡。
  • 缺乏协作 — 跨职能协调比各自为政的工作质量更好。治理策略应促进产品团队之间的协作，而不是阻碍协作。
  • 错位的优先事项 — 领导层应该激励平衡交付，而不仅仅是速度或成本节约。质量不能是别人的问题。
  • 缺乏透明度 — 进度报告应包含真正的质量指标。掩埋或掩盖缺陷会破坏治理。
  • 缺乏风险管理 — 通过适当的行动来识别和减轻质量风险需要项目领导层的关注。缺乏风险透明度会妨碍适当的治理。

        当这些治理崩溃发生时，质量就会受到影响，失败就会随之而来。然而，根本原因可以追溯到组织领导力和文化，而不仅仅是测试功能。

掩盖系统性问题的代价

将系统性组织问题导致的失败归咎于测试人员会导致巨大的成本：

  • 失去信任 — 当测试人员成为替罪羊时，它会削弱测试职能部门的可信度和信任度，抑制他们倡导产品质量的能力。
  • 员工流动率 — 当更广泛的组织未能认识到他们的贡献和价值时，测试团队会经历更高的人员流动率。
  • 较少的协作 — 其他团队避免与被视为瓶颈或障碍的测试人员而不是合作伙伴进行协作。
  • 重新发明轮子——从过去的治理崩溃中吸取的教训没有吸取，导致这些问题以新的形式重新浮出水面。
  • 较差的客户体验 — 最终，模糊质量方面的治理问题会导致更负面的客户体验，从而损害组织的声誉和底线。

掌握软件质量

        将质量提升为整个组织的责任对于治理、透明度和风险管理至关重要。质量不能成为单一职能的负担，领导层应该培养一种从本质上重视质量的文化，而不是将其视为事后的想法或复选框。

        为了建立所有权，组织需要将测试转移到上游，将其更早地集成到需求规划、设计评审和开发流程中。它还需要对测试实践本身进行现代化改造，利用所有可用的创新：从测试自动化、左移测试和服务虚拟化，到基于风险的测试用例生成、建模和生成式 AI。

        通过对谁拥有质量的共同理解，治理策略可以更好地平衡围绕成本、进度、功能和发布准备情况的竞争需求。测试见解将为更明智的权衡提供信息，避免质量故障和今天随之而来的指责。

        这种未来状态降低了失败的可能性，但也承认尽管尽了最大努力，一些失败仍然会发生。在这些情况下，组织必须有一个治理模型，以透明地识别跨团队的根本原因，从中学习，并防止再次发生。

        在本质上重视质量的文化中，软件测试人员赢得了值得信赖的顾问的地位，而不是沦为挑剔者。他们可以对其他团队的工作进行监督和验证，而不必担心遭到强烈反对。他们的专业知识将加强而不是威胁到协作交付。

        有了共同所有权，质量就不再是“测试人员的问题”了。它成为一种组织价值，可以赢得跨职能领域的支持。领导力为人们的理解定下了基调，如果质量是每个人的责任，那么失败也是如此。