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都应该尽快修复。