在不同的公司，测试工程师不仅进行测试的内容不同，对于缺陷定位的深度以及测试的范围等指责的划分都有着很大的不同。比如说在一些公司，测试工程师进行的仅是动态黑盒测试，发现bug以后直接提交报告，由开发人员去做bug-fix，而在另外一些公司，测试工程师进行的除了黑盒测试之外，还有静态、动态白盒测试。那么在新成员加入这个团队时，测试经理要明白的告诉他们他们的测试内容、定位深度等职责范围。至少，对于聪明的项目管理人员来说，当团队面临大量任务时，应该针对测试团队当前的处境采用适当的测试策略并让每位团队成员知道这是当下测试团队所遵循的共同标准。对于人手紧缺的中小规模公司来说更是如此。一般地，大公司有着比较充裕的人力资源和成熟的运作模型来进行项目管理，也就是说有相对固定的一些人力去做特定的工作。而对中小公司来说，如果能用有限的人力去完成更多的工作，则意味着在项目的不同时期部分人员的角色需要转换。

　　比如在软件研发过程中，测试环节与开发环节在时间上总有着一定的滞后。除非开发和测试部门都生活在理想的软工乌托邦中，大家都严格按照软件工程的理论去部署每一步工作;而且客户有很足的耐心等待你完成一个质量有保证的产品周期(通常这样一个周期中你的竞争对手都会推出质量不敢保证但可以吸引客户的样品)。现实中很多情况下产品开发过程中并没有严格的SPEC，甚至连项目经理都不敢确定的说这个产品发布时会是怎么怎么样的，而且开发过程中可能还会不断的增加新的特性。这时所谓的开发测试协同就生长成了真正的幻想。这种情况下，需要测试团队更为积极的参与到开发环节中以增加对产品和特性的熟悉程度。

　　此时针对测试团队就需要定义两种用人策略并不断的调整现阶段采用何种策略：紧的用人策略和松的用人策略。紧的用人策略是仅从部门职责划分的角度完成分内的事，更多的完成工作量，进而完成在职责划分上测试团队应该完成的工作;松的用人策略则除了完成测试工作意外，扩大测试内容的范围和定位的深度，并尽可能的参与到开发过程中，帮开发人员做一些工作，从而达到熟悉产品的目的。这样，在分工明确的情况下，采用紧的用人策略能保证及时的完成工作量;而采用松的用人策略能在产品尚未交付以前增加产品熟悉程度，甚至，增加开发和测试团队之间的了解程度和信任度。

　　上述想法，也不仅是基于公司规模的考虑;还有团队成员对项目熟悉程度的考虑。比如在多家公司同时协作推进一个新产品的诞生时，这种策略同样适用于其中任意一家公司的测试团队。在功能尚未完成时，测试团队可以采取松的用人策略，测试人员可以利用这段工作量不大的阶段更多的了解产品，熟悉开发团队，而开发人员这时能够把一部分简单的工作交给测试人员，并共享一些文档;而在产品交付后，采用紧的用人策略，保证工作量的按时完成，开发人员则因为产品的交付而开始有足够的精力放在进一步定位bug，开发和提交bug-fix这件事情上。

　　但最好的，还是能够在产品原型阶段就着手指定严格的产品SPEC。甚至，更早。