Defects的启示

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

内容简介:在过去的几个月,我做了一些实践,通过整理、讨论和分析项目上的Defects情况,来探索质量管理中的待改进点。最终发现,Defects实际上给质量管理带来了很多的启示。当然,要讨论Defects,首先要使团队对Defects有一致的理解。我查了很多资料,也没有找到对”Defects”一词的明确定义,大部分人将”Defects”等同于“Bug”。1947年9月9日,Grace Hopper发现了第一个电脑上的bug。当团队在Mark II计算机上工作时,搞不清楚为什么电脑不能正常工作了。经过深度挖掘,才发现,

在过去的几个月,我做了一些实践,通过整理、讨论和分析项目上的Defects情况,来探索质量管理中的待改进点。最终发现,Defects实际上给质量管理带来了很多的启示。

当然,要讨论Defects,首先要使团队对Defects有一致的理解。我查了很多资料,也没有找到对”Defects”一词的明确定义,大部分人将”Defects”等同于“Bug”。

1947年9月9日,Grace Hopper发现了第一个电脑上的bug。当团队在Mark II计算机上工作时,搞不清楚为什么电脑不能正常工作了。经过深度挖掘,才发现,原来是一只飞蛾误打误撞地飞到了计算机内部,从而引发了故障。从此,人们开始用“Bug”(原意是“虫子”)来称呼计算机中的隐含的错误。

然而,一个好的软件产品,不仅要关注功能本身,还要关注其是否好用、是否安全、是否给用户带来良好的体验、是否帮助用户实现真正的业务价值。因此,从狭义上讲,Defects是指软件程序中存在的某种破坏其正常运行的问题或错误。从广义上讲,Defects还包含那些没有达到客户或用户期望的质量问题。具体来说,Defects可以分为以下几类:

  • 程序错误: 指程序中存在某种错误,比如边界、时区等问题,使得系统无法正常工作。
  • 性能问题: 指由于性能瓶颈所导致的系统缺陷。试想,作为用户,如果你想要查看一个报表,却需要花10分钟来等待加载,你是否会放弃?
  • 安全问题: 指软件安全漏洞,造成信息泄露、或使得系统数据或功能易受攻击。
  • 兼容性问题: 指程序无法在不同的硬件平台、操作系统、网络环境等中正常运行。
  • 功能与用户需求不否: 指软件功能与用户期望不匹配。比如,用户期望造一个沙发,却交付了个马扎。
  • 交互体验不佳: 指用户使用起来不方便。譬如,电梯控制面板上的“报警”按钮和“关门”按钮紧挨在一起,你是否经常由于”关门”而误触了“报警”按钮?再比如,你在网页中填写了一个长长的表单,点击“提交”按钮后,系统提示输入信息有误,却并没有告诉你错误的哪里,你是会不耐烦地从头查阅,还是干脆放弃?

Defects的产生与应对策略

产品质量是团队共同的责任,软件开发是一个过程,任何环节都有可能产生质量问题,但每个环节的问题都应该选择比较恰当的处理方式。

在敏捷开发中,我们以迭代的形式逐步完成产品的开发,每个迭代都能以一个可交付的软件呈现给用户,从而尽早地获得用户反馈,以保证我们交付的软件是用户真正期望的。在每个迭代中,我们所有的开发都基于用户故事卡(Story),每一张用户故事卡都将经历Analyse、Design、Code、Test、Deploy的过程。

那么,在敏捷软件开发过程中,哪些环节都可能产生Defect呢?

Defects的启示

正如上图所示,Defect分别来自于Sprint阶段、UAT用户验收阶段以及真正的生产环境。其中,Sprint阶段又细分为:不合理的需求、不恰当的设计、代码及逻辑错误、Story卡测试过程中发现的问题、回归测试中发现的问题、以及非功能性测试发现的问题。

开发过程中不同阶段的Defects,我们分别采用什么样的敏捷实践来应对呢?

Defects的启示

上图以看板的形式展示了Sprint开发中Story卡片流动的过程,以及每个环节的敏捷实践,这些实践有助我们发现和改善质量问题:

  • 不合理的需求: 由于QA往往有不同于BA的视角,提早与BA Pair完善Story AC (Acceptance Criteria)。此时发现的问题要及时补充到Story卡上。这样,不仅能够尽早地发现需求上的不合理或遗漏,还有助于QA深入理解需求、设计测试用例。
  • 不恰当的设计: UX制作出酷炫的设计图,却并不一定是用户真正期望的,或者技术实现的成本过高。因此,一方面,要在开发之前与用户Review设计图,并按照用户的反馈及时更新;另一方面,在每一张Story卡开始开发之前,由BA、UX、QA及Dev一起Kick Off Story,通过讨论和澄清,使得团队成员对需求和设计达成一致。一旦发现问题,要及时更新Story卡和设计图。
  • 代码及逻辑错误: 单元测试、Code Review、Desk Check都是用来发现代码及逻辑错误的有效手段。因此,开发提交代码后,要先执行单元测试、只有当单元测试通过之后,才可以将代码部署到QA测试环境;然后按照Story的AC逐条与QA和BA进行Desk check。除此之外,开发团队要每天坚持Code Review,以便发现代码逻辑及编码规范方面的问题。这些过程中发现的Defects都应该尽快修复。
  • Story卡测试中发现的问题: Story卡测试时发现的问题,无论其严重程度如何,基本上都要在当前迭代修复。QA可以与Dev面对面沟通,也可以将Defect添加到Story的Comment里面,再将Story重新拖回In Dev状态,或者在物理看板上添加一张物理卡片。但无论哪种形式,都需要在早会时提及,以便有效地跟踪Defect进度。
  • 回归测试中发现的问题: 普遍来讲,回归测试发现的问题,优先级要低于Story的开发。因此,QA需要在电子看板或者Defects管理系统中提交一条Defect记录,然后与BA沟通,在最合适的时间Assign给Dev。但如果该Defect造成系统崩溃或者Block了某些功能的使用,就应该立即修复它。
  • 非功性测试发现的问题: 非功能性测试一般是在每个Release上线之前做,发现的问题也要在Release之前修复。同样需要在电子看板或者Defects管理系统中提交Defect记录,但要注意其优先级。
  • UAT用户验收阶段的反馈: 在UAT阶段,开发团队向用户Showcase,或者由用户来做用户验收测试。此时,用户会提出一些反馈。由QA和BA对这些反馈进行分析,如果是功能层面的问题,在看板上建成卡片,并在上线前修复。如果是需求层面的问题,就将其添加到需求列表中,以便安排在之后的迭代计划中。
  • 生产上的问题: 生产上的问题优先级是最高的。但是与用户反馈一样,功能层面的问题要立即修复,用户体验上的问题要添加在需求列表中。

Defects对质量管理的启示

Defects并不是独立存在的,它或多或少反映出了项目管理和开发过程中存在的问题,这些问题都可能对质量产生影响。比如:线上问题的走势,是否能够反映出产品质量的变化;分析每个迭代Defects的数据及产生的原因,有助于发现开发过程中出现的问题,及时地进行风险把控。

我以自己所在项目为例,说一说Defects给质量管理和团队管理带来的启示。

1. 通过线上问题走势,分析产品质量的变化

2017年8月,我们接到A遗留系统,到10月份累计在生产环境发现历史遗留问题21个。按照优先级,每个月修复一定的数量。截止2018年7月,发现的历史遗留问题高达46个,只剩余2个还未修复。Defects数量在减少,产品质量在逐步提升。

Defects的启示

除此之外,我们对历史遗留问题和新引入问题做了对比,这10个月的线上问题中,历史遗留问题占85%,新引入问题占15%,可见仍有部分没能在开发过程中发现,使其流到线上。要对这些问题具体分析:其严重程度如何、产生的原因是什么、为什么在开发过程中没有发现、后续有怎样的改进措施。 当然,最好能对生产上的“运维类问题”和“功能类问题”加以区分,以便采取更恰当的改进措施。

2. 分析迭代Defects情况,讨论改进措施

除了分析线上问题,我还对从2017年10月-2018年7月QA提交的Defects情况做了一个统计,观察每个月提交的Defects和修复的Defects情况。

Defects的启示

从统计结果来看,2018年7月发现和修复的Defects数量均呈明显的上升趋势,达到历史最高点。因此,有必要对7月份的Defects情况做一个详细的分析,看看究竟是什么原因导致了这些Defects。

Defects的启示

我对这些Defects做了一个初步的分类,并利用Retrospective Meeting的机会,与团队成员一起分析讨论。发现产生问题的原因有以下几个方面:

  • 本次Release的Story Kick Off和Desk Check做的不够好。有时候开发没有Kick Off就直接按照自己的理解开始编码,导致团队成员没有对需求达成一致的理解,做出来的功能出现偏差。有时候Dev将一堆卡垒在一起做Desk Check,这样很难逐条覆盖AC,从而将问题流入QA测试阶段。
  • 本次的需求比较偏技术,BA只能从业务的角度去编写Story卡。开发同学为了追赶工期,没能够添加充分的Tech Task, 也没能够坚持Code Review,导致出现一些逻辑错误。
  • 单元测试覆盖率比较低。作为一个遗留的微服务系统,某些服务在之前从未重构过,代码逻辑比较混乱,添加单元测试的难度大、成本高。因此一些本该单元测试阶段就能发现的问题一直流到QA测试阶段。
  • 本次Release一共一个月时间,UI一直到最后一个礼拜才确定下来,期间反反复复的修改不仅花费了太多成本,还消磨了Dev的意志,导致出现一些本不该出现的Defects。
  • 新人加入,项目工期紧,对上下文信息同步不够,导致新开发的内容破坏了一些已经验证过的功能。

这些原因充分说明了这段时间项目中存在的问题,我们对此逐条提出了具体的改进措施:

  • 坚决执行Story Kick Off和Desk Check敏捷实践,在每日站会时严格跟踪每一张Story卡的进度。
  • 预定一个定期会议,每天下午17:00 – 18:00进行Code Review,并每周一人轮班担任Owner。
  • 将单元测试覆盖率可视化。同时,制定项目标准:对于新开发的内容,必须编写并通过单元测试才能Desk Check;对于历史遗留模块,在技术债墙上添加技术债卡片,并于每周消化一个技术债务。
  • 项目开发前期要加强与客户和用户的沟通,在Story开始开发之前,确定好UI设计,开发过程中尽量避免大的改动。
  • 新人加入项目时,采用结对编程的方式完成开发。除此之外,每周在项目内进行一次技术分享Session。

当然,以上两点只是我基于A项目举的一个例子。实际上,Defects还给了我们很多启示,比如,为什么项目老是加班?为什么有些模块的Defects数量比较多?如何根据团队成员花在Defects上的efforts,制定提升计划?然而,每个项目的情况不一样,我们应该基于自己的项目背景,由团队成员一起分析深层次的原因,共同制定切实可行的改进措施,从而不断地提高产品质量。

更多精彩洞见,请关注微信公众号:思特沃克


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

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

Web Data Mining

Web Data Mining

Bing Liu / Springer / 2011-6-26 / CAD 61.50

Web mining aims to discover useful information and knowledge from Web hyperlinks, page contents, and usage data. Although Web mining uses many conventional data mining techniques, it is not purely an ......一起来看看 《Web Data Mining》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

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

RGB CMYK 互转工具