产品测试组和业务测试组

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

本文讨论的是软件测试的团队模型，开发团队能够参考，可是因为开发和测试工做性质的不一样，不能简单的推理为开发团队模型；

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分的进步，学习架构不断完善的技术。