到底谁应该对软件开发的质量负责？

本文关键点：

• 随着软件开发越来越追求质量，每个团队成员都要为质量负责。

• 质量的定义不再仅仅有正常运行时间和可靠性，有了供用户选择的各个方面。

• David A. Garvin 1984 年的《定义质量的五种方法》将质量定义为卓越的质量、基于价值的质量、基于用户的质量、基于产品的质量和基于制造的质量。

• 除了基于制造的质量之外，大多数类型的质量是不可测量的，但是团队又必须要考虑它，并且常常要直接与用户一起来做这件事。

• 行为驱动的设计(BDD)是一种在编写代码之前规划用户旅程和测试用例的方法。

敏捷软件开发和 DevOps 除了强调用户体验，还让我们关注产品背后的人。但是这些过程重要吗?或者只是为了证明方法是不是正确？伦敦P3X（或People, Product, and Process Exchange ）非常关注这三个 P 的交集，也许最后一个 X 是最有趣的，因为它凝聚了更多的缩写，比如测试驱动开发(TDD)、行为驱动开发(BDD)、持续交付(CD)、领域驱动开发(DDD)等等，以帮助团队审视如何系统性地建立更好的系统。

Janet Gregory 是敏捷测试协会的联合创始人，近期她完成了一场主题演讲，主题是关于追求软件质量的过程，在演讲结尾，她问大家是否感受到敏捷团队的魔力，如果能感受到他们在传递质量意识，举手示意。结果整个房间里，大概只有几个敏捷实践者举起了手。

自敏捷宣言签署以来，已经走过了这 17 个年头，我们是怎样过来的，为什么仍有一些人看它如镜花水月一般？也许我们仍然没有进行正确的交流，也许我们没有和合适的人在一起协作，或者我们的过程中根本就不包括交流。

尽管这份宣言将个人和交互置于流程和工具之上，但流程中的某些内容也是以人为本的。也许通过审视我们的过程，我们可以更好地响应变化，增加协作，减少 bug，所有这些都是为了尽早和经常地满足客户。Gregory 拿出一个世代相传的质量方法，将其应用于现代敏捷软件团队，希望每个人都能对发布的内容有主人翁的精神。

究竟什么是“质量”

Gregory 指出，必须先为质量给出主观定义。她引用David A. Garvin在 1984 年提出的“定义质量的五种方法”，以这种方法开始为质量下定义：

• 卓越的质量：氛围，天生的卓越气质，举世公认的成就

• 基于价值的质量：价格和成本

• 基于用户的质量：对某些人（一考虑质量大多数人就会想到的那些人）的价值

• 基于产品的质量：你的用户在寻求什么?(比如你提供的牛奶)

• 基于制造的质量：实践、过程、标准、要求、规范，我们做得对么？

Gregory 将每个类别的重要性进行了可视化，并将其应用到现代敏捷环境中。如下图所示，从最必要的中心向外辐射。

基于制造的质量

首先，有件事得顺利开展下去，因此基于制造的质量必须在第一位。

Gregory 说，这与测试驱动设计有关，因为“通过创建清晰的代码，可以显著减少返工”。

让我们第一次就把事情做对，使我们不会有其他的缺陷，可以满怀信心地发布。

TDD，这是一个在软件测试之前先设计自动化测试的实践，它倒推迫使软件解耦，是制造质量的重要组成部分。Gregory 引用了一项研究成果，该研究指出，与不进行 TDD 的团队相比，进行 TDD 的团队会少 60%到 90%的缺陷，但是 TDD 平均用时要多花 15%到 30%。

许多团队都在面对这种质量和速度的权衡。

“也许 PO(产品负责人)说，与提高质量相比，我宁愿你加入新功能。是谁，正在做出这些决定?”

Gregory 说，除了 TDD，基于制造的流程还包括：

• 针对可维护性的编码

• 针对错误日志的监控

• 持续集成

• 在故事上开展探索式测试

• 验证产品是否符合规格的测试

• 为快速反馈而创建自动化测试

• 平台的静态分析

• 明确定义完成标准

最后，她说，“像 DevOps 之类的实践是在设法在向客户发布产品时降低给客户带来的风险。”

基于产品的质量

简单来说，如果基于制造的质量是为了确保某些事正常开展，那么基于产品的质量则是为了确保产品按预期正常工作。例如，我们希望付钱追求更高的品质，但如果虽然某样东西坏了，但它的成本很低甚至为零，我们也会更宽容。如果有例外，那可能是我们通常期望的又能免费而又能工作良好的应用程序。

Gregory 指出，什么是基于产品的质量，这取决于目标受众。会计人员会希望键盘托盘能从当今大多数笔记本电脑中分离出来。

这其实是在问这样的问题：

• 我们打造的是正确的东西吗?

• 我们加入了我们想要的功能吗?

这包括：

• 验收测试驱动开发(ATDD)，有时也称为故事测试驱动开发，它是将关键客户引入到 TDD 阶段

• 安全性测试

• Bug bashes——就像一个团队黑客马拉松，寻找尽可能多的 Bug

• 持续交付

• 特征的探索式测试

• Beta 版本

• 性能测试

• 负载测试

基于用户的质量

对于这个观点，存在的分歧最大。按照 Gregory 的说法是：“人各有所好，不同的人有不同的选择。他们有不同的需求。如果我们想让顾客选择，就让顾客满意。”

但别忘了，她接着说，“我们假设了一个大前提，那就是消费者掌握足够的信息，他们可以做出一个合格的决定。”

她提到一款曾经使用过的应用，自己觉得它非常不友好。事实证明，用户喜欢它的原因，是因为它完全遵循了他们的工作方式。她并不在那个领域工作。所有都是为了满足特定用户的特定用例。

基于价值的质量

这很简单，这就是人们愿意为之买单的东西。价值很难判断，如果不与潜在客户交流，基本上不可能做出判断。

基于价值的质量可以通过以下几种方法进行评估：

• 有效性

• 效率

• 舒适度

• 信心

• 复杂性

• 环境适应性

卓越的质量

最后是最难以评估的质量——卓越。Gregory 说，这是因为情感是最难度量的，这种评估要把卓越的质量与艺术性、参与度和客户忠诚度结合起来。

我们如何度量软件的质量?

总的来说，如果您接受 Garvin 的质量级别，那么软件质量的大部分内容都很难度量。她引用了Isabel Evans 在《软件质量度量》一书中的说法。基于制造的质量有很多例子：

• 生产环境中的缺陷数量

• 生产环境中的缺陷的严重性

• 从上次发布到生产环境至今的天数

• 自上次发布生产环境的 X 天内获得的新支持票数

• 构建发射源总保持绿色

• 没有古怪的自动化测试(随机性的失败)

• 代码库的静态代码分析结果是健康的

• 返工率很低

• bug 不会重复出现

你还可以做做用户满意度调查，以这种形式度量基于用户的质量。

然而，你无法真正度量基于产品的、基于价值的或卓越的质量。但是，您可以讨论和评估质量的所有五个层次。测试是度量质量的重要手段，但 Gregory 提醒说，产品团队不能否定在彼此之间、与用户以及与竞争对手讨论质量的价值。

当然，团队需要在希望避免错误和追求速度之间找到平衡。

整个团队对质量负责

很清楚的一点是，质量保证不仅仅是测试部门的责任，开发人员不能把代码丢给他们就算了，或者质量保证这种叫法本身就有点问题。

整个团队都在把控质量

“如果你的组织、你的公司以质量为出发点，很可能就会取得成功，因为其他一切都很到位。一切都很正常。但是如果你们一开始认为速度最重要，不关注质量，那么就很有可能长期进行大量的返工，会出现很多不可维护的代码，质量将更进一步地下降”Gregory 说。

但她并没有提供一个追求品质的完美秘方。

“不管你用定性的还是定量的，那没所谓，但你得问问自己，你在寻求什么，它能让你满怀信心地发布吗？”Gregory 说。

“度量过程的质量就是度量产品的质量吗?”她引用了《BDD Book 1： Discovery 》的合著者 Seb Rose 的话：“当度量成为目标时，那么它就不再是好的度量了。”

Gregory 说：“无论你如何度量它，它都应该引发一场讨论，看看你们到底需要什么。”

她继续说：“团队掌控着质量，但你们必须考虑得更长远一些。过程中的质量和实践中的质量。

你的团队的能力，你如何交付软件的能力。

她最后说，在这个方向上展开每次对话时，如果大家都从试图解决问题开始，那是最好的了。

Gregory 说：“让我们将质量管理纳入我们的流程，并学会谈论我们做什么。”

关于作者

Jennifer Riggins 目前居住在伦敦，是一名科技故事讲述者和作家，在故事里，数字转型与文化交汇，希望能让世界变得更美好。你可以在推特上关注她@jkriggins。

敏捷测试协会的联合创始人 Janet Gregory 花了 14 年的时间帮助团队过渡到敏捷软件开发环境，她专门帮助测试人员和业务人员理解他们是“整个团队方法”的一部分角色。

查看英文原文： Who is in Charge of Quality in Software Development