开发人员与测试人员比例

上周末去参加了第二届(杭州)互联网测试技术交流会,下午结束了以后有个小型的交流会,会中淘宝的郭芙在自我介绍的时候提出了一个问题,就是开发人员与测试人员比例多少才是合适的呢?这个话题引起了各位嘉宾们的踊跃讨论,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传统),人员素质在同一个水平,等等。。。在这些前提条件下,如果发现自己的所在的组织的效率不如其他公司,可以参考同行有什么好的实践,取其精华去其糟粕。

开发测试比例只是浮云,整个组织的效率才是关键。

4 thoughts on “开发人员与测试人员比例”

  1. 你好,我在写某个功能的测试用例计划的时候有一个疑问,想请教一下:是不是在设计测试用例的时候,要考虑到两个方面:实际需求与代码的实现原理?就比如说需求中对于因素A和B说都要满足,但代码设计中因素A和B并没有区别,是不是就不用分成因素A和因素B来进行测试了?

    1. 这个前提条件是不是这样:你现在是在做白盒测试,你能看到代码的。如果能看到代码,可以考虑不用区分因素A和因素B来设计。但是这样做会有风险。因为只是现阶段的实现里面A和B都是一个东西,可能过了几个版本以后,实现改了,把A和B分开了,那这时候就很容易漏掉了。所以还是应该以实际需求来设计,并且在了解代码实现的基础上*补充*测试用例。

  2. 嗯,谢谢,我之前一直是因为了解代码的实现逻辑,所以在测试的时候会根据代码来调整我的测试,今天觉得似乎错了,看了你的分析,我觉得豁然开朗了。

Leave a Reply

Your email address will not be published. Required fields are marked *