微软是怎样做测试的(三)

测试架构师（Test Architect）是在微软内测试技术人员技术发展方向的最高职位。其实在4、5年前，微软是没有软件测试架构师这个职位的。测试人员发展到最高级别就是测试主管，然而这是偏管理方向的发展道路。对于那些钟爱技术又十分优秀的测试人员来说缺少这方面的职位发展目标。后来在测试工作的长期发展过程中，需要有人去做整个产品在测试方面的推进工作。慢慢地，随着担任此项工作的人越来越多，软件测试架构师这个职位定位和概念渐渐清晰起来。
那么对于这要一个职位，都需要具备什么样的素质和特性呢？
坚持、有毅力、在逆境的时候要能坚持自己的想法和做法。以ATC软件测试经理何浪飞为例，在成为软件测试架构师（Test Architect）之前，他就是这样坚持，并且曾经为了一个大家都觉得并不那么重要的Bug，历经周折来为这个小Bug“正身”。
这个既不会返回错误又不会造成Down机的小小Bug只是在注册表中某个值的默认设置上可能会给一些初级用户带来不便，让他们不知道该如何正确地使用这个值相关的功能。何浪飞当时所在的测试小组中包括那些有20年以上经验的员工，几乎所有人都因为这个Bug造成不便的几率只是可能，所以认为它还到不了必须要去修订的程度，而加入这个测试小组不到2年的何浪飞却坚信改进它非常必要。既然问题出在可能会让用户感到不便，那么用户的反馈将是进行验证的最好证据。于是他找到负责相关产品支持的人员，查找该产品用户反馈问题的Top 10列表，发现自己坚持需要修订的Bug就在其中。在了解了解决问题所带来的人员支持等所花费的时间和各项费用之后，何浪飞的意见终于被大家欣然采纳，很快修正了那个Bug。
站在用户的角度上审视产品，相信自己，并且要用例证说话。这是要达到测试工作技术领域的最高级别――软件测试架构师所必需具备的。在微软，很多领域都有很强的竞争对手，大家需要付出很长时间的努力，然而也许需要5年才能超过他们，这个时候在市场上很长一段时间都不会有比较明显的表现，所以特别需要给自己信心，相信自己做的工作。在项目组里也是，也许观点大家都不同意，但是如果在分析了事实之后，觉得自己是正确的，就需要坚持，而不是简单屈从大多数和经验深厚的人或者是领导的决定。
然而，要成为软件测试架构师，仅凭这些还不够。因为他们的很多工作都需要和项目经理、开发人员以及项目外部相关人员互相协调和合作，在沟通和影响力传递的方面也需要有很高的造诣。
那么测试架构师在和项目经理、开发人员以及项目相关的其他外部人员之间如何协调进行工作呢？
在项目进行中，测试工作师、项目经理和开发人员的合作通常有两种形式。一种是相互交叉的，交叉的地方有大有小。在单元测试中，要提高产品质量的话，需要开发人员也参与测试工作，项目经理也提供相应的支持，进行各种资源的调配。这种情况更注重合作，是由三方共同进行参与的过程，大家彼此都是平等的地位。测试架构师需要关注项目经理、开发小组和项目相关外部人员之间合作和各自工作的各个过程，找出哪些需要继承，哪些需要优化和提高。
另外一种形式是由测试人员来驱动整个项目的过程，然后由项目经理、开发人员和外部相关人员进行各种合作，大家各司其责，整个工作是由测试人员来负责进行协调。测试人员编写代码验证的工具，希望开发人员和外部合作人员在Check in他们的代码之前，使用这个工具来确认他们的代码是符合要求的。项目经理在协调整个小组的各项资源的时候，受到测试人涡对代码要求的影响，从而影响到所有的成员。这种关系是驱动合作的关系，而不是管理的关系。测试架构师在其中不仅需要对所有的测试人员编写的工具进行监控，更要对这种驱动关系进行很好的推进，以测试角度的需要和要求控制项目的进行。
软件测试架构师有时候总是称自己为传道士，把他们做的工作称为在为相关的其他部门布福音。
以何浪飞所在的MSN部门为例，这个庞大的部门包含了50多个产品小组，并且都有自己成型的组织架构，并且每个产品组，每隔6个月都需要发布一个产品的版本，想要改变他们工程流程上的一些细节，都是非常困难的。在这样庞大的机构中要想推进某个优化流程的工具就更是难上加难。首先在每个部门中少有这样专门用于配合推行这项工具的人员，并且确实存在有怀疑这些工具是否能够改进他们现有工作状态的人存在。这个时候要MSN部门中50多个产品组，随时达到接受改进的最佳状态，非常不易。
这个时候就需要这些软件测试架构师去对这50多个产品组一一走访，去了解他们的状况。因为每个小组的现实情况和需要都不同，也许测试架构师推行的工具虽然很好，但是每个小组可能使用的方法不同，遇到的问题也不同，他们需要去倾听没有使用或者没在达到预想效果的这些原因，帮助这些人去适应这些工具实现顺利过渡，或者对工具做些相应的修改。
通常在推进策略上也采取一些渐进的方法，何浪飞他们称之为“农村包围城市”。他们通常最先去解决那些积极提供支持和合作的部门，然后去解决消极抵触的部门，最后去解决那些年头比较长、阴力比较大、现成和历史东西比较多的产品部门。这个时候大多数部门都已经接受，并且开始有成效，他们的工作逐渐被认可，那些之前最难接受的部门也就慢慢容易接纳所推行的工具了。这些软件测试架构师就这样去为整个工作搭建平台，让大家在一个公共环境中去做工作，节省成本和提升整个工作组的工作效率。
另外很多测试工作通常需要自动化，在其中需要有什么样的测试推进、测试需要有哪些步骤、需要哪些点进行测试等这些工作需要有技术过硬又对产品有整体把握的人来进行，这些都属于软件测试架构师的工作范围。他们不仅对于测试相关的工作需要深入把握，还在对于整个团队工作的本身流程优化和整合做出很大的贡献。同样用何浪飞所在的部门为例，其中的哪些测试架构师历经很长的时间，为相关的工作人员搭建了一个平台，方便大家的合作工作。现在他们的平台可以让开发人员把代码自动Check in，由Build Lab产生一个Build，并且自动在Lab里进行测试工作，并将结果保存到一个数据库中。开发人员通过平台提供的网站可以看到结果，立刻知道哪些代码通过了测试，哪些没有通过，从而可以决定这个Build能不能发布，值不值得做更多的测试，或者还需要进一步做哪些工作。节省了测试人员很多查找常规Bug和验证测试结果的时间，也方便了测试人员和开发人之间的沟通，节省了大量的时间和人力。在更高的产品线上工作的测试架构师，涉及到的平台更加庞大，他们通常需要给客户一个解决方案，到数个产品，需要去解决不同产品甚至是产品线之间是否可以进行有效的工作的问题。例如微软很多产品都需要进行.NET Passport的身份验证，当Messenger增加一个功能的时候，它的验证是否可以同Office里新增的身份验证进行合理和有效的信息互通都是测试架构师需要去解决和优化的事情。所以，测试架构师的大部分工作都是在决策和优化整个产品线，或者跨产品线、平台的工作以及合作工作的流程。
这些时候，测试架构师的工作往往涉及到很多的部门和角色。然而由测试架构师提供的工具、方法和要求往往对于其他相关人员来说，只是第二位的，因为虽然这些对于整个项目以及部门都有很大的益处，但是对于每个人来说自己的工作才最重要。这个时候就需要测试架构师对项目经理和管理人员产生必要的正面影响，然后由他们将这种影响传递给参与合作的人员，从而达到影响到所有人。决策、协调和组织就是他们的工作主题。