这一篇是系列文章的第三篇，前面两篇分别谈了测试的必需性《关于软件测试的几点反思 - 测试是必需的吗？》，以及测试工作的一些内容《关于软件测试的几点反思 - 测试工作的三个阶段》，接下来想聊一下测试团队的组织。
要讨论这个话题，首先要讨论下测试人员本身的归属，因为通常是人多了才有组织的必要，很多东西都是一点点长出来的。
我在读研期间实习的一家公司，根本没有专职的测试人员，回头想想当时还是挺大胆的，因为做的是比较核心的系统，而且当时像我这种实习生都写了很多核心的涉及金额计算的代码，然后大家自测下就上线了。这种情况也持续了好久，也验证了不一定必需，在特定的情况下。
个人的工作经历，没有一开始去很小的研发组织。后面工作后的面试中，也接触过很多规模较小的公司的测试人员，这种情况下大部分是直接归属到项目，汇报给开发经理。人数少，大部分是比较基础的黑盒测试，相对也比较弱势。没有任何贬低的意思，但是客观来说，这个阶段的测试很难有一些比较深入的测试技术上的实践，时间不允许，也处于没有人带的情况，大家基本上都专注在项目的功能测试上面。一直觉得环境对人的影响是比较大的。有些比较有上进心的同学会自己学一些技术，但是因为没有指导，也没有实际应用的场景，通常比较浅。
后面等到整个研发体系发展大了之后，可能测试人员也慢慢多了起来，同时服务于多个开发小组，于是就出现了测试团队的二级组织。比如对口每个开发小组的有几个人，或者更多，然后有一个lead或者first line manager，然后这些人汇总到一个second line的manager。这个时候随着测试团队规模的壮大，当然也是随着整个研发组织的壮大，以及业务和开发方面提出了更多更高的质量要求，测试团队在客观上有了进一步提升的需求。主观上因为second line的出现，会不再满足于完成基本的测试工作，也有提升的动力。一些测试的规范，用例设计，缺陷管理，数据的分析，工具平台的引入，自动化的开展等慢慢开始引入。
接下来，可能到研发部门层面有一个完整的测试团队，进而可能是整个公司，或者事业部（BG，BU）层面有一个完整的测试部门，或者中心。
目前看到的腾讯和阿里的几个大的业务导向的事业部都是这样的情况，比如腾讯的互联网，互动娱乐，电商（曾经）；阿里的淘宝，天猫和支付宝，都是在事业部层面有一个完整的测试团队。
进一步，如果这类很大型的公司，把全集团的测试集中到一起的还没看到，主要是因为组织架构的顶层还是按业务来划分的，比如事业部制。
基于上面的讨论，我们可以从测试的集中这种角度来看看测试团队的情况，这样划分就有两种，集中还是不集中。
集中的例子就是上面说的情况，所有专职测试人员都在一个小组，一个大的二级组，进而一个中心，一个部门，数据结构上是一颗树。非集中的情况就是测试人员散落在不同的开发中心，或者开发组，是一个森林。每一块的测试人员组成一个小组，汇报给开发中心的总监，或者开发经理。 目前了解到不少公司是这样来组织的。
每一种组织方式都是结合了公司的实际情况和要求，但是如果单纯从测试团队的价值和效率方面，目前来看，会觉得集中到一起是个更好的方式，主要的理由是下面几点。
1. 集中到一起之后，因为资源的整合，可以减少各个团队的重复建设，集中来做一些平台建设，技术研究，或者横行的技术共享，有利于提升团队的技术深度。
2. 从业务的角度，集中后测试可以横向的对齐，来看各个项目的质量情况，研发流程的过程执行和效率的情况。从整个组织的角度，对研发的质量和效率有促进的作用。
3. 从测试人员个人发展的角度，因为整个测试组织有了更好的深度，个人发展的空间也会更大，无论技术还是管理方面。
4. 测试人员的归属感，有自己的部门和自己的职业发展通道。
谈到和项目的对应，目前采用测试集中方面的团队也基本上是矩阵式管理，特别是针对负责业务测试的小组。一方面，从组织架构上是归属于质量部或者质量中心，但是从日常工作上，是归属到项目或者产品，和对应的产品、开发团队密切配合，包括座位可能都在一起。
就目前观察的情况来看，这种组织架构相对是比较成熟，也比较普遍被采用的，运作起来也还比较顺畅。
第二个方面，想讨论一下测试人员的内部细分。IT行业早已经是内部就开始隔行如隔山，分得非常细了。考虑对口的产品和技术形态，测试人员也有很大的差异了，比如测试通信设备的，测试Web网站的，以及测试app的，其背景知识，工作流程也有很大的差异。即使不考虑这方面，从专注的测试工作内容上看，也有进一步的细分。我接触到的会分为四个方面：
1. 业务测试
这一部分的测试人员就是上面提到的矩阵式管理的那一类，负责具体的产品的测试和质量提升。所以这一类的人就数量上来说通常是最多的。
2. 专项测试
如果测试组织稍大，对测试的深度有更高的要求，而有些测试类型又需要比较长时间的积累，且技能有横向的共用性，那么就可能有专人来做，俗称专项。比如安全测试，性能测试等。就实际运作的情况来看，像安全测试这种看起来确实比较有必要，因为没有长时间专注的积累难以有效果。这样的专项测试通常人数不是很多。
3. 质量管理
有些地方叫QA或者SQA，就是第二篇里面提到的专注在质量数据的收集，研发流程的管理和推动等事项上面的一些人。通常放在测试部门，但是也可能放在研发管理等团队。
4. 测试开发
当整个测试的团队比较大，需要很多共性的基础的平台和工具建设，就可能会抽出一个团队专门来做这方面的事情，称之为测试开发。
实际中，关于业务测试和测试开发，其实有时候界限是没有那么清楚的，取决于多个方面的因素：
1. 老大观念
没办法，这个很重要。接触到几位部门级测试团队的负责人，观念不完全一样，有些认为独立的测试开发团队很重要，且愿意大的投入，有些觉得没必要有专门的测试开发团队，业务测试团队应该有能力来做测试技术方面的事情。
2. 业务测试团队的能力
这个要看实际的情况，业务测试如果要做得比较好，业务测试的团队本身也需要比较好的技术能力，所以很多测试开发意义上的事情业务测试团队也可以做，实际也在做。但是也有些情况，业务测试团队本身的技术能力不够，或者时间非常的局限。从业务测试团队本身的意愿上，肯定也希望能做一些技术方面的事情。
3. 测试开发团队和业务测试团队的双向互动的情况
一方面是看测试开发团队做的东西能否在业务测试团队落地，涉及方案本身，是否贴合项目时间，以及和业务测试团队的配合的情况。这个实际情况应该还是比较复杂的，各个团队面临的实际情况都不太一样。
最后想讨论下关于测试人员外包。这里不讨论整个项目的测试外包，那是另一个范畴，也曾经和一个资深的测试leader深入聊过，不过最终也只是些理论推导，没有实际的应用，很多问题也不好说。
自己关于外包的观念也一直在变，因为看到身边不同的实际的例子，目前的想法大致如下：
1. 觉得外包非常的有帮助，能帮助完成很多的测试工作，在招聘速度上也很有优势，所以是个不错的选择。
2. 就实际运作来看，觉得外包的比例不能太高，一个正式配1-2个外包应该效果还不错，太多了对项目，对外包同学的成长觉得都不太好。
在我们团队的应用中，还有几个小的实例的体会
1. 像面试正式员工一样面试外包
如果我们觉得外包只是过来做黑盒的手工测试，随便找几个人就好了，可能效果不会太好，因为最终还是取决于人。我们目前的几位外包同学都是我们非常认真的面试过，从很多位中挑选出来的，在团队里面发挥的作用其实已经超出了我们的预期。
2. 更放手让他去做
就目前项目的情况，我们的外包同学除了做好基本的黑盒手工测试，他们也可以牵头一个项目的测试跟进发周报，自动化的用例制作和问题定位，crash问题的跟进分析等，而且工作的态度和主动性非常好。因为我们没有给他们设明确的界限，只要他愿意尝试，也具备基本的能力，那就可以去做。这个和上面的1也有关系。
3. 关注外包同学的发展
这两年接触了很多外包同学，团队里有好几位正式同学也是之前做过外包，所以对外包的看法有些不同了，在职业发展上尽量和正式同学一样看待，并关注他们个人的发展。
在这个充斥着企业文化，价值观的年代，测试如果作为一个独立的部门，也一定会被问这样的问题：作为一个独立的测试部门，我们的核心价值是什么？
这个问题好像一直都会在，值得去想想看。
最新内容请见作者的GitHub页：http://qaseven.github.io/
