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，制定提升计划？然而，每个项目的情况不一样，我们应该基于自己的项目背景，由团队成员一起分析深层次的原因，共同制定切实可行的改进措施，从而不断地提高产品质量。
- 相关阅读 -
点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。
本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。