缺陷预防-我认为的质量改进正道之光
欢迎关注公众号“软件质量奇谈”。关于软件工程，测试，质量管理等问题，欢迎在公众号留言提问，必定尽力解答，如有资料需求，也可尽力分享。
前段时间在和几位研发团队负责人讨论团队的质量目标时，有一位同事说了句让我印象很深的话。
他说：相比较让我团队的同事们更快地修复缺陷，我更关心这些缺陷是怎么发生的，如何避免这些缺陷的发生。
我告诉他，我很高兴听到有同事提出这样的观点，当多数人都还在讨论缺陷能不能修复，哪些缺陷需要修复，哪些缺陷可以晚点修复，甚至不修复的时候，他已经在思考如何预防缺陷的发生，这是更高级的质量观，很好。
我说这些话，是在真心的赞扬他。
现实的大IT行业，特别是互联网行业中，有缺陷预防意识的研发负责人不多，多数对质量的理解，还停留在“测试”阶段，认为软件质量主要依赖软件测试团队来进行检测，然后开发团队对检测出的问题进行修补来达成，所以，你也许也遇到过这样的情况，当产品交付后发现缺陷逃逸的时候，研发团队就会有人质问测试负责人：这个Bug为什么没有测试出来？他们问这些问题的时候很坦然和理直气壮，因为在他们的质量观中，他们真的认为，缺陷的发生不可避免，却没有理由不被检测出来，质量就是测试团队的事情，质量的达成就是测试一个团队的责任。
当然也有少数质量观相对成熟一些的团队，他们会有关注自己工作产出物质量的意识，也会相应的采取一些对自己工作进行检测的措施，比如单元测试，集成测试，模块测试等，也或者仅仅是一些基础的代码健康测试。在他们中的一些人看来，他们已经在做缺陷预防了，因为他们自己解决掉了一些质量问题，避免把这些问题流入到下一个研发阶段。
但是，对自己的交付物进行测试，发现并解决掉自己造成的缺陷，这就是缺陷预防了吗？
很遗憾，这也还不是缺陷预防。
什么才是缺陷预防？
缺陷预防不是先纵容缺陷的发生，然后再投入资源去探测和发现这些缺陷，最后再对这些发现的缺陷进行返工和修复，缺陷预防强调的是要采取积极主动的方法和技术，在开发的过程中正确实现产品的需求，避免在产品中引入错误或者缺陷。再简单一点讲，缺陷预防不是先犯错后改正，也不是自查自纠，而是要求一开始就不要犯错。
我们为什么要做缺陷预防？
简单的回答，就是缺陷预防是更高效更经济的质量控制手段。传统的质量检测，不管是产品研发生命周期中哪一个阶段采取的哪种检测手段，不管是需求评审也好，设计评审也好，甚至后期的代码走查，单元测试，集成测试，系统测试等等，这些工作本质上都是返工（Rework），这种返工，与工厂里面生产线上发现了次品，然后工人们把次品退回到上一道工序进行处理本质上没有区别。缺陷引入后，检测需要成本，问题的分析，确认和沟通需要成本，问题的修复需要成本，修复后的复测还是需要成本，而且为了解决掉一个引入的问题，很可能这样的发现和解决问题的循环要跑不止一次才能最终完成对问题的修复。我们都知道时间对于业务的重要性，也知道开发资源很贵，测试资源一样很贵（关于测试的成本，以后有机会专门谈），再想想这些时间和资源的机会成本，缺陷的引入，往往带来的是效能的降低和资源的极大浪费。
可能有的同学会有疑问，缺陷检测和修复需要成本，缺陷预防不是一样要成本？为什么缺陷预防就一定能从整体上更经济？这个问题要仔细回答还真的不容易，除了需要质量成本COQ（Cost of Quality）的一些理论和分析，还需要结合团队的缺陷预防能力看，也许以后可以专门讨论一次。但是这里还是可以用质量领域很有名的1-10-100原则来简要解答这个问题。
1-10-100原则是质量管理大师George Labovitz等提出的一个理论，它主要是说在缺陷预防上每花1美元，大约可以在缺陷检测和纠正上节省10美元，以及在缺陷可能带来的业务损失上减少100美元。
从这个原则上看，如果我们把产品总的质量成本看作是预防缺陷，检测和修复缺陷，以及缺陷逃逸所带来的损失的总和，那么显然缺陷预防是一项非常值得投资的质量控制措施，因为即使它不是免费的，因为它比检测和修复有更高的ROI，在软件质量管理中引入缺陷预防也会从整体上减少质量成本。
通过缺陷提高质量的三个层次
一般而言，通过缺陷来提高质量大概有三个层次，第一个层次是传统的缺陷检测，主要以评审，审计以及测试为主要手段，找到问题并修复问题，从而达到质量目标。
第二个层次是缺陷分析，对已经发现的问题寻根溯源，找到问题的原因，并采取行动避免类似的问题发生，这个层次也可以称为被动的缺陷预防。
第三个层次是主动的缺陷预防，不止是要去避免类似的问题发生，而是主动的分析可能会出现哪些错误，从而在设计和实现的过程中提前采取措施避免这些错误的发生。主动的缺陷预防使用的常用技术包括失效模式分析，故障树分析，失效模式影响与诊断等技术，以后有时间再展开介绍。
两个极端：预防缺陷可行吗？抑或我们应该用缺陷预防完全取代缺陷检测？
我听到过不少这样的声音，很多工程师会抱怨或者质疑：有人的地方就有错误，有代码的地方就有bug，缺陷预防会给工程师带来很大压力，诸如此类。
缺陷能不能预防，我觉得需要反过来分析一下问题是怎么造成的。一般而言，人们在工作里面犯错，主要有两个原因，第一个原因是缺少足够的知识和信息，当然有人会提到经验，但是我认为经验仍然属于知识和信息的范畴。第二个原因是缺少足够的重视和关注。知识和信息的缺乏，是可以通过学习来加强的，而缺少重视和关注，本质上是态度问题，可以通过管理手段来解决。当人们具备了充分的知识和信息，也对工作和目标有了足够重视和关注，缺陷预防就已经具备了可行性。
可能也会有人提出另一个极端：既然缺陷预防更加高效和经济，那么我们是否应该完全用缺陷预防来替代检测和修复？
我的观点是：不能。首先，软件的缺陷并不一定完全就是人的错误所造成的，这里面可能会有工具，环境，使用的技术等其他原因，而人对这些可能的问题根源是很难完整的认识和规避的。其次，确实可以通过预防技术的学习，知识和经验的积累，流程的改进和实施等减少人为造成的错误，但是我们可能永远也无法确保人百分之百不犯错。第三，缺陷预防是有门槛的，能够产生多大的效力，缺陷预防的投资回报有多高，还要看团队的缺陷预防能力和实施能力如何。所以，即便我们引入和实施了缺陷预防，我们还是继续需要缺陷检测作为质量保障的重要工具（测试工程师们饭碗暂时是丢不了的）。
总的来说，缺陷预防是一个很大的话题和一个专业的质量技术领域，本文只是对它做了一些很基础的介绍和讨论，还没有涉及到具体的缺陷预防理论和技术。也许正是因为它是一项很专业的技术，所以行业中真正在做缺陷预防的组织其实很少，很多人望而却步，连基础的被动预防都不做。
但实事求是地说，缺陷预防仍然是一项能够有效提高质量管理效率，降低成本的技术，我个人认为，作为研发组织，我们可以正走在通往缺陷预防的路上，但是我们不要轻易说我们做不到缺陷预防。当你这么说的时候，你也许只不过是在承认自己的团队没有足够强大而高效的质量交付能力而已。
欢迎关注“软件质量奇谈”
IT，互联网，软件测试，质量管理，探讨技术，分享经验，聊聊职业规划。