开发与测试可能是软件开发过程中的一对“对头冤家”了，开发人员开发应用，测试人员测试开发人员开发的应用，然后将结果（即发现的bug）反馈给开发人员，开发人员修正bug，然后测试人员需要测试验证，如此以往，形成了一种螺旋上升的环状反馈结构。

　　在这个反馈过程中，测试人员其实是起到了QA的作用，用来保证软件应用的质量，因此，在许多公司，测试人员也叫做QA。从理论上讲，这是一种比较良好的能够保证软件应用质量的反馈机制。但是，如果不对这个过程中采取一定的监控机制的话，则会削弱整个项目的开发质量，提升项目的成本。笔者就遇到这么一种环境，公司对于测试人员的绩效考核中一个非常重要的标准就是测试人员提交的bug的数目（即测试人员提交的故障数量）。一个测试人员提交的故障数量越高，那么他的绩效就越高。这种方式直接产生了一个后果：测试人员以故障数量为导向，在测试的过程中为了提高故障数量，拼命地去寻找一些比较简单的，界面呈现不太一致的之类的故障，因为寻找这种故障的消耗的时间成本最低，却能够有效地提高自己的绩效。这种情况在刚刚入职的新员工身上体现地更为明显一些。因此，在项目的一段时期之内，出现了一种怪现状：开发人员提交一个功能，经过了几轮的系统测试，该功能稳定下来，然后将其投到工程中一使用，出现了很多的工程故障，给项目带来很多本来可以避免的客户投诉等负面效应。后来，项目才慢慢发现，这些功能在进入系统测试环节时，测试人员只是重视其提的故障数量而非质量，把大量的时间投入到测试一些容易发现的问题上面（去刷故障数量），最后的结果就是本来应当投入核心的业务测试的时间被大大压缩，导致了测试质量的低下，将不少的故障暴露到了工程上面。可惜的是，尽管项目发现了这个问题，却不知道由于什么原因，未对此种问题进行控制处理。

　　此外，这种测试方式不仅削弱了测试的质量，而且消耗了不少开发人员的时间。由于笔者所处在的项目比较大，整个团队有接近两百人，所负责的软件也是百万行级别的软件，再加上规划、需求和系统工程师的前期工作的质量问题（未能留下良好的需求、设计文档），造成了一种“测试人员以自己的主观判断为基准的测试方式”，测试人员只要是主观上认为此问题属于故障，就可以提交，而开发人员就必须去定位解决。有一些测试人员并未去参照需求或设计文档，且未与开发人员沟通确认就直接提交故障，这就造成了开发人员在收到故障单之后，首先需要确认此故障属于需求还是故障类的问题，如果是需求类的问题，还需要去找系统工程师去确认是否要修改，把需求变更的沟通过程加之于开发人员身上，大大地加大了开发人员的工作量。此外，测试人员有些主观性的观点，实质上并不能认为是故障，但由于开发人员到测试人员的反向反馈渠道建立地并不是很畅通（项目要求要拒绝一个故障必须与测试人员沟通确认过才能提交拒绝），这就出现了开发人员要与测试人员就一待拒绝故障互相扯皮，甚至僵持很久处理不了，还要去提交CCB进行分析处理，也在很大程度上加大了开发人员的工作量，从而间接地消耗了项目的人力和时间成本。

　　在上述案例中，一个显而易见的问题是由于测试人员的绩效考核机制的漏洞直接导致了测试人员投机于故障数量而不是质量，从而既削弱了软件的质量，又在一定程度上浪费了项目的开发人员的时间和人力成本。其次，测试人员本身的素质和业务水平也非常重要，如果这方面的素质能力较差，测试的质量也很难保证。最后，还有一个问题是项目开发流程的不规范，上游的需求设计文档的不完整性，测试流程的不规范（没有开发与测试均认可的标准），均在间接上产生了这种不良的后果。

　　然而，这种后果有的时候是以一种非显性的方式来出现的，因此，并未引起所有人的注意。但如果长持以往，其一定会对项目的正常进程产生不良的负作用。笔者认为，要想解决这个问题，首先要从源头上切断，对测试人员的考核不单纯要以故障数量为基准，而要将故障的质量纳入到考核范围之内，在考核中甚至要占据比故障数量还要大的权重。这样，就能够在一定程度上刺激测试人员去努力提高故障的质量，使得重大问题较早地暴露，降低项目的风险和成本；其次，要求测试人员将需求类问题和故障类问题分别提交，这样可以减少开发人员去斟别需求和故障的工作量，项目将需求类的问题纳入的以后的开发过程中，将故障类的问题提交开发人员修正；第三，开发和测试要达成故障的标准，二者都要以需求文档为基准，是否遵守需求文档为故障的基准，否则以需求类问题处理。这样，才可能有效地将案例中偏离正常质量保证轨道的测试人员拉回到保持软件的质量上面来，推动项目的有效进行。