这一篇是系列
文章的第三篇，前面两篇分别谈了
测试的必需性《关于
软件测试的几点反思 - 测试是必需的吗？》，以及测试
工作的一些内容《关于软件测试的几点反思 - 测试工作的三个阶段》，接下来想聊一下
测试团队的组织。
要讨论这个话题，首先要讨论下测试人员本身的归属，因为通常是人多了才有组织的必要，很多东西都是一点点长出来的。
我在读研期间实习的一家公司，根本没有专职的测试人员，回头想想当时还是挺大胆的，因为做的是比较核心的系统，而且当时像我这种实习生都写了很多核心的涉及金额计算的代码，然后大家自测下就上线了。这种情况也持续了好久，也验证了不一定必需，在特定的情况下。
个人的工作经历，没有一开始去很小的研发组织。后面工作后的
面试中，也接触过很多规模较小的公司的测试人员，这种情况下大部分是直接归属到项目，汇报给开发经理。人数少，大部分是比较基础的
黑盒测试，相对也比较弱势。没有任何贬低的意思，但是客观来说，这个阶段的测试很难有一些比较深入的测试技术上的实践，时间不允许，也处于没有人带的情况，大家基本上都专注在项目的
功能测试上面。一直觉得环境对人的影响是比较大的。有些比较有上进心的同学会自己学一些技术，但是因为没有指导，也没有实际应用的场景，通常比较浅。
后面等到整个研发体系发展大了之后，可能测试人员也慢慢多了起来，同时服务于多个开发小组，于是就出现了测试团队的二级组织。比如对口每个开发小组的有几个人，或者更多，然后有一个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. 关注外包同学的发展
这两年接触了很多外包同学，团队里有好几位正式同学也是之前做过外包，所以对外包的看法有些不同了，在职业发展上尽量和正式同学一样看待，并关注他们个人的发展。
在这个充斥着企业文化，价值观的年代，测试如果作为一个独立的部门，也一定会被问这样的问题：作为一个独立的测试部门，我们的核心价值是什么？
这个问题好像一直都会在，值得去想想看。