在项目进行中，测试工程师、项目经理和开发人员的合作通常有两种形式。一种是相互交叉的，交叉的地方有大有小。在单元测试中，要提高产品质量的话，需要开发人员也参与测试工作，项目经理也提供相应的支持，进行各种资源的调配。这种情况更注重合作，是由三方共同进行参与的过程，大家彼此都是平等的地位。测试架构师需要关注项目经理、开发小组和项目相关外部人员之间合作和各自工作的各个过程，找出哪些需要继承，哪些需要优化和提高。

　　另外一种形式是由测试人员来驱动整个项目的过程，然后由项目经理、开发人员和外部相关人员进行各种合作，大家各司其责，整个工作是由测试人员来负责进行协调。测试人员编写代码验证的工具，希望开发人员和外部合作人员在Check in他们的代码之前，使用这个工具来确认他们的代码是符合要求的。项目经理在协调整个小组的各项资源的时候，受到测试人涡对代码要求的影响，从而影响到所有的成员。这种关系是驱动合作的关系，而不是管理的关系。测试架构师在其中不仅需要对所有的测试人员编写的工具进行监控，更要对这种驱动关系进行很好的推进，以测试角度的需要和要求控制项目的进行。

　　软件测试架构师有时候总是称自己为传道士，把他们做的工作称为在为相关的其他部门布福音。

　　以何浪飞所在的MSN部门为例，这个庞大的部门包含了50多个产品小组，并且都有自己成型的组织架构，并且每个产品组，每隔6个月都需要发布一个产品的版本，想要改变他们工程流程上的一些细节，都是非常困难的。在这样庞大的机构中要想推进某个优化流程的工具更是难上加难。首先在每个部门中少有这样专门用于配合推行这项工具的人员，并且确实存在有怀疑这些工具是否能够改进他们现有工作状态的人存在。这个时候要MSN部门中50多个产品组，随时达到接受改进的佳状态，非常不易。

　　这个时候需要这些软件测试架构师去对这50多个产品组一一走访，去了解他们的状况。因为每个小组的现实情况和需要都不同，也许测试架构师推行的工具虽然很好，但是每个小组可能使用的方法不同，遇到的问题也不同，他们需要去倾听没有使用或者没在达到预想效果的这些原因，帮助这些人去适应这些工具实现顺利过渡，或者对工具做些相应的修改。

　　通常在推进策略上也采取一些渐进的方法，何浪飞他们称之为“农村包围城市”。他们通常先去解决那些积极提供支持和合作的部门，然后去解决消极抵触的部门，后去解决那些年头比较长、阴力比较大、现成和历史东西比较多的产品部门。这个时候大多数部门都已经接受，并且开始有成效，他们的工作逐渐被认可，那些之前难接受的部门也慢慢容易接纳所推行的工具了。这些软件测试架构师这样去为整个工作搭建平台，让大家在一个公共环境中去做工作，节省成本和提升整个工作组的工作效率。

　　另外很多测试工作通常需要自动化，在其中需要有什么样的测试推进、测试需要有哪些步骤、需要哪些点进行测试等这些工作需要有技术过硬又对产品有整体把握的人来进行，这些都属于软件测试架构师的工作范围。他们不仅对于测试相关的工作需要深入把握，还在对于整个团队工作的本身流程优化和整合做出很大的贡献。同样用何浪飞所在的部门为例，其中的哪些测试架构师历经很长的时间，为相关的工作人员搭建了一个平台，方便大家的合作工作。现在他们的平台可以让开发人员把代码自动Check in，由Build Lab产生一个Build，并且自动在Lab里进行测试工作，并将结果保存到一个数据库中。开发人员通过平台提供的网站可以看到结果，立刻知道哪些代码通过了测试，哪些没有通过，从而可以决定这个Build能不能发布，值不值得做更多的测试，或者还需要进一步做哪些工作。节省了测试人员很多查找常规Bug和验证测试结果的时间，也方便了测试人员和开发人之间的沟通，节省了大量的时间和人力。在更高的产品线上工作的测试架构师，涉及到的平台更加庞大，他们通常需要给客户一个解决方案，到数个产品，需要去解决不同产品甚至是产品线之间是否可以进行有效的工作的问题。例如微软很多产品都需要进行.NET Passport的身份验证，当Messenger增加一个功能的时候，它的验证是否可以同Office里新增的身份验证进行合理和有效的信息互通都是测试架构师需要去解决和优化的事情。所以，测试架构师的大部分工作都是在决策和优化整个产品线，或者跨产品线、平台的工作以及合作工作的流程。

　　这些时候，测试架构师的工作往往涉及到很多的部门和角色。然而由测试架构师提供的工具、方法和要求往往对于其他相关人员来说，只是第二位的，因为虽然这些对于整个项目以及部门都有很大的益处，但是对于每个人来说自己的工作才重要。这个时候需要测试架构师对项目经理和管理人员产生必要的正面影响，然后由他们将这种影响传递给参与合作的人员，从而达到影响到所有人。决策、协调和组织是他们的工作主题。