通过上面的案例信息，可以看出这个产品的开发过程本身就是不规范的，而且测试工作介入的太晚，同时在软件产品设计、过程管理、文档评审等诸多方面均存在问题。产品开发工作和项目开发工作相比，一般进度压力较小。但是产品要进行商业化最终转化为通用的商品软件，质量方面的要求要比项目成果高很多。缺陷反复出现几乎是软件产品开发的一个常见现象，要想解决这个问题，作者建议整个团队要从下面几个方面入手：

　　规范化产品开发流程：产品开发是应该遵循软件工程规范的，开发过程不应该跳过必要的环节。例如这个案例中的产品，无疑就是开始系统设计和评审工作没有做好，才导致二次开发，并且还有一个严重的遗漏就是首次开发忽略了测试工作。测试、质量保证等相关工作应该从立项开始就同步启动。

　　需求分析要明确：如果开发人员都不知道完成的内容是否正确，而是由测试人员来判断是否符合要求，那简直是需求分析的的巨大“失误”。用户或者设计者想要达到什么目标一定要清晰的描述出来，模棱两可的需求是没有办法设计测试用例的，更不用说进行测试了。

　　开发人员的调试一定要到位：开发人员一定要认真调试代码，至少要把自己负责的部分和其它模块的接口部分进行详细的测试。这项由开发人员进行的基础测试是不可缺少的。目标就是把尽可能多的缺陷消灭在开发阶段，这也无疑是最节约成本的。现代软件系统十分复杂，程序员写了程序不仔细检查代码，大多会有很多缺陷存在。如果凭着侥幸心里把所有的测试工作都交给测试工程师来完成，那只能适得其反。这些本来在开发阶段解决的缺陷由测试人员来发现会有如下的后果：

　　耽误进度——首先，缺陷要经过一定的测试流程。例如上面的案例中，网页的Title写错这样的缺陷折腾了两个部门，简直是“劳民伤财”。

　　转移测试人员注意力——大量的低级缺陷使测试工程师无法进行更加深入的测试。测试工程师的注意力分散在对于开发工程师来说“无关痛痒”的缺陷上，使得更深层次的缺陷隐藏起来。

　　降低开发人员斗志——尽管这些缺陷是开发人员自己“制造”的，但是一看到上百、上千个缺陷，无疑会影响心情，降低效率。

　　当然，增大开发人员测试力度会带来一定的投入，因此需要在项目初期进行合理的规划，否则开发工程师就会拼命赶进度，自然把测试工作“寄厚望”于测试工程师。

　　加强缺陷管理：缺陷管理在这个案例的前期做的不好。在缺陷管理中，我们不但应该把缺陷修改工作能否一次通过作为考核开发师的标准之一，更应该把一些常见的缺陷是否存在作为考核开发工程师的标准。在经过一定的积累后，开发团队应该形成一些常见的程序缺陷列表，以引起开发组成员注意。在此基础上，还需要做到下面几个要求来提高质量：

　　修改缺陷要彻底——彻底不单单是要修改好测试人员提交的缺陷，还要争取不带来新的缺陷、这就要求开发工程师修改缺陷时要对相关联的部分进行检查。

　　低级缺陷不存在——常见缺陷列表中的错误尽量不应该由测试工程师发现并提出。

　　3、产品发布后，缺陷谁来负责？

　　本案例发生在一个正在建设测试团队的组织中，这个研发团队有独立的测试小组，但不是独立的测试部门，产品部经理兼任测试经理。在产品提交给代理商后，代理商发现了一个严重的缺陷，并对其进行了投诉，最终的结果是公司领导层对开发队伍的相关人员进行了一系列惩罚。

　　测试过程简要记录：