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

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

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

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