整体上有两种测试团队的模型，既然都有存在，自然是各有各的道理。城里城外的人倒不必互相羡慕，只是要观察对面的优点，分析自己的缺点，尝试做点事情补偿一下。
所以，下面多说一点各自的坏处。
独立的测试团队
这个就是著名的与程序团队打架的测试团队。
好处
独立团队，还是能保证一定的“公正性”的，比如在测试的最终，横竖有人能不屈从于程序团队的要求隐瞒产品质量，而是的确会客观地评价质量。
坏处
当测试团队完全独立于开发团队的时候，常常有几个误区。
1、程序团队是用来开发功能的，测试团队是用来查找缺陷的
有了这个认识，要让两者打架就不难了。
2、更多的测试人员=更高的质量
很多公司拥有惊人的测试人员比例，程序和测试基本上能到1：1，这个已经接近了造航天飞机的水平（50：80），但是质量……一般缺陷率都能达到航天飞机的一万倍左右。
1和2是互相促进的，一旦拥有了1的认识，程序团队就对质量不太在乎了，因为后面有人负责擦屁股，并为擦不干屁股而承担责任，所以自己只管按自己的兴趣编写代码就是了；而留下的缺陷越来越多，自然就需要更多的测试人员来解决。
分散的测试团队
好处
每个团队都有测试人员，自然测试活动会被当作家里的事情来看待，有机会在很早的时候就启动测试活动；由于没有后继的测试活动了，也没有人可扯皮了，所以组内的测试活动的效果会比较好。
坏处
常常有这样几个误区。
1、人员不能共享，测试人员不足
基本出发点，还是认为这几个测试人员是来帮助解决缺陷问题的，因此他们极有可能成为局部的擦屁股者。
由于只能调用自己的测试人员，当然逐渐地几个人就不够用了，也需要更多的测试人员。
2、缺少总体质量的把关者
由于所有测试人员都被当作小组的负责质量的人，产品最终所有模块集成在一起的时候，质量由谁负责，就成了个问题；集成后如何验证整体业务（而非技术），也是个问题。
