测试管理FAQ三。
测试开发比多少合适?1:3?1:10?作此统计纯属扯淡,分析团队产能有很多指标,这是最不靠谱的一个,但偏偏不少人就是喜欢,由此不知误导了多少老板。
测试开发工作量比多少合适?5:5?5.5:4.5?这个更扯淡,世间万物千变万化,就是一般情况也无法套用此比例,误人子弟。
要说世间万物是否有其内在规律,我信,但规律远远不是一个单纯比例能够汇总的,之所以很多人喜欢用是因为它简单,不用了解太多细节不用做深入分析简单粗暴的一个比例搞定,小团队长年累月做那么几个产品还好说一点,团队规模越大业务越复杂越是不能套用,作为一名合格的管理者,准确评估团队产能团队整体性能是必做功课,是必须掌握的技能,如果做不到就老老实实做技术或业务吧,别整天拿管理者来标榜自己,说远了,打住。
本篇主要讲述在研发任务中测试人员的分配,不涉及比例的概念,单纯以多少来说明,主要说明在一般情况下何种类型的任务可以少分配测试人员,仅作为一种参考,或许有点以偏概全,勿争论,有些常识性的就不做说明了。作为系列文章,老板需要什么在前两篇已经叙述过了,这里不再重复。
1、任务类型
- 业务型:如果研发任务主要是业务需求,可以少分配测试人员。相对于优化型任务而言,业务型任务目标更加明确,任务范围更加清晰,圈定风险点更加容易,再加上小步快跑,无需大量投入。
- 新增型:全新功能,非改造型任务,原因同上。
- 突发型:可能是线上故障修复,也可能是为了迎接某个大型活动临时做的变更,反正这种类型任务的共性是周期短优先级高紧急程度高,越是这种任务越要降低沟通成本,没有时间圈一大帮人反复讨论方案,迅速上线解决问题是首要目标。
- 协作型:跨部门协作任务,尤其是跨技术部门,跨的越多,本团队的工作量可能就越少,大头是在联调上,不用找多个接口人。
- 技术型:非业务也非优化,纯属技术研究,实用价值待定,可能做了半天没一个业务线用,这种先让开发人员折腾吧。
- 周期型:周期长,一期二期很多期,长时间占用固定资源,配备人员能少尽量少。
- 试验型:甚嚣尘上的敏捷或类似产物是人都在玩,但大都浅尝辄止并不持续,在中国大陆这片土壤上敏捷是否会像ISO、CMMI一样臭大街目前不得而知,但有一点可以明确,在当前形式下不用投入太多资源搞这玩意。如果任务过程采用新模式,资源投入越少越好。
- 残缺型:任务信息不全比如说没有文档,或者是临时接手之前的负责人跑路了,对于这种任务,首要工作是整理清楚任务,不是动手做。
- 自测型:在保证质量的前提下,这种方式是首选,应大量推广。
2、团队构成
- 失调型:大团队男女比例失调。如果测试团队女性员工居多,可以少分配,原因你懂的。
- 基建型:测试基础建设完备,大团队成熟度高,很多时候研发任务无需配备测试。
- 复合型:一专多能人员居多。测试岗位天生就是复合型的,特别是技能复合。能做开发也能做测试,能做功能测试也能做性能测试,在某一个领域比较深入同时其它领域的工作也能做,这是我推崇的团队结构,无需对某项工作设立专岗,而是在做业务测试的同时兼任其它工作。是否会因此沉淀的不够深?有可能,但总比脱离业务的好。
- 扁平型:组织结构扁平,垂直化,沟通成本小,任务目标一致尤其是KPI。
3、产品特点
- 延时型:非实时交互产品,出了问题也有足够时间修复。
- 社区型:比如说我最近在途牛论坛上写游记,差点没把我搞死烂的一塌糊涂,但还不是照样用。
- 搜索型:很难对结果进行准确验证,尤其是算法的合理性验证,我们用百度还不是照样被强奸。
- 媒体型:视频、文字、图片,用户更关注的是内容,能打开就好。
- 还有不少不一一列举了。注意,不是说这些产品不重要,而是无需投入太多测试资源,二者不要混淆。
以上所说的测试资源主要指普通测试人员,非测试“专家”,我一直不清楚测试专家是干嘛的,前不久往火星发送好奇号,专家们应该有参与吧?呵呵。