测试资源分配

测试管理FAQ三。

测试开发比多少合适？1：3？1：10？作此统计纯属扯淡，分析团队产能有很多指标，这是最不靠谱的一个，但偏偏不少人就是喜欢，由此不知误导了多少老板。

测试开发工作量比多少合适？5：5？5.5：4.5？这个更扯淡，世间万物千变万化，就是一般情况也无法套用此比例，误人子弟。

要说世间万物是否有其内在规律，我信，但规律远远不是一个单纯比例能够汇总的，之所以很多人喜欢用是因为它简单，不用了解太多细节不用做深入分析简单粗暴的一个比例搞定，小团队长年累月做那么几个产品还好说一点，团队规模越大业务越复杂越是不能套用，作为一名合格的管理者，准确评估团队产能团队整体性能是必做功课，是必须掌握的技能，如果做不到就老老实实做技术或业务吧，别整天拿管理者来标榜自己，说远了，打住。

本篇主要讲述在研发任务中测试人员的分配，不涉及比例的概念，单纯以多少来说明，主要说明在一般情况下何种类型的任务可以少分配测试人员，仅作为一种参考，或许有点以偏概全，勿争论，有些常识性的就不做说明了。作为系列文章，老板需要什么在前两篇已经叙述过了，这里不再重复。

1、任务类型

• 业务型：如果研发任务主要是业务需求，可以少分配测试人员。相对于优化型任务而言，业务型任务目标更加明确，任务范围更加清晰，圈定风险点更加容易，再加上小步快跑，无需大量投入。
• 新增型：全新功能，非改造型任务，原因同上。
• 突发型：可能是线上故障修复，也可能是为了迎接某个大型活动临时做的变更，反正这种类型任务的共性是周期短优先级高紧急程度高，越是这种任务越要降低沟通成本，没有时间圈一大帮人反复讨论方案，迅速上线解决问题是首要目标。
• 协作型：跨部门协作任务，尤其是跨技术部门，跨的越多，本团队的工作量可能就越少，大头是在联调上，不用找多个接口人。
• 技术型：非业务也非优化，纯属技术研究，实用价值待定，可能做了半天没一个业务线用，这种先让开发人员折腾吧。
• 周期型：周期长，一期二期很多期，长时间占用固定资源，配备人员能少尽量少。
• 试验型：甚嚣尘上的敏捷或类似产物是人都在玩，但大都浅尝辄止并不持续，在中国大陆这片土壤上敏捷是否会像ISO、CMMI一样臭大街目前不得而知，但有一点可以明确，在当前形式下不用投入太多资源搞这玩意。如果任务过程采用新模式，资源投入越少越好。
• 残缺型：任务信息不全比如说没有文档，或者是临时接手之前的负责人跑路了，对于这种任务，首要工作是整理清楚任务，不是动手做。
• 自测型：在保证质量的前提下，这种方式是首选，应大量推广。

2、团队构成

• 失调型：大团队男女比例失调。如果测试团队女性员工居多，可以少分配，原因你懂的。
• 基建型：测试基础建设完备，大团队成熟度高，很多时候研发任务无需配备测试。
• 复合型：一专多能人员居多。测试岗位天生就是复合型的，特别是技能复合。能做开发也能做测试，能做功能测试也能做性能测试，在某一个领域比较深入同时其它领域的工作也能做，这是我推崇的团队结构，无需对某项工作设立专岗，而是在做业务测试的同时兼任其它工作。是否会因此沉淀的不够深？有可能，但总比脱离业务的好。
• 扁平型：组织结构扁平，垂直化，沟通成本小，任务目标一致尤其是KPI。

3、产品特点

• 延时型：非实时交互产品，出了问题也有足够时间修复。
• 社区型：比如说我最近在途牛论坛上写游记，差点没把我搞死烂的一塌糊涂，但还不是照样用。
• 搜索型：很难对结果进行准确验证，尤其是算法的合理性验证，我们用百度还不是照样被强奸。
• 媒体型：视频、文字、图片，用户更关注的是内容，能打开就好。
• 还有不少不一一列举了。注意，不是说这些产品不重要，而是无需投入太多测试资源，二者不要混淆。

 

 以上所说的测试资源主要指普通测试人员，非测试“专家”，我一直不清楚测试专家是干嘛的，前不久往火星发送好奇号，专家们应该有参与吧？呵呵。