51Testing软件测试论坛

标题: 关于测试任务的分配讨论 [打印本页]

作者: 莉莉莎儿 时间: 2015-11-11 11:27
标题: 关于测试任务的分配讨论
本帖最后由莉莉莎儿于 2015-11-11 11:29 编辑

之前公司的测试团队工作模式：400左右的技术人员，测试团队50人，包括一个自动化测试小组、若干功能测试小组。
公司业务分项目组若干，一个项目组对应一个测试组，组内根据业务规模人数不等。
由于公司业务是移动软件，那么项目组内有ios、Android等N个渠道N个版本，版本同步率有些只有80%存在差异性。

问题来了：
测试人员基本按照一个版本一个人负责，由于版本多任务重，时常无法有时间编写用例，都是上手就测试，但感觉效率仍然不高，只能不断招人。

不断招人不是好的解决办法，感觉可以通过合理的任务分配，达到提高效率的目的，但目前还没有想出合理的方法。
求高人指点迷津！

作者: joykao 时间: 2015-11-11 13:42
是否可以对ios和Android的版本做个用户市场调研，这些数据你们应该也有的吧，把最有价值的挑选出来，砍去价值较低的，允许容错，同时测试兼容性是否可以换思路比如先分辨率，后系统，再机型同时可以引进外部的测试资源，比如testin就可以，而且价格也不贵。貌似今天还在打折

作者: jingzizx 时间: 2015-11-11 13:54
我觉得还是要编写一下用例，当然可以不用那么详细，可以把所有功能点列出来，进行一项项测试，是不是会提高效率；
现在效率不高的原因是什么呢

作者: gaha 时间: 2015-11-11 14:08
从人员比例上看，开发和测试虽然没有达到1比1的程度，但是50人的团队也着实不小了，如果在处理任务压力的时候，仍然通过持续不断的招人，肯定是下策中的下策。我不知道你在50人的团队里处于什么情况，还是只是思考如果遇到这种问题，你该怎么做，不管情况如何，谈谈我的想法:
首先应该把50人分出层次，哪些需要，可以，有能力接触核心技术的，有一定的开发能力，在管理上，在编写自动化工具，维护测试代码方面有专长的，需要重点关注，这部分人作为测试团队的基础，是提高效率，提高质量保障的关键；
其次要归拢你们的业务，实在不能合并在一起的业务，该分开要分开，但是每个业务组安卓和IOS是可以同时存在的，这部分主要做补充业务的功能测试，稳定版本需要渐渐通过自动化或工具去实现，而自动化的程度，需要看你们核心人员自身的能力了；
然后核心团队里要分两拨，一波是管理，协调资源，管理每个组的工作，另一波完全是开发测试工具，设计测试代码，成果分享给每个业务团队的测试人员，这部分技术的核心应该有通用性，日久维护的成果才是不断精简人员的基础。
最后已经50人规模的团队了，不管做什么变革都不是一朝一夕的，我说的只是一个思路，无非就是要提炼技术基础，拿工具运用到不同的业务里，核心人员价值最大，用质的提高缓和单纯用量去解决问题的粗放型工作模式。

作者: zhuruize 时间: 2015-11-11 14:27
1、每个测试组应该对应业务和技术分组，比如每个组都分配业务能力熟悉的，技术按熟悉自动化的每组一个，等等；
2、版本来的是看能不能团队合作，一个人主要负责，其他人帮忙。
能实现自动化的把基本功能都实现自动化，新添加的功能做新的测试就省力一些了

作者: 莉莉莎儿 时间: 2015-11-11 14:48

gaha 发表于 2015-11-11 14:08
从人员比例上看，开发和测试虽然没有达到1比1的程度，但是50人的团队也着实不小了，如果在处理任务压力的时 ...

感谢回复，很受益！
目前的情况是，自动化小组在对核心项目的业务进行摸索，但推广情况不佳
而其他的小组都还处于手工测试的工作模式，每个组有组长协调资源，一些确实有代码能力的成员，也没有能到能力的发挥；其次小组间过于分散，基本没有共用资源，重复的业务没有归拢集中测试，辅助工具的使用率也低；还处于粗放型工作模式。
目前团队较大，但做的事情确很有限，不尴不尬，如你所说，改革困难，牵一发动全身，和公司业务框架也颇多干系，若要调整，不是一朝一夕

作者: 莉莉莎儿 时间: 2015-11-11 14:51

zhuruize 发表于 2015-11-11 14:27
1、每个测试组应该对应业务和技术分组，比如每个组都分配业务能力熟悉的，技术按熟悉自动化的每组一个，等 ...

由于自动化开发没有依赖于市面上成熟的产品，而是自主开发，精力花费不少，起到的作用却不多，这一块其实已经基本判定失败了

作者: 莉莉莎儿 时间: 2015-11-11 14:54

jingzizx 发表于 2015-11-11 13:54
我觉得还是要编写一下用例，当然可以不用那么详细，可以把所有功能点列出来，进行一项项测试，是不是会提高 ...

效率不高有几个原因：
版本多且杂，但每个版本要人工跑一遍，重复率高；
开发版本质量不高，低级bug多；
项目组配合程度不高等类似原因；

作者: 莉莉莎儿 时间: 2015-11-11 15:06

zhuruize 发表于 2015-11-11 14:27
1、每个测试组应该对应业务和技术分组，比如每个组都分配业务能力熟悉的，技术按熟悉自动化的每组一个，等 ...

拿我所在的测试组来看，测试组内包括组长5个人，同一时间内待测试任务为4-5个版本，因为这个项目组有多个app产品，每个版本功能不同，每个新版本任务大概需要5人天，基本测完一个后面还一个等着测；可以说没有空闲的时候；再加上自动化测试工具的缺乏，感觉很艰难。极其需要有一个可行的突破口改变现在的工作模式

作者: vivian_lau_bj 时间: 2015-11-11 15:19
50人的测试团队具体到能进行功能测试的人员可能会更少。
功能测试人员要对软件能实现的功能有比较深的了解；这点不断从外部招聘进来的人员如果没有经过对应的培训是不了解相应功能的。
400人的技术人员可以按照项目属性分类，那么50人的测试团队也可以按照项目进行划分；在一直熟悉的项目上做事效率会比较高，而且团队合作也会更高效。
1、不管是什么渠道或版本，软件要实现的基本功能是既定的，或者随需求变化各版本会有不同
2、找出主线的功能，每轮测试先保证主要功能（这点要一定能落实到纸面上最好），然后考虑其他容错、例外功能
3、因操作系统不同，那么可以将每组人员按照操作系统进行分类
4、每个项目或版本来了，先评估差异性（既然只有20%左右的差异），建立差异库，由专人负责，其他人负责相同功能；
如果不能建立差异库，必须一个人一个版本负责到底；那也要将人员区分为不同操作系统上的测试，对操作系统的熟悉也会提高效率。

其他问题：
1、你们的版本是如何发布的，每次版本发布的时候会告知影响的内容么？如果说是版本多，那么考虑发布版本的规则是否合理，针对这个版本的测试任务分配是否合理？
2、自动化测试组在整个项目中承担的角色是？是否可以承担基本功能的验证
3、你说的效率不高是体现在什么地方？规定时间没有完成测试任务？还是遗漏bug太多？组内积极性不高？

作者: 莉莉莎儿 时间: 2015-11-11 17:46

vivian_lau_bj 发表于 2015-11-11 15:19
50人的测试团队具体到能进行功能测试的人员可能会更少。
功能测试人员要对软件能实现的功能有比较深的了解 ...

针对你说的其他问题：
1.版本发布基本就是ios和Android同时开发，但根据开发进度，交付测试的时间节点可能不同；个人认为，每个迭代功能还是比较大且杂
2.自动化测试组还处于摸索阶段，在测试环节没有发挥实际作用（我所在的项目中没有接入自动化）

3.效率不高，是说重复的功能同步后并不比第一次测试耗时短，对于这部分效率低的原因，我自己总结了有2点：
一是，纯手工，重复工作量占比大，目前也没有可替代的工具；
二是，开发团队的开发周期很短，必然导致测试环节来买单，提交给测试的版本质量差，测试时间拖长就无法避免，哪怕只是同步的功能，也不敢只进行简略的测试。
针对以上两点，
第一点，除了寻找合适的自动化工具意外，我认为从人员任务分配上还有优化的空间，但不知如何下手更好；
第二点，似乎至今整个测试团队都已经放弃抗争。开发任务重，时间短，把压力都丢到测试这边来，而整个团队更看重结果，没有过多要求过程

作者: 吼吼哈哈 时间: 2015-11-12 18:12
2楼说的很有道理，表示严重同意

作者: han80119 时间: 2015-11-13 12:56
作为软件开发，如此规模，着实让人羡慕，不知道是哪个知名公司。
测试的时间，其实弹性非常大，开发出来的软件的质量直接影响测试时间的长短，这一点我是深有体会。400多人的开发人员，50个测试人员真不算多，要想提高效率，不妨从提高开发交付的软件质量着手，测试本身就是开发的一部分，任务重不能作为开发交付低质量软件的借口，任务重更应该仔细，防止修改bug浪费时间。
低级bug多，可能是软件内部源码结构不好造成的，而不是任务重造成的，有经验的开发人员，bug少而且用的时间还短。如果你控制不了这些，可考虑进行个人的bug统计汇报公开，只有开发的软件质量提高上去，整体质量才能提高，测试也会更轻松，质量是做出来的，不是测出来的，质量不只是测试人员的事。

作者: 莉莉莎儿 时间: 2015-11-16 11:30

han80119 发表于 2015-11-13 12:56
作为软件开发，如此规模，着实让人羡慕，不知道是哪个知名公司。
测试的时间，其实弹性非常大，开发出来的 ...

非常赞同你所说的！
测试团队内部也很清楚这个情况，之前一度以提高提测质量为目标，但由于团队自身的一些原因，最终执行没有达到我们预期的目标，这一点现在想来很遗憾
最根本其实还是得把控交付测试版本的质量，再来谈论其他

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)