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

栏目: 编程工具 · 发布时间: 5年前

内容简介:敏捷软件开发和 DevOps 除了强调用户体验,还让我们关注产品背后的人。但是这些过程重要吗? 或者只是为了证明方法是不是正确?自

本文关键点:

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

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

  • 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


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

面向模式的软件体系结构(卷1) (平装)

面向模式的软件体系结构(卷1) (平装)

Frank Buschmann、Regine meunier、Hans Rohnert、Peter Sommerlad、Michael Stal / 贲可荣、郭福亮 / 机械工业出版社 / 2003-1 / 45.0

一起来看看 《面向模式的软件体系结构(卷1) (平装)》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具