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

整体上有两种测试团队的模型，既然都有存在，自然是各有各的道理。城里城外的人倒不必互相羡慕，只是要观察对面的优点，分析自己的缺点，尝试做点事情补偿一下。

所以，下面多说一点各自的坏处。

独立的测试团队

这个就是著名的与程序团队打架的测试团队。

好处

独立团队，还是能保证一定的“公正性”的，比如在测试的最终，横竖有人能不屈从于程序团队的要求隐瞒产品质量，而是的确会客观地评价质量。

坏处

当测试团队完全独立于开发团队的时候，常常有几个误区。

1. 程序团队是用来开发功能的，测试团队是用来查找缺陷的

有了这个认识，要让两者打架就不难了。

2. 更多的测试人员=更高的质量

很多公司拥有惊人的测试人员比例，程序和测试基本上能到1：1，这个已经接近了造航天飞机的水平（50：80），但是质量……一般缺陷率都能达到航天飞机的一万倍左右。

1和2是互相促进的，一旦拥有了1的认识，程序团队就对质量不太在乎了，因为后面有人负责测试，有Bug漏掉还要承担责任，所以自己只管按自己的兴趣编写代码就是了；而留下的缺陷越来越多，自然就需要更多的测试人员来解决。

分散的测试团队

好处

每个团队都有测试人员，自然测试活动会被当作家里的事情来看待，有机会在很早的时候就启动测试活动；由于没有后继的测试活动了，也没有人可扯皮了，所以组内的测试活动的效果会比较好。

坏处

常常有这样几个误区。

1. 人员不能共享，测试人员不足

基本出发点，还是认为这几个测试人员是来帮助解决缺陷问题的，因此他们极有可能成为局部的捡垃圾者。

由于只能调用自己的测试人员，当然逐渐地几个人就不够用了，也需要更多的测试人员。

2. 缺少总体质量的把关者

由于所有测试人员都被当作小组的负责质量的人，产品最终所有模块集成在一起的时候，质量由谁负责，就成了个问题；集成后如何验证整体业务（而非技术），也是个问题。

F型测试团队

这是本人“次喜欢”的一种模型。

如果历史问题已经形成，或者说不可能拆分掉专业测试团队，可以考虑这个形状。

F的两个横线，代表分散的测试团队，就是整体上测试团队的人员在项目成立时，分别被指派到程序团队中，协助在早期就提升质量。

而竖线，则表明他们定期向测试经理报告各小组的的进展，分散到各小组的几个测试人员之间也可以频繁通气，以便做好集成准备；并在几个小组都完成了内部的工作时，很方便地接管集成和整体测试工作。

好处

是当团队使用敏捷开发的迭代交付的时候，这几个测试人员还是可以进行很好的持续支持的，比如完成一个版本，就测试一个版本。

由于他们长期在项目组内工作，而且定期通气，所以接管系统测试会变得非常顺畅。

坏处

这个模型有些矩阵式的团队的确在用，不过需要很好的管理，确切说是文化，才能做好。

个人感觉在操作这种团队的时候，整个大项目的经理（同时管理开发和测试的），必须要有很强的管理能力，并随时防止程序团队和测试团队分化。

实际上在很多时候，领导的作用都不再是管事，而是管人，就是如何管理好多个团队之间的关系。

小型测试团队

个人感觉最容易驾驭的团队。

比如有20个人，4～5个程序团队外加1个测试团队。

每个程序团队都各自负责自己的质量（不派驻测试人员），而那个测试团队则只负责业务层面的测试或称为验证，不负责质量。

好处

这种团队基本上是前面那个案例1（参考I和II）中的团队模型，由于当年的团队非常成功，所以非常推荐。

这种团队的集成活动是由开发团队和测试团队一起完成的，两者都为此负有责任；但完成集成后，由测试团队自己做系统级的业务测试。

整体上，是一种很“无我”的敏捷团队。

坏处

这种团队只在上面提到的那个公司见过一次，之后的团队似乎都没有采取这个形式的，表明这种形式不容易自然形成。

不过，鉴于当年的效果如此之好，本人一定会在自己未来的团队中采用这个模型。

而实际上每个公司，与其在那些很容易组建但同时很难做好的团队模型中挣扎，不如去尝试一下真正效果好的团队模型。

很多人都很希望找到一种很容易做到，效果又好的模型（以及任何其他东西）。如果这种模型存在，全国人民都别炒房了，都来开软件公司吧。