敏捷开发中,学会为Defects管理做减法

前两天,我接到好友Sasha的电话,她满腹委屈地说自己与组里一位测试MM产生了些分歧。原来故事是这样的。

Sasha是A公司B项目组的测试Leader,刚刚处理了一个关于Defect的纠纷。组里一位测试小姐姐提的Defect开发小哥哥没看懂,就被随手搁置了,直到上线前才被扒出来。小姐姐抱怨开发fix Defect不及时,小哥哥自然不答应了。便找她投诉,说是Defect只有一张截图,根本不知道如何复现。Sasha发现事实确实如此,就去找测试小姐姐沟通。谁知,小姐姐却振振有词,“敏捷不就是在讲究提高效率、少写文档吗?每一个Defect都按照规范来写,我的时间就都花在写Defect上了”,“有图有真相,开发还看不懂,是不是说明他自己对需求不够理解”,“Defect assign到他头上那么久,到现在才说写的不清楚,早干嘛去了”……

七姑娘却认为这位测试小姐姐的一连串的发问并不完全没有道理,相反,却恰恰反映了Defects管理中的几个关键点:

敏捷开发中,如何管理Defect才能真正提高效率?

即使有截图为证,却仍然不能真实的传递信息,该怎么办?

Defects到底是谁的责任?

Defects管理作为测试工作的核心之一、也是每个QA必须掌握的一项专业技能。但现实中,QA和Developer往往会因为Defects产生各种各样的摩擦。大部分团队会倾向于采用专业的Defects管理工具,比如QC、Jira等,企图用标准的、规范的工作流来保证Defects的信息传递、进度跟踪以及数据收集。工具自然是好的,意图也是好的,然而问题却是,这些工具和流程对于QA来说,太过于重量级,以至于花费了大量的精力在Defects的编写上,却忽略了沟通的重要性。

七姑娘认为,在敏捷开发中,要因时制宜、因地制宜,学会为Defects管理做减法,才是真正提高效率、解决冲突的不二法则。所谓做减法,就是简化Defects的书面描述和工作流,加强面对面的沟通。

首先,对Defects进行分类管理

标准的Defect描述包括预置条件、复现步骤、预期结果、实际结果、以及截图等。QA需要花费大量的时间在Defect的编辑上, 严谨的QA甚至要多读几遍以保证没有错别字、语义没有分歧。然而,等到了Developer这里,大篇幅的文字,他的内心一定是排斥的。即便是认真读了,其理解也未必准确。

敏捷开发强调“个体和互动 高于 流程和工具”,太注重流程,反而不利于敏捷项目的推进。很多时候,编辑一个Defect的时间要远远大于修复它的时间。因此,我们要学会对Defects进行分类,并针对不同类型的Defects采用恰当的管理方法。

第一类:不合理的需求、不合理的设计方案

Defects不仅仅指是代码逻辑的错误,有很多缺陷往往来自于“不合理的需求“。BA也是人,有些细节,BA在前期不一定考虑的到。QA往往有不同于BA的视角,这就要求QA要提早介入需求的讨论,一旦发现需求有任何的不合理或覆盖不全面,就要及时与BA沟通,将这些内容补充到Story的AC(Acceptance Criteria)中。

还有一些缺陷来自于”不合理的设计方案”。比如,系统中有若干个定时任务,他们协同工作才能使得系统正产运转,那么,一旦定时任务的前后顺序设计的不够合理,就可能发生意想不到的问题。因此,QA要有刨根问底的精神,主动与Developer沟通实现方案。一方面,了解技术细节有助于进行更多的探索性测试;另一方便,能够增强QA准确定位问题的能力。

第二类:未达到Story的核心验收标准

在敏捷开发中,Developer每完成一张Story卡,都要showcase。按照story中的AC逐条进行演示。如果某一条AC没有验收通过,这张Story就不能Dev Done,Developer需要修复后重新Showcase。

Showcase通过后,QA就可以正式的展开测试了。这时候,如果发现的Defect属于这张Story本身的范畴,并且影响到了Story的核心功能,则建议QA在Story下面添加Comment,一句话描述清出问题。然后找Developer面对面复现一遍Defect,这种方式更加高效直观。避免出现“我这儿咋就是好的”的问题。当然,为了便于追踪,建议写上物理卡片,贴在白板上,并在每日站会时更新进度。

第三类:是Defect,但不影响Story的核心功能

QA在测试过程中,也会发现一些并不影响Story核心功能的Defect,这时候,Defect的优先级就应该低于其他Story的开发。无论使用Defects管理系统还是看板,QA需要将该Defect先记录下来,详细程度吧,以自己能够复现为标准。

此时,不建议直接将Defect assign给Developer,以便Developer不被打断,全身心的投入Story的开发。

等到Story开发基本完成,高优先级的Defects基本修复之后,这些Defects就该给翻出来了。要注意的是,Defect是由时效性的。有些Defect会被Developer自己发现,然后默默修复。还有些Defect会随着新功能的开发现象发生改变。因此,QA需要按照之前的记录,重新复现一遍Defect,确保问题在当下的准确定,再找Developer当面演示。毕竟,面对面的沟通比文字直观多了。如果可以的话,要多跟Developer Pair调查原因,自己定位问题的能力也会逐步提升。

第四类:复杂的Defects

当然,Defects不是在测试一个个独立的Story时就能全部发现的。有一些是当功能集成在一起的时候才会出现,还有一些是遗留很久的历史缺陷。这些Defects往往复现步骤比较复杂,就需要我们按照标准的Defect描述方式将其记录下来。并根据严重程度逐一安排修复。优秀的Defect描述实践如图所示:

需要注意的是,即便有了详细的描述,面对面的沟通永远是最直接的。将Defect assgin 给Developer时,最好需要做一个类似于Kick off的活动,以便QA与Developer的理解保持一致。

其次,Defects到底是谁的责任

很多QA偏执的以为,Defects是Developer造成的,Developer就有责任修复它。于是提完Defect随手扔给开发,只要工作流没重新走回到自己这里,就绝不会主动跟踪。Developer更是站在对立面,认为Defects是QA提的,他(她)不催,自己也懒得催。

实际上,敏捷开发强调质量是大家的责任,无论是什么角色,都应该尽可能的为提高产品质量出一份力。QA作为Defects管理的核心人员,应该时刻关注每一条Defect的进度和状态,主动与Developer沟通,以保证其在最恰当的时间、最快的得到修复。而Developer,应该积极配合,一方面,高效的完成assign给自己的任务本身就是一件很有成就感的事;另一方面,通过对Defect的分析和修复,也是对自己的方案设计或者编码的一种审视,收益远比自己想象的大。

总而言之,Defect管理只是一种手段,解决问题才是目的。对QA有最价值的事就是尽可能多的发现问题,其次,帮助Developer花费最少的时间修复最多的Defects。学会为Defects管理做减法,将QA和Developer从不必要的劳动中解放出来,才是高效的做法。如果在Bug管理本身花费太多时间,就有些得不偿失了。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180525G1I66900?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励