在一些软件大会上，人们常常会问这样一个问题：测试人员与开发人员的比例究竟多少是合理的？而这样的问题，很难直接给出一个答案。为什么会有这样的问题，可能来自于两方面的压力：

   许多公司领导总是希望得到一个合理的比例，然后按这个比例分配招聘的名额，或者设法缩小测试队伍，减少开发成本。
多数情况下，测试人员工作量大，比开发人员忙，所以想寻求一个数据，来说服其公司，多招些测试人员。
有些专家说，根据调查结果发现通常的比例是1个测试人员对3个开发人员。实际上，这样的比例毫无意义。测试人员与开发人员的比例会受到很多因素的影响，因不同的业务、文化和产品而不同。如果不管公司的文化、产品的类型和责任定义等，一定要按照某个比例来分配测试人员与开发人员，这是武断的做法，缺乏科学性。有两个典型的例子能说明这个问题：

   微软公司的测试人员与开发人员比例一般为1:1，甚至在Windows 2000开发团队中，有1800个测试人员，900个开发人员，测试人员与开发人员比例为2:1。
   在Google (谷歌)公司，则测试人员与开发人员比例则很低，据谷歌公司的测试经理介绍，为1:10.
   那为什么呢？这里主要是测试人员与开发人员工作范围的定义，在这两家公司差别挺大，在微软，单元测试由测试人员（SoftwareDevelopment Engineer in Test， SDET）做， 相当于SDET再写一套代码来测试开发人员写的产品代码，其工作量不比开发人员低，另外，微软开发的产品都是比较复杂的操作系统、服务器软件等，自然需要很多的测试人员。而Google的单元测试和功能测试一般都是由开发人员自己来完成，测试人员主要提供自动化测试工具的支持。软件开发人员进行了足够的单元测试，单元测试的覆盖度高达85％以上，软件在交给测试人员时，在功能上基本没有缺陷，这样测试人员主要集中精力进行性能测试、负载测试、安全性测试等，而这些都是自动化工具来完成的，自然需要较少的测试人员。
 
另外，测试人员与开发人员还受所开发的产品类型、企业文化、项目环境、质量要求水平、开发人员或测试人员的自身素质等影响。例如：

     所开发的产品是操作系统、基础平台，和一般的客户端软件、简单的Web应用系统，其测试需求、范围和工作量都是不同的。如Windows操作系统要支持第3方各种应用程序、支持大量的API和各种硬件驱动程序等，还有兼容DOS、32位/64位等应用程序，系统非常复杂、用户操作也非常灵活，所以测试的工作量也大得多，需要大量测试人员的付出。
    软件设计、代码的质量，也是企业文化、开发人员的素质和能力等直接影响了软件的阶段性成果的质量，如果软件构造质量很高，其回归测试范围有限、重复测试的次数只有1～2次，而不是4～5次，结果，测试的工作量大大降低，测试人员数量随之降低。
例如，许多免费的网络应用产品总是将自己定位在Beta版，那么，会降低质量水平，让用户试用，并帮助发现一些缺陷（因为免费，用户也不能抱怨什么），这样的话，公司内部测试的努力会少多了。
    测试人员素质高，精兵强将，那么人数会少些；如果测试人员定位低、待遇低，可能靠人海战术，那么人数会多。
在敏捷方法中，开发人员的主导作用比较明显，测试人员对开发人员的比例会低些。如果采用测试驱动开发，测试人员对开发人员的比例会更低。这时，测试人员和开发人员的界限也变得模糊些。
    当然，针对一个具体公司，流程、产品和文化等都定型了，可以根据自己的经验、历史数据等，定出一个合适的比例，如1:2、1:3等，都是可以的。如果一个软件公司，硬要参考微软、谷歌或其它某个公司的做法，也许不合理。一定要找相似的公司，那家公司又做得很成功，那可以直接参考。
 
    也许将来某，测试人员和开发人员会合二为一，并没有明显的区分，只是每个人的任务会有所不同，大家都能胜任、完成某个任务中的测试和开发的工作。所以，作为测试人员，掌握良好的技术也是必要的，包括编程能力。