产品测试组和业务测试组

本文讨论的团队模型，是基于阿里巴巴（淘宝、天猫）这样比较复杂的电子商务互联网公司；

本文讨论的是软件测试的团队模型，开发团队可以参考，但是由于开发和测试工作性质的不同，不能简单的推理为开发团队模型；

Part1

一般电子商务网站，都有“会员、商品、店铺、交易、评价”这些基本概念，在淘宝网最开始发展的几年，这些产品概念在架构上是一个整体。随着技术架构的发展，这些概念被一个接一个的从淘宝系统中拆分出来，形成一个又一个产品中心，如下图（系统架构图）：

底层的这些“中心”，都有独立的测试团队支持；然后接下来几年，业务的发展非常快，除了淘宝网，又发展出天猫、聚划算、旅行等一些独立的业务概念，如下图：

上层这些组织，在阿里集团被称为Business Unit（业务单元，后面简称BU），每个BU都会有独立的测试团队支持，我们称这些测试团队为“业务测试组”。底层产品中心测试团队我们称为“产品测试组”。这两个概念只是用于本文讨论，在真实的组织架构中可能并不叫这个名字。

在第一种架构的时期，并没有什么问题，业务测试组和产品测试组配合的很好，因为大家都是为了同一个BU（淘宝网）在工作。可是当上层BU不断增多的时候，矛盾就慢慢显现出来了。

BU和产品中心产生了很多交集，比如“淘宝商品”、“天猫交易”这样的，这些交集部分到底由哪个测试组负责，这就是本文讨论的主要问题。

Part2

由于产品中心并不像物理层（数据库、缓存）那样抽象，也是具有相当的业务复杂度的，这就与BU产生了明显的纠缠，所以交集部分的测试归属，就是一个大家无法回避的矛盾中心（这里开发团队也差不多）。另外一方面，产品测试组本来是以支持淘宝BU为主，当其他BU如雨后春笋般增加的时候，产品测试组没有及时进行角色的转换，下意识的认为自己的职责仍然是支持淘宝BU（主站），因此其他BU的业务测试组，从产品测试组这里能获得的支持要少得多，这也加剧了矛盾。

关于这个问题的观点主要有两个，其实也很简单。观点1：交集部分由产品测试组负责，理由是产品测试组对产品中心结构非常熟悉，测试效率最高；观点2：交集部分由业务测试组负责，理由是贴近业务和最终用户，也可以随时响应BU开发团队的测试需求。在很长一段时间里，我们经常听到这两种观点的争论，也一直没得出特别靠谱的结论，有时还发展出第三种，也就是业务测试组和产品测试组“一起负责”这种和稀泥的观点，其实只是回避了这个矛盾，并没有从根本上缓解。

这里我们有必要简单回顾一下产品测试组的发展过程，也就是从架构1向架构2的变化过程。当我们还是架构1的时候，产品测试组是按照观点1的方式运作。当BU增多的时候，产品测试组开始出现人力资源瓶颈，很多BU的测试需求无法及时的完成，于是出现了一种无序的，抢夺资源的局面。注意这只是现象，根本原因是产品中心没有站在全局的层面来进行人力资源预算和资源配置，而是任由各个BU争夺资源。于是经常能看到产品经理到处圈人，测试经理疲于应付，却也理不出头绪。

由于人力资源预算机制的缺失，“产品测试组缺人，是瓶颈”的观点被大家逐渐接受了，甚至产品测试组自己也这么认为。但是更要命的情况出现了，基于这个观点大家开始继续推理，既然产品测试组是瓶颈，那业务测试组就必须发展起来，承担交集部分的测试工作。于是各个BU的业务测试组开始招兵买马，团队规模持续增加，然后慢慢接近于观点2的工作模式。

虽然观点2确实解决了BU面临的测试资源不足的问题，但是观点2是基于一个现实问题（产品测试组是资源瓶颈）进行推理，这样的推理方式无法根本解决问题。团队模型的研究还是应该从科学性出发，而且团队模型的设定切忌走极端，不能因为在一个极端碰了几个钉子，马上全速奔另一个极端绝尘而去，精力都耗在路上了。

让产品测试组把所有BU的业务都搞定，确实不现实，但是如果把产品测试的工作，完全拆散，然后分散到各个BU去，更加不靠谱。

因为观点2的团队模型的问题也非常明显：

1. 多个业务测试组都是围绕一个系统在测试，肯定会存在重复劳动，资源利用率低；
2. 大家都只关注自己的业务，缺少对产品中心全局质量的控制，可能会造成产品中心质量不断恶化；
3. 产品测试组需要和n多业务测试组对接，不仅费事，也很可能存在合作的空档，造成质量风险

最后有必要分析一下那个“资源瓶颈”的问题，是不是真的存在，如果存在，是不是真的无可救药。首先我们做一个假设，X中心的产品测试组有3位测试工程师，要支撑3个BU，然后这3个BU都认为测试需求无法满足，于是把这3个人分别拆到这3个BU的业务测试组去工作，然后问题就解决了。真的是这样么？

即使在表象上看真的是这样，这里面其实还有很多隐情，我分析很可能是下面两种情况。A、这3个人在产品测试组，并不是全力支持3个BU，可能只有一半资源在支持，另一半他们去做“更重要的事情”去了，于是拆到业务测试组以后，资源加倍，问题解决；B、这3人来到业务测试组以后，仍然无法支撑测试需求，于是测试经理给他们加了人手，增加到6人，资源加倍，搞定。

很多时候资源瓶颈并不是因为人的总量不足，多半是由于人力资源使用率较低，或者是人力资源计划性不强。

Part3

分析了这么多，这个问题是不是真的无解了呢？我们还是要回归到BU的原始需求。如果产品测试组包揽一切测试工作，那么那些业务爆发式增长的BU，肯定会坚决反对，因为他们希望自己控制资源，由业务测试组快速搞定业务。另一方面，那些业务比较平稳的BU，特别是跟产品中心交集已经非常稳定的BU，他们更情愿把交集的测试工作交给产品测试组，不愿自己的业务测试组陷入一个他们并不熟悉的系统里去，因为业务才是根本，业务测试组应该更关注BU主营业务。

于是“BU业务发展速度”这个概念进入我们的思考，看起来这个因素是造成目前矛盾的根源，但同时也是解决问题的关键所在。

不同类型的BU，支持的观点也不同，有的BU支持观点1，有的支持观点2。我们不管用哪种方式，都会有BU不满，是不是我们需要考虑一种“混合”模式。在决定如何混合之前，我们要把两种观点的优缺点分析清楚，我们用下面的表格来对照，绿色字体代表优势，红色字体代表劣势；

测试工作	业务测试组	产品测试组
对BU业务熟悉程度	直接接触业务方和客户 随时获得第一手资料	与业务方离得比较远 了解业务不太及时
支持BU开发组的效率	与BU开发朝夕相处，沟通方便	交流不方便
对产品中心的测试效率	不清楚产品中心的结构 测试过程难以判定真伪 对代码的改动的质量风险不好判定	对产品中心的架构和测试策略非常熟悉 测试效率高
产品中心质量整体控制	只关注BU本身的业务 对整体质量不关注	对产品中心的整体质量较好的控制
回归测试设计和管理	回归质量参差不齐 重复脚本多，资源浪费 回归出现问题，确认超级费事 脚本统一设计结构清晰	回归覆盖科学，管理成本低

 

从这个表格可以看出，业务测试组的优势是快速的支撑BU的业务发展，而产品测试组的优势是对公共产品有持续的维护和完善。我们可以概括成一句话：

业务测试组负责进攻，产品测试组负责防守。

这其实是一种观点1和观点2并存的解决方案，BU的业务发展速度，是决定业务测试组和产品测试组分工方式的关键。不过只有这个概念还是远远不够，我们需要进一步说明产品测试组的工作逻辑和工作内容，看看怎么做才能更好的支撑BU，支持业务测试组的工作。

首先我们要重新梳理一下产品测试组的工作方式，看看和以前有什么不同。这里需要特别引入前文重点提到的“人力资源预算”的概念，简单来说就是，一个产品测试组能支持多少BU，一共需要多少人，这些人怎么分配。目标就是让每个BU都满意，注意并不是给每个BU平均分配资源，满意是关键。我们罗列一下产品测试组的工作重点（岗位描述）：

1. 一个产品测试组负责一个产品中心，但可能面对多个BU的开发组；
2. 一个产品测试组有1~2位测试leader，根据产品中心规模而定；
3. 明确哪些BU与本产品中心的交集，由产品测试组负责，哪些由业务测试组负责；
4. 对于确定要支持的BU，产品测试组需要定期制定资源计划，并得到这些BU的认可；
5. 产品测试组负责设计开发所支持BU的自动化回归体系；
6. 产品测试组负责承接所支持BU的测试需求，可能改代码的是BU的开发工程师，但是改的是产品中心的系统；
7. 如果所支持的BU在本产品中心出现故障，责任由产品测试组承担；
8. 产品测试组要定期与业务测试组交流近一段时间的业务变化；

下面说一下上面第三点，产品测试组如何判断应该支持哪些BU。前文说到一个“业务发展速度”的概念，这个概念比较抽象，我们很难定义出，BU的发展速度到底有多快才是逻辑区分点。这里其实还有个更简单的逻辑，那就是：

尊重BU研发团队的意愿。

在实际工作中，我接触过很多BU的开发和测试，他们都希望由我们产品测试组来完成测试工作，因为“你们对系统最熟悉”、“我们人手也很紧”等等。既然客户有这样的需求，那我们就把这部分工作接下来好了。如果BU坚持用自己的业务测试组，那也ok，产品测试组将不负责这个BU的质量。而且BU有足够的自由选择权，BU可以选择一部分产品中心的工作交给产品测试组，一部分由自己的业务测试组搞定，这样也非常好，比如“商品管理我要自己测”、“交易流程你们去搞定好了”。

业务测试组和产品测试组的分工，不是一成不变的，而要根据BU的发展，动态的调整。

这一点也非常的重要，因为我们讨论的是一种混合团队模型，变化将成为常态，测试工作可以在产品测试组和业务测试组之间转移。举例来说，比如某个BU需要对交易流程进行一个很大的改动，涉及到BU的核心业务，那么就需要BU的业务测试组负责，产品测试组给予一定支持。等这个项目做完了，近一段时间BU的交易不会有大的变化（有些小修改），那么就交给产品测试组来维护，业务测试组转去做其他的测试。也许过了半年，这个BU的交易又需要大的调整，那业务测试组再次出现，以此类推。

上面分析了这种新的团队模型的优点，下面也说说带来的风险：

1. 常规的测试团队模型，是测试严格对口开发，并按照固定比例配比（开发测试比），新团队模型对此是很大的挑战，很多人会不适应；
2. 产品测试组的人力资源仍然是风险，特别是当很多BU同时开始做“大项目”的时候，这就需要资源的预算要尽量准确，资源调配也要更可操作；
3. 测试工作在业务测试组和产品测试组之间移交的时候，可能会产生问题，当然测试设计能力强，合作默契的团队会好很多；
4. 由于测试工作动态化，测试团队的绩效评估将面临挑战；

到这里我们的分析告一段落了，中心思想是要用发展的眼光看问题，不能形而上的希望用一种手段解决所有问题。本文所讨论的观点1和观点2，都是对的，不用争论哪种更好。对于各个BU来说，自然会根据自己的业务特点选择最合适的测试策略，作为产品测试组需要尊重BU的选择。对于测试工程师来说，那就问问自己到底是属于进攻型，还是防守型。如果是进攻性选手，就加入业务测试组，享受跟业务一起成长的成就感；要是防守型选手，就加入产品测试组，体会产品从80分到90分的进步，学习架构不断完善的技术。