通常的做法是通过更多的单元测试 （Unit test） 和code review，使得我们在开发阶段发现更多的问题，从而减少bug数。的确，开发人员经常单元测试，具有良好的测试和编程习惯，在每次check-in之前，或每次打baseline之前，项目组都有代码cross review，同级或跨级评审，自己代码每日评审能大大保证代码质量，在提交给测试组之前就消除大量的bug。但往往发现更大多数的bug是我们通过 Unit test和code review所不能发现的。为什么？
1、首先是需求的不明确，比如客户原先对软件的部署的需求就是和一般软件一样，没啥特定需求，后来项目进行到后期部署阶段发现有更多的部署需求，比如Failover，并行部署，对vista的兼容性等等。这些都带来的新的问题和代码修改量。
2、其次是需求理解的偏差，设计理解的偏差，比如一个员工对保险业务不熟悉，去开发保险业务IT系统的时候，往往开发出来的功能和实际业务需求相差很远。对需求理解的偏差，以及对设计理解的偏差，也有部分原因是因为沟通，没有良好的沟通，导致没有倾听客户的诉求和用户的反馈，和客户沟通的问题导致需求偏差，软件没有对客户产生价值，这种bug的比例非常高。
3、再次是程序员本身能力的限制，比如代码前期都认真经过了单元测试和功能测试，但后期发现运行效率很低，性能不好，原因在于程序员是用他们不熟悉的语言进行开发，而且对性能设计没有经验，开发中根本没有性能上的考虑。如何保证一个程序员进入一个项目开发之前，已经掌握了足够的编程语言知识和技能，已经掌握了足够的业务知识？如果这些程序员经过技术和业务两方面的培训，可能会避免这方面的问题。
4、最后是没有一套好的研发流程，质量管理体系，和配套的支持工具。这是最大的一个问题。如何找到一个适合自身公司文化和项目情况的process？
总之，软件开发和编程是一项智力活动，从获得需求、理解需求、程序设计、程序编码（数据结构 + 算法）、单元测试、功能测试、提交的整个过程中，任何一步出现偏差都可能产生bug。
当然，测试组的严格测试能保证软件的质量，但问题是如何主动防范bug？
1、程序员的技术能力和经验很重要，比如：代码设计能力，良好的编程习惯，良好的数据结构和算法，编程规范的遵守，随时资源的释放，避免内存泄漏，避免导致性能下降的代码，异常处理，以及对维护、部署、可用性、性能、稳定性的全面，良好的文档和注释习惯等等。另外，项目采用新的架构、框架或技术（例如Spring， Castle， WCF），都会因为程序员不熟悉而引入更多的bug和风险。
2、程序员的业务积累和经验很重要，大大有助于对需求的理解和把握。这非常关键。例如一个程序员做过老版本的银行清算系统，他不仅熟悉清算业务流程，而且知道老系统存在的问题，就会主动防止这些问题，准备高效的实现新系统。
3、测试组的测试活动不仅仅是找出bug，而且要通过测试来规范项目开发过程，从而提高软件产品的质量。测试通过了，bug都改完了，项目结束了？其实测试组可以总结和分析下bug产生的原因和分布，这个bug list和分布图交给开发组长和开发人员，可以分析发现开发人员经常哪儿引入bug，从而在以后的开发活动中避免这些问题，实现项目组的积累。其实可能80%的bug分布在20%的模块，因此从各个方面分析bug的根源，可以总结出项目组可以改进的地方。
最后，从根本上来说，作为软件产品与服务的提供者，只有真正理解客户的业务、顺应客户的需求才能提供令客户满意的产品与服务。应当以一个用户角色的眼光去重新审视为用户提供的技术解决方案和产品，是否是用户所真正关心的，是否真正解决了用户的问题。对于客户而言，最有价值的不是你掌握哪些技术，而是你能帮他们解决哪些问题，产生哪些价值。IBM推行OnDemand随需应变的服务， 因为在当今市场竞争日趋激烈的今天，“求变” 已经是必不可少的生存法则。这个求变的过程，需要软件公司到技术人员的蜕变，从灵活多变的业务，到随需应变的技术，不管客户的业务和管理流程、需求如何变化，技术都只是业务变革的推进动力和实现工具，bug free（无缺陷）的软件背后其实是对业务和需求的深刻理解和行业积累，先进的技术实力，完善的质量管理体系，和软件开发流程。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/