终极反馈环:从客户上报的缺陷中学习

发表于:2017-7-27 11:01

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Emanuil Slavov    来源:InfoQ

分享:
  主要结论
  详细分析最昂贵的Bug可以帮助公司节约时间、金钱和资源。
  所收集的数据有助于对软件开发领域普遍认同的教条提出质疑。
  在服务导向的架构中,集成测试能揭露出远多于单元测试的缺陷。
  大部分缺陷往往集中在少量可轻松辨别的功能中。
  简单的措施即可大幅减少最终用户可能遇到的缺陷数量。
  由客户发现的软件缺陷往往是最昂贵的。很多人从事有关软件缺陷的调试(往往难以在生产环境中进行)、修复和测试工作,所有这些人需要领薪水,需要与新功能的开发工作争夺时间和资源。客户上报的缺陷往往还会让组织陷入窘境,毕竟组织内部的所有措施都没能成功发现它们。这也难怪软件维护成本通常会占到整个项目成本的40%-80%之间(根据一些研究,甚至可能高达90%: 如何节约软件维护成本 ),而这些成本中很大一部分都用在与缺陷修复有关的工作中。修复一个Bug的准确成本很容易计算,但所造成的声誉损失往往难以衡量。客户可能因为糟糕的质量而不推荐某个应用,或弃之不用。
  我们面临的情况
  大部分公司并没有探究造成任何缺陷的根本原因(哪怕最昂贵的缺陷)。Komfo的做法则截然不同。我们认为缺陷是开展业务不可避免会产生的成本,从不就此产生质疑,也不会试图解决这种问题。因为我们找不到任何与客户上报的缺陷有关的行业数据来建立初始基准,我们只想知道自己所处的位置。
  有这样的一个例子:我们的客户可以通过多种渠道上报缺陷:邮件、电话、社交媒体。在我们接到的所有报告中,仅12%最终对代码进行了实际的Bug修复,另外88%只是出于其他方面的原因而引起了我们的关注,也许我们的产品使用体验不够直观,或者我们的客户需要更多培训。只有12%的Bug最终修复了,这种情况是好是坏?除非其他公司也开始统计类似这样的数据,否则我们也不知道。
  不久前我读了一本名为《丰田模式(领导力篇)》(The Toyota Way to Lean Leadership)的书,书中讲到这样一个故事:丰田北美公司在机动车质保期内通过调查修复了刹车问题,将保修成本降低了60%。受到启发后我们决定采取类似的措施,于是开始收集数据来调查哪些方面存在改进的余地。
  数据收集
  我们的所有缺陷都记录在Jira中。根据发现时所处的不同阶段,还会为这些缺陷添加标签,例如内部发现的,或由客户上报的。我们将所有这些缺陷收集到另一个分组中,并排除所有标记为不打算修复,或已纳入考虑的缺陷。我们最关注的仅仅是缺陷本身。随后开始在Git日志中搜索相应的Jira ID(我们已经建立了一个策略,会将Jira ID保存在提交消息中)。
  最终我们发现了189个缺陷以及代码库中相应的修复,这些内容的时间跨度长达两年半。对于每个缺陷,我们会收集超过40种统计信息:上报和修复时间、影响的领域、通过哪种类型的测试或技术可以提早检测到、缺陷所在方法/函数的规模和复杂度等(你可以查看我们所收集统计数据的删节版本,并将其用作自己的指导方针: goo.gl/3Gdsnm )。
  数据收集过程十分漫长,因为需要收集手头的所有数据。我们已通过日常工作调查了189个缺陷,每个缺陷收集40多种统计信息,这一过程就用了超过六个月。现在我们已经可以清楚地知道需要查看哪些信息,因此冗烦的数据收集过程已经可以自动实现。
  初始分析
  我们得到的第一个结论是:只有10%的缺陷是我们真正感兴趣的,并且不是由开发者造成的。我们的产品是一种SaaS应用,可以从最大规模的社交网络收集各类数据(仅通过Facebook API,我们每天就要处理上千万个请求)。有时候,社交网络会不事先通知直接更改自己的API,随后我们的客户就会发现存在缺陷。对此我们只能快速反应修补自己的产品。我们会从后续分析种排除这些缺陷,因为此类问题根本无法提前解决。
  前端和后端的缺陷数量比值约为50/50,但两方面都需要密切关注。后端本身的缺陷分布就足够有趣了,大约2/3的此类缺陷位于PHP代码中,1/3位于Java代码中。我们一开始使用了PHP后端,大约一年半之前开始使用Java重写后端的部分组件。因此PHP已经用了很长时间,在我们进行缺陷调查的两年半时间里“贡献”了大部分缺陷。
  哪个编程语言造成的缺陷数量更少,这种讨论已经太多了(例如 哪种编程语言通常可以产生最少量包含Bug的代码? ),我们决定通过经验为自己的PHP和Java应用程序找出答案。最终发现,如果一开始就使用Java而非PHP,只有6%的缺陷是可以避免的。在PHP代码库中,有很多地方我们并不清楚变量的具体类型。对于string、date、number或object,我们会进行额外的变量检查。在Java代码库中,我们知道所有变量类型,因此无需进行额外的检查(而这也是缺陷的一个潜在来源)。
  然而在将部分后端从PHP重写为Java时,仅仅6%的“Java优势”也会被进一步削弱,我们忘了包含某些函数,导致产生了缺陷。此外(关于这个结论只有一些“传闻证据”)开发者觉得相比PHP,使用Java开发的速度“更慢”。
  我们两年半之前开始调查客户上报的缺陷。当时后端(这可不是双关语)完全使用PHP编写。在那一年后,我们开始用Java重写部分组件,新的后端于六个月后上线。新发现缺陷的数量并未立即减少(参阅下文Screenshot_9)。从PHP切换为Java并不意味着缺陷数量会自动减少。随后我们开始实现下文将要介绍的不同改进措施,并且需要继续等待六个月才能看到缺陷数量开始减少。重写工作也是同一批开发者进行的(我们的人员调整率很低)。
  这一切意味着,根据我们自己的数据,长远来看,产品的质量将主要取决于所涉及的开发者以及所用流程。质量与所用编程语言或框架的关系其实并不大。
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号