人们经常还是喜欢纠缠在一些具体的数字上，特别是西方人更是喜欢用数据说明问题，因为那样客观、具体，但同时也往往将人引入歧途，容易形而上学，因为每个公司、公司的每个产品、产品的各个项目或各个阶段都不同，没法用一刀切的办法。在软件企业，面对测试经理，常常被问的问题是“你们公司的开发人员和测试人员的比例多少？”，如果你回答是“2：1”，得到的反应也许不同，对方可能会说：你们公司挺重视质量的，测试搞得不错啊！也可能会说：你们公司测试人员太多了，开发人员不怎么样吧？
软件企业中开发人员和测试人员的比例往往是管理者关注的一个问题，也可能是下面测试经理头疼的问题，似乎没有人知道什么样的比例是合适的。我曾写过一篇文章—— 测试人员与开发人员的比例究竟多少是合理的？，从各方面阐述这个问题。
幸好，倒是有个学者做个这方面的调查——Tester to Developer Ratio Initial Research Findings，因为这个想法也缠绕着他整整十年。他通过4个问题调查得到一些数据，可以供那些对此感兴趣的人参考。4个问题是：
1) 你的组织有多少开发人员?
2) 你的组织有多少测试人员?
3) 如果以1到 6这个范围来看, 其中1代表低， 6代表高，你给当前这个比率的有效性打多少分？
4) 关于当前这个比率的有效性有其它一些奇闻轶事吗？
调查结果显示：
- 测试人员最贫乏的：20个开发人员对1个测试人员 （但有效率比较低，是2）
- 测试人员最丰富的：15个开发人员对8个测试人员 （有效率比较高，是4）
- 也有一个异常数据：4个开发人员对0个测试人员（有效率是3）
- 平均比率是 4.52个开发人员对1个测试人员
- 最常见的情况是：3个开发人员对1个测试人员
- 其次是：2.5 个开发人员对1个测试人员
- 多数是开发人员与测试人员比率是3:1 或更低（即2.5:1 或 2:1 ）
有效性也是很重要的考量因素，因为虽然 开发人员和测试人员的比例是一种客观存在，比例过高或过低也许是可行的，但是否带来高质量的产品是重要的考量因素，或者说，是否严重影响企业的业务。所以，成功企业的开发人员和测试人员的比例常常更有说服力，这就是人们常常以微软、Google作为范例，见 测试人员与开发人员的比例究竟多少是合理的？中讨论。
从另个角度说，质量是构建的，从需求、设计到编码，只有每个环节做好了，质量才能上去。而且这些环节做好了，特别是开发人员进行了足够的单元测试，测试人员可以大大减少。如果更彻底一些，开发人员有足够强的责任心和良好的素质、能力，从项目开始就全面对质量负责任，开发人员不但杰出完成设计和代码，而且自己全面完成相关的单元测试、功能测试、性能测试、安全性测试，那么就不需要测试人员。也就是说，软件测试完全可以让有高度责任心的开发人员完成，虽然这样的开发人员在国内并不多见（在国外也不多见）。
提高开发人员:测试人员的比例，也有积极的一面，它会驱动产品设计人员、开发人员具有更强的质量主人翁精神，承担更多的责任，做好需求分析、设计，写好代码和充分地完成单元测试，提高各个阶段性成果输出的质量。要达到这样的目标，需要从管理层开始，具有相同的认识——如质量是构建的、软件产品的质量更大程度上取决于产品设计人员和开发人员，以整个团队改进质量和提高效率为宗旨，不断驱动产品设计人员和开发人员做好工作，领导持续改进的过程，最终整个团队是受益的。从这个角度看，“开发人员:测试人员的比例”问题不是向测试经理提出的挑战，而是向整个团队的挑战，更多地是向开发人员的挑战，即应该经常问开发人员：设计的重构经常做吗？为什么写出这么多的缺陷？根据缺陷分析的结果改进了代码规范？下一个版本每千行代码缺陷数可以降低30%~50%？单元测试覆盖率超过80%？......
再换个思路，如果像那样开发人员做测试人员的工作，合算吗？测试人员是少了，开发人员多了，整体开发的成本并没有降低，反而是成本提高了，又何苦去追求哪个3:1或4:1的数据呢？测试人员更多站在客户角度思考问题，对开发人员的互补作用也不可忽视。
软件开发最根本的就是质量和生产力。如果生产力不好衡量，就设法降低成本。一切有助于提高产品质量和生产效率的、实实在在的事，倒是我们要去做的。有时，数字倒不重要。