关于软件测试的几点反思 - 关于测试团队的组织

这一篇是系列文章的第三篇，前面两篇分别谈了测试的必需性（ http://blog.csdn.net/superqa/article/details/21406611 ），以及测试工作的一些内容（ http://blog.csdn.net/superqa/article/details/21485737 ），接下来想聊一下测试团队的组织。

要讨论这个话题，首先要讨论下测试人员本身的归属，因为通常是人多了才有组织的必要，很多东西都是一点点长出来的。
我在读研期间实习的一家公司，根本没有专职的测试人员，回头想想当时还是挺大胆的，因为做的是比较核心的系统，而且当时像我这种实习生都写了很多核心的涉及金额计算的代码，然后大家自测下就上线了。这种情况也持续了好久，也验证了不一定必需，在特定的情况下。

个人的工作经历，没有一开始去很小的研发组织。后面工作后的面试中，也接触过很多规模较小的公司的测试人员，这种情况下大部分是直接归属到项目，汇报给开发经理。人数少，大部分是比较基础的黑盒测试，相对也比较弱势。没有任何贬低的意思，但是客观来说，这个阶段的测试很难有一些比较深入的测试技术上的实践，时间不允许，也处于没有人带的情况，大家基本上都专注在项目的功能测试上面。一直觉得环境对人的影响是比较大的。有些比较有上进心的同学会自己学一些技术，但是因为没有指导，也没有实际应用的场景，通常比较浅。

后面等到整个研发体系发展大了之后，可能测试人员也慢慢多了起来，同时服务于多个开发小组，于是就出现了测试团队的二级组织。比如对口每个开发小组的有几个人，或者更多，然后有一个lead或者first line manager，然后这些人汇总到一个second line的manager。这个时候随着测试团队规模的壮大，当然也是随着整个研发组织的壮大，以及业务和开发方