一、导读

品质中心近半年提出了外包人员效率优化的口号。各个测试团队积极响应，想出各种各样的办法来尝试节省人力。其中 “外包资源池管理” 是各个团队都没有放过的一种尝试手段。

其最初的理念是把各个项目中一些简单的任务识别出来，交给一波初级的外包去做。这样能解决部分外包工作不饱和问题以及降低外包的培养成本。

而在不同测试团队的具体实施中，又演化出不同的实施方案。本文记录手机 QQ 浏览器测试团队在 “外包资源池管理” 方案上的几次尝试。有沉痛的教训，也有深度的思考。

二、资源池管理的预期收益

1、外包人力的充分利用

当前外包利用不充分的情况主要有 2 种形式。一是任务潮汐现象导致在任务量少的时候外包工作不饱和。而因为管理或者能力上的割裂不能很好地把这些闲置的人力给利用起来。手机 QQ 浏览器测试团队也存在这个问题。希望能通过资源池的管理方式解决。二是由于缺少统计和管理导致的人员闲置与低效。这个问题手机 QQ 浏览器测试团队不多见。在这里不展开。

2、外包培养和管理的成本下降

目前外包的培养和管理职责都是落在测试经理头上的。如果外包资源池能够分担甚至包管了这部分职责，测试经理就可以把更多的精力放在产品测试本身。对项目质量以及测试经理的个人成长都有利。

三、手机 QQ 浏览器测试外包团队特点

1、项目割裂

手机 QQ 浏览器分为 iOS 浏览器、Android 浏览器、TBS 浏览服务 3 个大产品。具体分工上，又分为 iOS 测试、后台（小说、视频、资讯、广告等）测试、Android 内核测试、Android UI 测试、Android 性能测试、TBS 测试、视频文件测试 7 个小组。地域上也分为深圳、成都、合肥 3 个地方。

项目的割裂代表着业务和技能的割裂。比如说，让一个测后台的同学去理解理解 TBS 的下载安装流程会很费劲；而让熟悉 android 手机抓网络包的同学去抓 iOS 手机网络包也要学习半天。这种割裂会让一个外包同学掌握多个测试小组的需求和技能变得十分困难。

2、任务难度大

任务难度大的问题在 Android 浏览器的几个测试组里体现明显。我们按照任务需要的技能要求将任务分成高中低三档。据粗略统计，QB 主线高难度任务占比为 44%；TBS 高难度用例占比为 33%。这些高难度的用例通常以下特征：

1）涉及前端、终端、后台多方面配合；

2）无法通过终端界面验证结果；

3）测试中会遇到很多意外情况需要灵活处理；

4）需要用到一些生僻、复杂的测试工具，如 inspector、fiddler 等。

以广告过滤为例，需要先确认拉取到 wup 后台的开关，了解广告过滤功能的开关状态，然后向业务后台拉取访问站点的过滤规则，接着终端要对该规则进行处理。过程中每个环节的结果都无从通过终端界面验证结果，而要通过查看日志、配置文件、上报等方法。

3、人力紧张

各个测试组都没有长时间的闲置人力。特别是 2017 年上半年，iOS、后台、TBS 都新增了不少业务。这半年的外包工作饱和度明显比之前更高。这样就不可能有闲置人力可以参与到资源池建设中。

从以上 3 点分析，我们一度悲观的认为，外包资源池管理不适合我们团队。

但是困难不是退缩的理由。我们以明知山有虎，偏向虎山行的毅力开始了我们的外包资源池方案探索。

四、他山之石

关于外包资源池，MIG 内部有应用宝走在前面。公司范围内，IEG 有不少的经验。所以在我们开始设计我们的资源池方案之前，我们先了解了其他团队的做法（一些关键词）：

应用宝：代码覆盖率，SDK，iTest，强调外包公司的作用（包括资源池运作方案也是外包公司在出），按类型划分任务，设立统一外包接口人。

IEG：ieg 有一个 itest 平台用于外包任务管理。该平台对我们设计开发 “外包任务和日报系统” 有参考价值。

五、方案 1：临近小组资源池方案

方案描述：临近资源池方案是指测试内容接近的 2 个项目之间组成临近资源池。

方案提出思路：这个是在人力紧张的情况自然想到的一种方案。两个项目的成员互相学习对方项目的技能，最终达到人力资源共用的效果。该方案分几步走：

1）整理技能标签并对任务和外包贴标签；

2）小组内实现人力资源共用；

3）临近小组实现人力资源共用；

4）整个浏览器测试组实现人力资源共用。

在想到这个方案的时候，我以为我看到了成功的希望。

方案实施时间：2 月 5 日- 3 月 31 日。

失败原因：前面 2 步都顺利完成。进行到 “临近小组实现人力资源共用” 的时候发现进展慢了下来。因为临近小组技能的互相学习是需要任务驱动的（通过做任务才能真正掌握技能），但适合放入资源池的任务太少（复杂任务不放入资源池）。临近小组实现人力资源共用

目标迟迟未能达成。于是我们开始考虑新方案。

收获和教训：临近资源池的准备阶段，我们整理了外包技能集。这是一个囊个了外包测试需要用到的几乎所有技能的培训文档。为后面的工作打下了很好的基础。

六、方案 2：准入准出资源池方案

方案提出思路：既然任务少，我就拉任务，我把整个浏览器测试组想放进资源池的任务都拉进来；人少我就拉人，我把整个浏览器测试组能挤出来的人力都挤出来。只要我控制好任务和人，并且用技能标签来做好任务和人之前的连接。资源池自然能运转起来！

方案描述：该方案有 3 个要点：任务审核、人员培训和技能标签关联。

1、任务审核：要通过任务审核的任务类型才能放到资源池来。主要是确保任务足够简单以及给任务贴上技能标签。

2、人员培训：要通过人员培训的外包才能进入资源池。主要是为了保证外包具备基本的通用技能 同时标记外包所掌握的技能标签。

3、技能标签关联：通过技能标签让任务找到对应的人去执行。下图展示了任务 1 和外包 A 是如何通过技能标签匹配上的。

在想到这个方案的时候，我以为看到了成功的希望。

方案实施时间：4 月 1 日- 4 月 30 日。

失败原因：这个方案理论上是可行的，但实际操作性不高。一来做任务审核、维护外包技能标签比较繁琐；二来在没有系统支持的情况下通过技能标签去配对任务和执行者不方便；最后是外包需要掌握的任务太多，第一次做任务效率低。测试经理也不放心。

收获和教训：过于复杂的流程规范注定无法落地生根，简单才是美。

七、方案 3：项目带头人资源池方案

方案提出思路：既然任务太多，那我就只让真正的简单任务进来。第一次做任务效率低，我就找熟悉的人带着干！让资源池先把最简单的这部分任务接管起来。

方案描述：每个项目设立一个项目带头人。项目带头人对提到资源池的任务的质量和效率负责。为了达到质量目标，项目带头人需要检查普通成员的测试结果；为了达到效率。

在想到这个方案的时候，我以为我又看到了成功的希望。

方案实施时间：5 月 1 日- 5 月 20 日。

失败原因：本方案解决是 “真正的简单任务” 放入资源池的问题。而前面分析过，咱们浏览器测试组的其中一个特点是 “任务难度大”。这个特点注定了我们组 “真正的简单任务” 会很少。通过统计，深圳浏览器测试组 “真正的简单任务” 只有 4-5 个人力，占总任务量的 20% 左右。即使我们能将这部分任务的效率提高一倍，也就只能节省 10% 的人力，预期收益太少。因此本方案实施了半个月就被叫停。

收获和教训：投入产出比是我们做任何事情都需要考虑的问题。不能为了资源池而资源池。

八、反思

手机浏览器组的外包资源池方案 3 次试错，总结出来最深刻的一条是教训是：思想不能被禁锢。如果先入为主地认为外包资源池就应该是简单任务、任务标准化，不能实际情况调整策略，只会一条路走到黑。

而事实上，对于不同的情况，需要选择不同的方案。很多关键活动到底要不要做，做到什么程度都需要根据实际情况选择。下面是我对于一些关键问题的思考：

九、方案 4：参考应用宝资源池方案

方案提出思路：在经历了 3 次试错之后，我们找兄弟团队应用宝学习了经验。决定采用 Android 资源池方案。对任务和人都进行梯队划分，所有任务都进资源池，最大限度地发挥接口人的作用。

方案描述：这个方案有 2 个要点。一是全部人、全部任务进资源池，这样才能最大限度地调度资源；二是充分利用外包接口人角色，把任务分发、人员培养的职责都放权给他，让他把资源池的事务统统管理起来。正式接口人只负责提考核指标和协调资源。

方案实施时间：5 月 1 日- 至今

参考应用宝的方案目前进展比较顺利。一路走来，我们越来越认识到判断一个方案好坏的标准只有一个：管用！不管黑猫白猫，抓到老鼠就是好猫。所以通过实践，证明适合我们手机浏览器组的才是最好的。

那怎么才算 “管用” 呢？

1、能管事

任务能准确理解，尽快分配给合适的人做。过程有反馈、少打扰，结果同步及时、信息完整。

当前资源池方案有 4 个关键活动能保证这一点。

（1）测试流程规范 - 保证流程统一

如下图所示蓝色是测试经理操作，红色是外包接口人操作，咖啡色是测试负责人操作。通过 tapd 需求模块和外包任务模块有机组合，保证任务的有效流转。

（2）任务视图 - 保证时间安排得当

如下图，接口人在安排任务的时候可以看到每个人当天已经安排了多少任务、任务优先级、任务进展和总预估工时。方便合理安排人力。

（3）任务梯队分级和任务责任人表格 - 保证任务分给合适的人

任务梯队 1（白底）：简单任务，所有人都会做；

任务梯队 2（红底）：中等难度，有 3-4 人会做；

任务梯队 3（蓝底）：高难度任务，每个项目保证 2 人以上掌握该项目的复杂任务。

任务梯队是为了形成任务难度分级的概念。而实际分发任务时，任务负责人表格则更实用。

下表中对每种类型任务的责任人和协助人进行了记录说明。

（4）测试方法总结

任务负责人需要保证自己负责的任务都有测试方法总结。协助人负责验收，保证如果负责人离职时，协助人能够快速顶上。

2、能管人

外包都得到合适的工作量分配，并有合理的能力评估和培养制度。

当前资源池有 3 项关键活动能保证这一点：

（1）饱和度均衡要求

通过 “外包任务” 模块的统计分析功能，可以了解到每个人的工作饱和度。及时分析原因保证人人有事干！不至于有些人特别忙，有些人特别闲。

（2）人员梯队技能图谱和梯队建设

技能图谱用于记录每个外包都掌握了哪些技能，没掌握哪些。同时有响应的课程用于培训学习。

梯队建设：

将人员分为三个梯队，对应三个梯队的任务（上文中有提到）。给外包接口人指定人员梯队提升计划，使得外包人员有计划低提升。

（3）新人培养制度

新人培养制度是为了让新招进来的同学迅速能达到第一梯队的能力要求。这里需要制定一些培训教程和淘汰规则。目前还在制定中。

3、数据透明

对外包的工作量、工作效率、工作质量有真实、便捷的评估。

这里有几项关键活动：

（1）使用 “外包任务” 模块统计分析功能统计外包的工作量、工作效率

（2）通过测试经理投诉管理质量

之前也有尝试过给每个任务评一个质量分，但那样运作成本太高。而通过测试经理的投诉管理则能够达到投入成本和质量监控效果的平衡。

投诉已经会从测试经理以邮件方式提出。正式接口人督促外包公司跟进解决。具体改进其实还是会落后外包接口人和任务负责人头上。

关注微信公众号腾讯移动品质中心 TMQ，获取更多测试干货！