关于中小公司的测试组织与人力资源配备
首先讨论测试组织模型，整理一下常见的测试组织模型主要可以分为3种类型：
1、测试组织作为开发组织的一部分
这个模型的优点是：
Ø 唯一的优点是，当项目非常小人员很少的时候，这个模型可以降低开销，提高效率；
这个模型的缺点是：
Ø 测试服务于开发，测试不能独立的不受限制的完成客观的有意义的测试任务；
Ø 测试资源（包括人员、资金、工具、时间）受开发管理者的控制，不可能实现客观的正确的资源配置；
2、测试组织作为项目组织的一部分
这个模型的优点是：
Ø 测试服务于项目，项目管理者能够以比开发者更客观公正的立场处理开发与测试的关系；
Ø 测试管理者向项目管理者报告，发现的问题会得到更好的关注；
这个模型的缺点是：
Ø 项目管理者一般与开发管理者具有相同的议程和兴趣关注；
Ø 测试被作为项目资源的一部分，被项目管理者支配；
Ø 测试的资源可能得不到合理的利用，甚至得不到保证；
3、测试组织独立于项目
这个模型的优点是：
Ø 公司管理者会从公司利益的角度调整测试与项目的关系；
Ø 测试管理者向公司管理者报告，项目问题得到客观反映，产品质量可以得到充分关注；
Ø 测试资源可以得到较充分的保证，并会在项目中合理的分配；
这个模型的缺点是：
Ø 比起前两个模型，该模型的缺点不谈也罢；
从上面讨论的三种模型来看，当公司规模达到一定程度，同时有多个项目在进行，前两种模型肯定不适合，它们也会在不同程度上造成资源浪费，测试的客观公正性也会得不到保证。那么，第三种模型就成为必然的选择。这种模型也是目前国内外诸多公司正在采用的。
测试模型的确定会影响到资源的配置（包括人员、资金、工具、时间）和测试过程的组织。
资料显示，目前在一些比较著名的软件公司，一般测试人员与开发人员的配备比例从2:1——1:6这个范围内，有专业的测试组织负责测试任务。
这说明，如果想通过第三种模型实现公司的质量要求，不但要在组织结构上做到测试组织与项目团队相互独立，而且配备一定数量的专业测试人员是必要的。
然而，目前国内很多软件公司还做不到这样的投入，很多测试任务（如单元测试、集成测试）仍然由开发人员完成，测试人员只做系统测试。甚至于，系统测试也是由开发人员或者临时抽调的其他项目开发人员完成的。测试资源得不到满足，尤其测试人员配备不足，使得第三种模型很难实现，如果勉强实施，最终的结果很可能是测试组织失去对测试过程的控制能力，测试活动开展不起来，或者测试与开发的界限模糊，责任不清，回到原来的老路上去。
下面我们就讨论在资源（主要是指人员）不充分的条件下，测试过程的组织形式，以及如何配置资源。
假设，多个项目同时进行，测试组织负责所有项目测试任务，按照前面提到的配备比例，每个项目都会组成一个测试小组（该小组向测试组织报告）。如果测试组织的测试人员，即使不考虑技能条件，也不能满足前面的比例配备要求，最终为每个项目配备的测试人员可能很少，甚至没有，这样开展组织制定的测试活动可能根本无法实现。
因此，我们提出以下概念：
任务驱动式人员配备和组间协作式组织测试过程。
任务驱动式人员配备，要求测试组织根据各个项目情况，结合测试人员情况，为每个项目配备一个测试小组，测试人员与开发人员比例一般在1：10左右。在没有测试任务的情况下，测试人员可以被调到需要测试人员的测试小组。
所谓组间协作式组织测试过程，是在每个项目中，测试小组负责项目的测试任务，测试活动在测试小组的主导下开展，活动中需要或者部分需要开发人员的参与完成，参与测试的开发人员在测试组成立时确定。测试小组对开发人员有下达任务、工作结果审核的权力。
任务驱动式人员配备和组间协作式组织测试过程相结合，使测试人员/开发人员达到合理的比例，可以部分的弥补测试人员不足的情况，允许组织按照第三种方案实施测试。但是，这不能完全解决测试人员不足的问题，根本解决的办法仍然是配备足够的测试资源。
该方案是第三种模型的修改版，同样的也具备第三种方案的优点，同时他的缺点也很明显：
Ø 测试人员可能频繁在项目之间调动；
Ø 组间协作不能从根本上解决测试人员不足问题，参与测试的开发人员的技能不一定符合要求；
Ø 测试组织申请参与测试的开发人员，需要征得项目管理者的同意；
Ø 参与测试的开发人员是否能够按计划到位存在不确定因素，也可能为测试组与项目组保持良好沟通关系带来障碍。
