继续深挖一下开发测试比的问题。
如果一个公司说，我们今年的开发测试比要达到5:1，或者7:1，甚至10:1，目的是什么呢？
可能是为了缩短项目周期，节约交流成本，提高开发的质量意识，大家是否同意？
那么我们就这几个目的，谈一谈提高开发测试比是否能够达到这些目的。
首先，提高开发测试比，只是提高开发人员和测试人员的比例，并不是提高了开发工作和测试工作的比例，对不对？
测试工作花费的时间并没有因为开发人员做测试而减少，虽然在统计报表上是看不到了，因为没有要求过开发人员将开发时间和测试时间分开来记录。所以从表面上看，开发人员做测试也被归到开发时间里了。老大们就以为开发人员和测试人员的比例提高了，也就意味着开发工作和测试工作的比例提高了。这是一个直觉上的错误，或者说是统计时间没有做到位而造成的直觉错误。这点我相信只要和一线的开发人员或者测试人员沟通过，老大们就会明白这个道理。
其次，测试工作是否应该减少？这并不取决于测试效率或者测试工具，而是取决于bug带来的风险价值。开发测试比增加，如果指的是开发工作和测试工作的比例增加，势必带来的问题是，遗漏的bug数增加。那么，老大们需要评估的是，bug遗漏是否是在我们承受的范围之内。什么样的bug可以遗漏，什么样的bug不可以遗漏。并以此在各个不同的产品线和项目中定出合适的目标。
如果测试工作不应该减少，只是让开发人员多做测试，而让测试人员少做测试的话。从节约公司的成本、缩短项目周期上来说，是没有达到目的的。因为首先开发人员的工资通常比测试人员要高。其次，开发人员并不擅长测试，需要每个开发人员从一个有经验的开发人员再成长为一个有经验的测试人员，学习测试人员的工具和方法，需要一段痛苦的时间，而这段时间公司的花费是相当大的。并且需要开发的老大们全力的支持和推行才会见到成效。如果有有心人能够记录这些时间和花费，我相信那是一笔不小的数字。再可以和专职测试人员做测试做一个长期的对比。如果有这样的报表，老大们需要重新思考一下推行开发测试比的真实目的到底是什么。
那么我们再谈谈节约交流成本这个目的上。开发人员做测试，可以不需要再和测试人员做交流，表面上看节约了交流成本。但是，这样的交流是不是必要的呢？现在很多小项目或者日常，只有一个开发人员在做，开发人员是否正确地理解了需求，是否正确地实现了需求，是没有别的开发人员参与和验证的。如果再节省了测试人员参与测试的环节，那么有一个很大的风险就是开发人员根本就没有实现需求。我们做测试，很多bug并不是代码级别的，而是需求级别的，测试人员常常扮演着澄清需求，解决开发人员和产品经理之间的交流问题。所以，放弃测试人员测试需求理解的环节，对开发人员和产品经理的交流就提高了要求。而开发人员和产品经理交流不畅是目前工作中普存在的问题。这又需要公司去大力地推行一些措施去解决这些交流问题了。
最后一个目的，是提高开发的质量意识。我们有一个项目组推行了很长时间的开发自测，感觉最大的收获就是提高了开发的质量意识。我之前也是这样理解的，让开发来做测试，可以提高开发的质量意识，写出更好的代码。我当初接受去诺基亚做测试，也是抱着这样一个目的。我也听说有些部门让开发到测试部门轮岗，效果也很好。不过也有部门并不是通过让开发做测试来提高质量意识的。开发的老大重视质量，开发的质量意识就上去了。我也发现，有责任心的开发，并不需要做测试，也有很强的质量意识。其实，想提高开发的质量意识，有很多方法。Code review就是一个很好的办法。我最近开始给开发做code review，被review的那个开发表示压力很大，因为我看得太细，要求太高。他之前写代码的时候，有些地方其实是知道有问题的，但是因为有些偷懒或者项目压得紧，就对自己放松要求了，被我揪出问题后感觉很不爽。那我相信下次他就会用更谨慎的态度去写代码了。Nginx的作者就有代码洁癖，每一行代码都做得很漂亮，很严谨，都是最优的选择。这样的产品几乎是零bug的。我们也希望每一个开发都是这样的，但是事实总是和理想相距遥远。通过让开发做测试来提高质量意识，这是一个办法，但不是唯一的办法，也不是最好的办法。相反来说，会开发就会是一个好测试吗？真的也未必。因为测试代码级别的错误只是测试工作很小的一部分，为什么我总是提测试向前走，总是提测试更应该叫做QA呢？就是因为测试需要保障的不仅仅是代码，而是产品。一个产品，从需求、技术方案、编码到用户反馈，都是测试的范畴。一个好的测试，要了解他测的东西，无论是产品的定位、技术的架构，还是代码的质量，都是需要去保障的。所以，一个好的测试，需要是一个好的PD、好的架构和好的开发，这样他就可以在任何情况下说“不，你们不能这么做，这么做会导致......”。
我向来强调的是，我们不需要主义，我们需要解决问题。每一件事情，都需要说，我们为什么要这么做，我们这么做的目的是什么，我们能否达到这个目的。
所以，我非常疑惑于提高开发测试比这件事情，我不知道到底是什么目的，是否能够达到这个目的。我希望那些大佬们能够冷静地去想一想。作为一个好的测试人员，任何的改变都是需要可测的。这次也一样，提高开发测试比，需要更多的数据来说话，需要可测，需要测试驱动执行，需要各种不同的开发测试比对应的各种数据，我们才能说，提高开发测试比，好还是不好。
如果只是因为google和facebook这么做，那么去模仿是很危险的。成功永远是无法复制的。马云很成功，但是如果一个家长让自己的孩子像马云一样成长，也不会像马云一样成功。很多公司想学苹果，结果都摔得头破血流。阿里的成功也是无法复制的。因为你不知道那个导致成功的关键的因素到底是什么。没有人知道。
还是胡适那句话，多谈些问题，少谈些主义。世界上没有银弹，没有一种模式可以解决所有的问题。敏捷不是银弹，开发测试比也不是银弹。马云说过，互联网企业拼的是什么，拼的是管理。管理者最重要的素质是什么？就是不要相信有银弹。
本文出自：http://debbie.blog.51cto.com/2754849/1211102
相关链接：
