软件开发人员与软件测试人员比例

　　上周末去参加了第二届(杭州)互联网测试技术交流会，下午结束了以后有个小型的交流会，会中淘宝的郭芙在自我介绍的时候提出了一个问题，就是开发人员与测试人员比例多少才是合适的呢?这个话题引起了各位嘉宾们的踊跃讨论，infoQ的泰稳整理了这次讨论(推荐看1楼回复)，我也想谈谈自己的一些看法。

　　其实算上实习，我已经在4个公司工作过了，回头来看看这些公司研发团队的开发测试比例，从一个小职员的角度。

　　第一个公司是一家年收入10亿美元的百年老店，传统软件企业，在那里，开发和测试的比例大概是3:1。作为一个传统的软件企业，这家公司的自动化测试在那时候(2006年)才是刚起步，公司内部有较为规范的流程，QA在公司里面的工作大概就是从需求文档开始到各种设计文档进行review，之后dev开始写code，这时候QA也开始写测试用例，当时用的是QC。写好以后QA会review用例，然后就开始执行用例(真的是step by step，不夸张)。一个人一天如果能执行完40个用例，那是相当的高效率。3:1这个比率，看上去挺正常，但是其实QA做的工作并不多，总的来说QA的工作效率不是很高。在自动化测试程度不高的情况下，要保持产品质量，所以需要更多的QA来达到这个要求。我个人认为3:1的比率有点高。

　　之后在一家做统计分析的美资企业实习过一段时间，这个公司现在已经被IBM收购鸟……在这个公司，开发和测试比大概是2:1。QA的工作主要是阅读设计文档，设计测试用例，执行测试。同样，我觉得这个公司跟之前那个公司有着相同的问题，自动化测试程度不高，但是产品的质量要求非常高，所以需要更多人力物力在QA团队，而且由于各种各样的问题，团队的效率好像不是非常高。所以2：1这个比率有点高，但是其中是有他的原因的。

　　在MySpace，我们的开发测试比大概是5:1，互联网公司，要的就是一个快字，所以对产品的质量不需要很高，有Bug没关系，只要改的快就行了，抢在竞争对手前把产品发布出去才是根本。那时候基本上是一个人负责一个项目，一个项目可能持续2~3个月，完了以后继续第二个项目，QA要做的事情是，在拿到产品的设计文档以后，跟开发一起开会做设计，做测试用例，测试，上线，回归。我做的是后台的测试，所以我这边其实是4个开发写的代码给我1个人测试，那些接口测试用例其实都是自动化的(VSTS的mstest)。所以工作基本能很好完成。在这个互联网公司，有互联网的血统(快)，但是对产品的质量要求也不低，QA做的工作比较细(其实主要是要经常性地在IE6的样式上纠结)。在自动化测试开展的还可以的情况下，比率是5:1。

　　终于到FreeWheel了，首先说一下我们的开发测试比，1.2:1，具体说就是12个开发对10个测试。说一下那么多QA都是干嘛的呢?QA的工作主要是拿到PM的设计以后，参与开发的设计，之后设计用例，测试，把测试转化为自动化回归测试(其实很方便的);解答客户遇到的各种问题(为什么我的广告没出来，我想要XXX的数据，等等)。我个人觉得这套服务的特点是(相对于其他系统来说)商业逻辑非常复杂，软件本身的复杂度相对商业逻辑来说较低。据我的工作的体会，DEV很少会出现比较低级的bug，出现bug的地方大多数都是在商业逻辑上，说白了这是一套business driven的系统，客户需求是第一位，如果他说要一个算法，要1+1=7的，都是要实现的。所以QA在看需求的时候需要看的非常细，所以就需要更多的QA，并且会花比较多的时间去解决客户遇到的问题。

　　这个开发测试比，基本上每家公司都是不一样的。这个原因有很多，公司传统，领导风格，人员素质，工作内容，等等……如果离开了当前公司的这个Context去谈开发测试比，并没有太多的意义。就譬如说两家公司的开发测试比都是3:1，但是其中一家公司的可能很糟蹋，另一家很高效。谈这个开发测试比例，最好是在相同的类型的公司(创业型VS大公司)，相同的行业(互联网VS传统)，人员素质在同一个水平，等等。。。在这些前提条件下，如果发现自己的所在的组织的效率不如其他公司，可以参考同行有什么好的实践，取其精华去其糟粕。

原文转自：http://www.ltesting.net