这是敏捷开发团队管理系列的第二篇。（之一）

　　测试团队的价值

　　这样看来，敏捷开发的质量保证问题，都被发开团队解决了，测试团队的价值何在？

　　这个可以从第一个项目组后来的发展来分析。

　　在整个程序团队大力保证产品质量的同时，项目组也一点点显露出一些问题。

　　比如每个模块的质量都还不错（有些模块甚至有一些原始的自动单元测试脚本，每次都能对模块进行回归测试），但是整个产品终集成后，是否能如期完成业务要求，却是未知的。因为各个模块的测试都集中在各模块的质量上，对于所有模块凑在一起的工作结果，却无法验证。而且在原来的团队体系下，师徒团队各自负责一个模块，居然没有人为此负责。

　　所以我们很需要一个人来团队里边，把整体集成及集成后的测试抓起来。这种工作，与其说是传统的面向质量的测试工作，不如说是一种面向验证的测试工作。是只要能告诉我们集成在一起是可以工作的，目的达到了。

　　测试团队的“发展”

　　这里边有很多戏剧性的过程。

　　首先过了一段时间，测试经理（虽然测试组当时只有2个人）想招几个人，原因是要写很多介于代码和脚本之间的语言，来仿真业务。

　　为什么说是仿真？原因是我们的产品之外，还有一个“订户管理系统”，这个系统的数据，是我们的业务。但由于他们部门的产品也在开发中，所以我们不得不先手工形成一些仿真业务。

　　这个问题，后来被开发组的人解决了。因为他们编写了一个文本的脚本语言，只需要手工写一些人眼很容易看懂的英文缩写和数字，能仿真一些业务。

　　这个脚本语言及其编辑、调试器后来越做越复杂（但因为开发它的开发人员对内部业务很熟悉，所以只花费了前后2周左右的时间），能够自动运行、单步运行、设置断点调试。

　　有一次，两个测试人员在2天里用脚本编辑器编写了144个测试用例，每个测试用例包含5～128个购买和分组行为，来仿真和测试他们认为可能的各种排列组合。这些测试用例不是我们常常遇到的写在Word或Excel里边的那种，而是用那个脚本编辑器打开，按F5，会自动执行并吐出结果的那种。

　　这个工作如果由人力来完成，无论是编写测试用例，还是执行以查看结果，都是几乎不可想象的。

　　两个测试人员有一次希望大干一番，以便验证一些不是有意构建的用例是否可以通过测试。但终结果是，这个编辑器和调试器后来被发展成能自动生成测试用例，乃至将用例发给真实机顶盒+IC卡系统和一个仿真的机顶盒+IC卡系统（一个友好的可以F5调试的VC++系统），如果发现区别则自动记录，并继续产生下一个用例。

　　这段代码因为走的时候没有留下文档而失传了，不过在7年后的一次老同事聚会中了解到，团队在后续的几年中按照这个原理，把很多不同层次的硬件（数字电视里边的，大约有10种之多，个个都是黑底绿字乃至干脆没有屏幕的，非常难缠）都做了纯软件仿真，每个模块做好了，都可以扔进去和仿真硬件集成一番，这些工作大大缩减了后真枪实弹时候经常出现的莫名其妙的问题，大大缩减了集成和测试时间。

　　这些程序人员的工作成果，保证了在团队有25人的时候（峰值曾经到达30人），只要两个测试人员能完成整个系统的功能测试，这个团队发展十分“缓慢”；但是从另外一个角度看，那些为测试团队编写测试代码的人，到底算是开发人员还是测试人员呢？

　　启示

　　一个的团队，应该受到关注的应该是质量的高低问题、集成的效率问题、功能验证的效率问题……这些有人买单的问题，而不是开发与测试的分工、如何明确责任、如何对双方进行绩效考核等没人买单的问题。

　　所以尽管2001年那个时候敏捷开发的概念还不太清晰，但是本着“无我无人”的精神（详见般若敏捷系列之四），很自然地创立了自己的敏捷方法。

　　这件事情让我回忆起近正在与很多业界人士合著一本“敏捷开发案例集”，中间有一个讨论时：“到底什么案例是敏捷案例，什么案例不是敏捷案例？”

　　后的结论是：“第一个很松：大致有点和敏捷沾边行；第二个很严：开发方法一定要被证明是的”，换言之如果大家对的开发方法视而不见，而到处找“敏捷开发方法”，是舍本逐末了。

　　下一篇，将谈及开发团队和测试团队的组织关系问题，比如专业的测试团队好，还是分散到开发团队中的测试团队好，抑或还存在其他的组织结构等。