Defects的启示

在过去的几个月,我做了一些实践,通过整理、讨论和分析项目上的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呢?

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

开发过程中不同阶段的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数量在减少,产品质量在逐步提升。

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

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

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

从统计结果来看,2018年7月发现和修复的Defects数量均呈明显的上升趋势,达到历史最高点。因此,有必要对7月份的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,制定提升计划?然而,每个项目的情况不一样,我们应该基于自己的项目背景,由团队成员一起分析深层次的原因,共同制定切实可行的改进措施,从而不断地提高产品质量。


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

Share

项目实施DevOps时,我们是如何做测试的

正如我们所知,DevOps最近几年很风靡,很多企业正在如火如荼的推行它。然而,你可曾想过,从传统到敏捷、再到DevOps,开发模式的不断革新对测试提出了怎样的挑战?

最近我们项目在实施DevOps,因此想趁热打铁,就DevOps模式下如何做测试,谈一谈自己的认知。

DevOps有什么特征

DevOps是一系列软件开发实践,强调开发人员(Dev)和运维人员(Ops)之间的沟通合作,通过自动化流程,使得软件构建、测试、发布更加快捷、频繁和可靠。

1. DevOps强调一种文化

在很多企业中,开发和运维人员通常隶属于不同部门,有着不同的工作环境,采用不同的沟通方式,使用不同的开发或运维工具,并且有着不同的业务目标,这使得他们之间形成一道参不透的墙。

DevOps实际是一种文化上的变迁,强调开发、运维、测试等环节之间的沟通合作。意在帮助这些人向着一个共同的目标努力:尽可能为公司提供更多价值。为了支持这种合作的发生,需要在团队内部文化和企业组织文化两个层面做出努力。

2. DevOps是一种实践

所谓DevOps,就是将敏捷方法延伸到Production!

DevOps主要是为了将敏捷开发实践扩展到运维阶段,进一步完善软件构建、验证、部署、交付等流程,使得跨职能团队能够完成从设计到生产支持等各环节的工作。

3. DevOps包含一系列工具链

DevOps是一种融合了一系列基本原则和实践的方法论,并从这些实践中派生出了各种工具。这些工具体现在软件开发和交付过程的不同阶段:

  • 编码:代码开发和审阅,版本控制工具、代码合并工具
  • 构建:持续集成工具、构建状态统计工具
  • 测试:通过测试和结果确定绩效的工具
  • 打包:成品仓库、应用程序部署前暂存
  • 发布:变更管理、发布审批、发布自动化
  • 配置:基础架构配置和部署,基础架构即代码工具
  • 监视:应用程序性能监视、最终用户体验

DevOps对测试提出了哪些挑战

刚参加工作时,我参与了某Audi系汽车电子的软件研发,采用的是传统瀑布开发模式。在整个项目生命周期中,前半部分设计和编码,后半部分用来测试。然而我在东家工作了两年,也没能等到产品交付到用户手上。直到去年,我们的软件才得以量产并投入市场。在这4年中,产品从未交到用户手上,因此无法验证它所带来的价值,也没有任何机会得到用户反馈从而适应变化。

后来,我又参与一个银行项目,我们采用敏捷的开发模式,全功能团队,开发测试并行,每2-3周就交付一个版本。但因为没有真正发布到生产环境,我们仍然无法及时得到有效的用户反馈。

现在,我们采用DevOps的优秀实践,开发和运维协同工作。每个迭代完成,或者每修复一个线上缺陷就立即部署到生产环境。这样,我们就能够迅速从用户处获得反馈并且快速做出响应。

通过参与传统、敏捷和DevOps的项目,我深深地感受到流程的改进对团队以及项目的产出和质量所带来的改变。

那么,这些改变究竟是对测试提出了什么样的挑战? 我认为有以下几点:

1. 频繁部署

在采用DevOps之后,我们能够根据项目具体情况做到每天甚至一天多次部署。在生产环境频繁部署软件,最大的挑战就是测试。以前,测试基本上都在开发阶段之后和产品上线之前完成。但现在,不再有充足的时间留给QA团队去发现问题再抛给开发团队来修复。那么,速度成了测试面临的一大挑战。

2. 自动化

DevOps强调将流程自动化,测试作为其中一个重要环节,势必要大规模实现自动化。因此测试人员的自动化编码能力正在面临极大的挑战。

3. 实践和反馈

敏捷提倡我们要拥抱变化,更多的是要适应需求的不断变化。虽然一部分功能性需求是明确又具体的,我们清楚的知道用户想要什么,也因此易于测试。然而,也有一些非功能性需求的验收标准没那么明确,比如:提高应用性能达到良好的用户体验。我们如何才能验证用户体验是否真的良好呢?仅仅通过性能指标吗?当然不是,满足指标只能说明一部分问题,唯有真实的用户数据和反馈才是可最靠的。

4. 协作

敏捷强调全功能开发团队的共同协作,但这仅仅止于开发阶段。而DevOps注重Dev、Ops和QA三个群体之间的密切协作。因此,良好的角色定位能够帮助测试人员将价值最大化。

我们是如何做测试的

Laurent曾经在Hiptest上发表了博客《Shift left and shift right: the testing Swing》,提出了一个有意思的测试矩阵,从四个维度进行分析,描述了当软件开发模式从瀑布到敏捷、再到DevOps转型时,测试该如何响应变化。

Laurent提出一个测试左移和右移的概念:

  • 测试左移,就是指在开发阶段之前定义测试。
  • 测试右移,就是直接在生产环境中监控,并且实时获取用户反馈。

在敏捷开发的生命周期中,我们通过每一次迭代来丰富和更新产品,以使其最大限度地符合客户对系统的需求。当时测试的关注点基本停留在开发阶段,以保证产品达到上线标准。引入DevOps之后,我们不仅要关注产品的质量是否达标,还需要使价值假设得到及时的验证。因此,我们不仅要将测试左移,在开发环境验证功能的可用性,还要进行测试右移,通过监控产品在生产环境的运作情况,来验证其价值并获得反馈,从而持续改进。基于这些理解,我在项目上做了初步的尝试并取得良好的效果。我将这些尝试和实践总结为以下几点:

1.如何保证新功能得以实现?

在开发环境,我们开发新功能,并且通过测试保证其达到产品验收标准。

首先,使用BDD(Behavior Driven Development,BDD)的方式定义用户需求,这样用特定的语言来描述用户行为,能够使各个角色(测试、开发、产品负责人、市场等)对业务价值达成一致的理解,从而使其从需求到最后的测试验证,进行高度的协作和沟通,最后交付最有价值的功能。同时,QA能够提前Review故事卡,补充验收标准。除此之外,BDD方式的用户需求可以直接指导测试,后续我会写到。

其次,采用单元测试来验证最基本的代码逻辑。在编写单元测试时,建议Dev和QA Pair工作。单元测试可以认为是编码的一部分,要对系统的代码逻辑有深入的了解,因此,Dev是最合适的人选,而QA可以帮助测试覆盖的更全面。

最后,每一个功能都要严格按照故事卡的AC(Acceptance Criteria)进行验收,并采用探索性测试方法来对新功能进行无死角测试。

2.怎样验证新功能的价值?

我们将新功能部署到生产环境以后,接下来就应该衡量业务价值是否达到预期

验证预期的一个好方法是衡量用户的行为变化。比如:在上传图片的功能后面添加了一个预览按钮,但用户却极少用它,很可能是因为用户根本不需要这个按钮,或者按钮放在了不恰当的位置导致用户不方便使用,亦或是按钮样式不够友好,导致用户没有欲望使用它。这时候,该按钮的业务价值就没有真正达到,是时候调整一下了。

3.如何确保已有功能不被破坏?

在软件开发中,任何代码都不可能完全独立存在,一行代码的变更也有可能导致系统的全面崩溃。那么,如何保证在开发新功能的同时,已有功能不被破坏?换句话说,如何做到全面的回归测试?人力是最高成本,也有现实的局限性,比如,人手不够,重复做同样的事情人会变得烦躁,手不够快导致效率低下等。因此,自动化测试才是不二选择。

将BDD需求直接转化为自动化测试用例。每个测试用例都应该讲一个关于应用程序的故事。当一个测试用例使用一致的业务术语定义时,它的可读性会比较高,且容易自动化。与此同时,上一个迭代的用例在下一个迭代就可以迅速转化为回归测试的基线。

支持BDD的工具有很多,比如:Cucumber。简单举个例子,如图:

BA用BDD方式定义用户需求,QA Review并补充AC,然后将其编写为自动化测试脚本。如果QA的编码能力较弱,可以让Dev协助完成代码实现的部分。这也充分说明了协作的意义。

最后,也是更重要的部分,测试应该集成在CI中。每一次Build或者每天都要去执行测试,验证已有功能是否完好。这样才会对没有预期到的变化产生的问题给出快速反馈。

另外,做一些性能测试、兼容性测试、和安全性测试等等。

4.怎样验证产品的可靠性?

有时候,某些缺陷并不是源于代码的错误,而是一个不好的用户体验,或者只有当数据达到一定量时才会出现,测试人员是无法模拟这种类型的测试的,因此直接在生产环境监控变得高效又可靠。通常我们需要监控两种特性:性能和可用性。

使用工具持续获取用户数据,或者使用log持续获取性能信息。这有助于监控产品部署到生产环境后是如何正确运作的。快速启用一个功能,在生产环境实时监控验证其业务价值,获取到有效且快速的用户反馈,加之拥有持续部署的能力,我们能够在出现问题的时候快速做出反应,从而使得我们的产品更加可靠。

这里实际上融入了《QA in Production》的理念。现如今,已经有很多工具和方法支持在生产环境做测试了。篇幅太长,这里就不做详细阐述了,请参考原文

到这里,再来回顾一下,我们的实践是否真的卓有成效。

  1. 用BDD的方式定义用户需求、编写测试,有益于不同角色之间的一致理解和共同协作。
  2. 自动化测试解决了频繁部署所带来的挑战,同时保证产品的整体功能持续得到回归和验证。
  3. 在线监控能有效地验证不确定需求,通过生产数据分析和预警问题的发生,并且快速获取用户反馈从而及时调整。除此之外,这一点也充分体现了Dev、QA和Ops的协作,像监控等原本只能Ops做的事,现在Dev或QA一样可以做。

写在最后

测试是一种活动,曾经我们通过它来验证产品是否达到上线标准。现在DevOps模式下,我们需要在各个阶段不断地执行测试活动,以达到产品质量的持续改进。

而QA(Tester)仅仅是一种较多进行测试活动的角色。敏捷一直强调“团队为质量负责”,测试不再是QA(Tester)的专属。DevOps模式更是对测试、尤其是自动化测试提出了更高的要求,也对QA的编码能力提出了极大的挑战。作为团队成员,每个人都有责任了解开发流程、提高测试技能,把好测试这一关。但是,测试活动作为QA(Tester)的主要职责之一,提高自动化测试技能,就是当下每个QA(Tester)最为紧急且重要的事情了。


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

Share