敏捷开发中，学会为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管理本身花费太多时间，就有些得不偿失了。