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

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

　　要讨论这个话题，首先要讨论下测试人员本身的归属，因为通常是人多了才有组织的必要，很多东西都是一点点长出来的。

　　我在读研期间实习的一家公司，根本没有专职的测试人员，回头想想当时还是挺大胆的，因为做的是比较核心的系统，而且当时像我这种实习生都写了很多核心的涉及金额计算的代码，然后大家自测下就上线了。这种情况也持续了好久，也验证了不一定必需，在特定的情况下。

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

　　后面等到整个研发体系发展大了之后，可能测试人员也慢慢多了起来，同时服务于多个开发小组，于是就出现了测试团队的二级组织。比如对口每个开发小组的有几个人，或者更多，然后有一个lead或者first line manager，然后这些人汇总到一个second line的manager。这个时候随着测试团队规模的壮大，当然也是随着整个研发组织的壮大，以及业务和开发方面提出了更多更高的质量要求，测试团队在客观上有了进一步提升的需求。主观上因为second line的出现，会不再满足于完成基本的测试工作，也有提升的动力。一些测试的规范，用例设计，缺陷管理，数据的分析，工具平台的引入，自动化的开展等慢慢开始引入。

　　接下来，可能到研发部门层面有一个完整的测试团队，进而可能是整个公司，或者事业部(BG，BU)层面有一个完整的测试部门，或者中心。

　　目前看到的腾讯和阿里的几个大的业务导向的事业部都是这样的情况，比如腾讯的互联网，互动娱乐，电商(曾经);阿里的淘宝，天猫和支付宝，都是在事业部层面有一个完整的测试团队。

　　进一步，如果这类很大型的公司，把全集团的测试集中到一起的还没看到，主要是因为组织架构的顶层还是按业务来划分的，比如事业部制。

　　基于上面的讨论，我们可以从测试的集中这种角度来看看测试团队的情况，这样划分就有两种，集中还是不集中。

　　集中的例子就是上面说的情况，所有专职测试人员都在一个小组，一个大的二级组，进而一个中心，一个部门，数据结构上是一颗树。非集中的情况就是测试人员散落在不同的开发中心，或者开发组，是一个森林。每一块的测试人员组成一个小组，汇报给开发中心的总监，或者开发经理。 目前了解到不少公司是这样来组织的。

　　每一种组织方式都是结合了公司的实际情况和要求，但是如果单纯从测试团队的价值和效率方面，目前来看，会觉得集中到一起是个更好的方式，主要的理由是下面几点。

　　1. 集中到一起之后，因为资源的整合，可以减少各个团队的重复建设，集中来做一些平台建设，技术研究，或者横行的技术共享，有利于提升团队的技术深度。

　　2. 从业务的角度，集中后测试可以横向的对齐，来看各个项目的质量情况，研发流程的过程执行和效率的情况。从整个组织的角度，对研发的质量和效率有促进的作用。

　　3. 从测试人员个人发展的角度，因为整个测试组织有了更好的深度，个人发展的空间也会更大，无论技术还是管理方面。

　　4. 测试人员的归属感，有自己的部门和自己的职业发展通道。

　　谈到和项目的对应，目前采用测试集中方面的团队也基本上是矩阵式管理，特别是针对负责业务测试的小组。一方面，从组织架构上是归属于质量部或者质量中心，但是从日常工作上，是归属到项目或者产品，和对应的产品、开发团队密切配合，包括座位可能都在一起。

　　就目前观察的情况来看，这种组织架构相对是比较成熟，也比较普遍被采用的，运作起来也还比较顺畅。

原文转自：http://blog.csdn.net/superqa/article/details/21966881