如题,我们团队遇到了一些困扰,主要体现在如下方面,希望大家都建言献策,如何提升测试效率,并最大化发挥测试人员的价值。
1、开发质量差,提测的功能,冒烟测试通过率通常只有 50% 左右,此问题一直在研发团队强调,但属于那种一拳打在棉花上,说的时候大家都知道提测知道差,但就是没有多大改善。(与开发负责人也进行过多次沟通,但都没有多大本质上的改善)
2、项目界面、易用性问题比较严重,每个项目测试、开发花费在这块的时间成本,基本可以占到 20%-30%,这块如果能够做好,项目成本也可以直接下降,但也是属于那种一说都知道,但就是一直没改善的状况。
3、基于问题 1、2,测试人员每天花费太多的精力在一些基本功能、界面问题上,而没有较多的精力在测试技术提升、深度问题发掘上,长此以往,会让测试人员有种专业价值没得到体现的感觉,不利于团队的长久发展。
4、这些问题,与开发负责人、CEO 都有过沟通交流,但最后都仍然没有多大改善,有一种感觉就是,测试团队自己着急,其他人都不着急。
在此想问大家,此种情况如何破局,真正的提升研发质量、测试效率,让开发、测试都能在工作中有所收获。
看你描述了一波,大概总结一下你们团队的难处和症结。
1、整个团队乃至公司考核制度不完善(这些问题,与开发负责人、CEO 都有过沟通交流,但最后都仍然没有多大改善),同时领导想看到的是即时效益,可能是你们公司规模和老板思想直接导致;
2、开发人员测试观念薄弱,同时技术能力也一般(开发质量差,提测的功能,冒烟测试通过率通常只有 50% 左右);
3、产品需求设计来回改,产品能力也不强(项目界面、易用性问题比较严重)
提供几点意见给你参考:
1、找 CEO、开发直接 leader、HR 直接沟通考核制度定制改善,你可以提前列出关于团队配合相关的开发测试考核指标,表达自己的意见,当然考核制度并不能很直接的解决问题,可以尝试去推动完成,公司的制度就是在工作中不断完善,作为测试领导这是你能为公司做的一些分外事。
2、作为测试 leader,首先你要分析一波你自己团队成员的能力,哪些测试主导能力强的(测试驱动方面,沟通方面等)、哪些具备测开能力的,这一步很关键。
1)对于测试主导能力强的,让他多执行测试 PM 职责(涉及发布前、发布中、发布后各个节点的职责点,这个作为 leader 你那边可以具体到点列清楚,然后让测试 PM 去执行推动),可以一定程度提高成员的执行力、测试管理能力以及成就感。
2)对于具备测开能力的组员,建议前期直接接入单元测试和接口测试,配合开发完成接口方面测试。另外建议部署一套 mock 接口平台,网上有开源的,这样提前编写 mock 数据(包括正常数据和部分关键异常数据)供前端自测使用。以上两点一定程度可以提高冒烟通过率,更能提升团队技能。
综述,两个点的执行也就是我们测试人员的两个大方向,管理发展方向和技术方向
3、界面问题多:针对过往 bug 分析一下为什么界面问题很多。我大概的提几点常见的,你可以做更详细的分析(开发粗心导致、需求变动频繁导致、需求不明确导致、前端异常情况考虑不充分导致、服务端逻辑缺陷导致等等),
1)我想强调的是开发粗心导致的问题,首先你要和这位开发经常聊聊这方面问题,多发发这些数据,提供一下技能提升的意见,作为朋友的方式沟通,我想想没人不愿意去听。其次,多次沟通无效果的情况,直接和开发 leader 报数据说明开发者能力方面问题,通常情况下开发 leader 也会去找他谈,最终效果还是不明显的情况,就是找 HR 和主要领导沟通这个成员的问题。如果再大家努力下还是没效果,结果自知,为公司筛选员工,你也尽了一份力。
2)另外就是需求的影响导致,前期尽量安排需求测试,这个测试团队最好在需求出来后就去做,另外写用例的时候也去关注。把问题尽量的往前处理。当然这并不是万能的,不可能想的面面俱到。
3)关于服务端逻辑问题和前端页面部分问题,在上面我提到过接口测试和 mock 测试,都是可以提前一定程度发现并解决。
作为 leader 我们需从问题本身分析找出策略去处理这些问题,这也是 leader 应该完成和必须去做的事。
补充两点:
1、需求测试一定要做(需求评审前和测试用例编写过程发现的问题);2、发布前的 checklist 团队成员核对,小会模式完成。
这两点很重要,很大程度避免一些不必要问题发生(环境问题、代码分支问题、数据问题等),如果还是发生落实到个人,多次发生 leader 需发起谈话。
另外以上讲的情况只是针对你所发起的问题给出的相关意见,但不一定就完全可以照搬,需要你根据团队情况逐步实现,或丰富更多手段去实现。总之作为 leader 我们不能只去反应和沟通问题,本质我们要尽量去行动改进问题,这才高层和老板希望看到的,尤其是小公司,你反馈再多基本上效果都是很低的。另外想说的就是很多情况项目是紧急的状态,是不是都必须去做,答案是肯定的,尤其是测试方,除非上面大老板拍板说不用关注质量,我们可以精简一些流程尽量在提供的时间范围内完成必要的工作,这种都会涉及到测试策略的规范等等。
希望有所帮助吧!
另外如果你都做了很多策略和行动,很长时间还是没改变,建议别在这家待着,这公司不值得,这里的同事也不值得。没灵魂!!!
先让老板和开发老大重视。否则都很难。
既然都与大老板讨论过了,大老板也不认可测试,那只能要么改变自己(跳槽),要么大家一起浑浑噩噩下去。就好比你去追一个不爱你的女孩,要么你只能换一个女孩。要么就心甘情愿做备胎
老板和各个领导都说测试很重要,也在一些办公会上也都明确提过,但就是效果始终差强人意,开发团队负责人推行不到位,我们测试团队就很被动。
你们公司付 1 块钱的成本,还想找个 5 块钱的开发,怎么可能?
这哪是测试能三两句呼吁能解决的问题,这是体系级问题,即使领导呼吁可能都没用!
换句话说,这公司的测试就是在额外给开发搽屁股
bug 多,提交修稿又带出一堆,测试验证后开发继续修改,测试再验证,无止尽的陪他们玩
如果下面的人有意见,只能看看能不能多招人,平分到每一个测试身上的人物少了,大家有时间学习些其它的技术 进步
1.测试为何如此没有话语权?2.二中的问题是否是需求优先级最高,为何不设定一系统的规则约定?3.自动化,性能为何不研究下?再不济开发小脚步提升安装效率也可以啊。4.测试没有方向,就自己给自己定个方向,路是死的,人难道不是活的吗?
建议从小开始改善:
1、冒烟通过率很低:把冒烟测试自动化,如果冒烟不通过,直接在流程上打回去,不浪费测试时间;
2、项目界面、易用性问题比较严重:这种问题应该产品或交互背锅?或者在需求评审阶段增加工作量,避免返工导致的浪费;
不要去抱怨工作以及工作的合作者。想想如何帮助开发提高冒烟成功率,开发的痛点在哪?而不是不断升级 “汇报”,最后谁都不开心。
这些问题还是需要数据支持的。描述中在强调:“大家都知道,大家都不做”,因为大部分情况,研发都是感官上觉得重要,身体很诚实。
所以第一个问题,针对研发质量差的建议是:
①:需测试 leader 和研发 leader 约定,冒烟不通过 90%,直接打回,直到提测通过。有些时候需要研发对质量差的有体感上的感同身受,不然大部分研发是不重视。测试需要做好 a:收集好打回的次数数据,做好数据的趋势图统计。b:测试本身技术能力,测试技能要过硬,不然无法说服研发和得到他们重视。
②:和研发沟通商量,对于【核心功能】,须经过研发小组长或者是资深研发工程师的 code review,测试建议也参与,能学到很多。
③:最核心的还是,测试把数据收集好,例如每个月打回的需求次数,占比。因为冒烟不通过导致延期的项目总数,占比。每个研发人员被打回需求的数据统计【这个还是私自发给研发 leader 为好,不要太公开】等等数据。
把这些数据,在月底的时候。如果你是测试 leader,找到研发 leader 一起过下【拉上越高级的人,越多的人越好】一起 check。多灌输一个观念:“质量出现问题,大家一荣俱荣,一损俱损的观念”。反正我每次和研发沟通,只要有机会就抛出这个观点。质量差,加班一起加,辛苦一起辛苦,还不如大家一起努力做好自己本职工作内容如何?
性能有在做,这个对着 2 个问题解决没有什么实质性的帮助,自动化前期做了一个子系统 UI 层的自动化,结果修改太频繁,搞得测试维护脚本很累,并且体现不出来价值,目前在启动接口层的自动化,效果如何还待考究。但我们目前基本是交付类的项目,项目周期都不长,花较多时间在自动化上也不是我想推行的,毕竟项目成本在那里,老板也不会愿意花太多成本来做自动化。目前想的是先把接口自动化搞起来,希望能在效率上有所提升。
感谢你的建议,我们有在做数据统计与分析,并拉上开发负责人和项目经理一起看过,但数据于他们,似乎就只是数据,观念意识上的改变真的还是挺困难。很感谢你的建议,你说的这几点我好好想想,结合我们的数据统计一起搞。
困难是客观普遍存在的,搞不定的是普通众生,很正常,能搞定的就是大佬
解题思路就是一系列自动化的手段,有没有测试提速的工具,帮助开发自测的工具等等
先让用户重视,没有用户,你们开发的终极目标就失去动力
老板和各个领导都说测试很重要——这就不好办了呀,我基本都会尽量选择避开与持 “测试很重要,测试保障质量” 观点的开发团队甚至老板共事——除非我有信心能改变他们的想法
我觉得只有老板和各个领导都说 质量 很重要,而 质量是全流程的质量 的时候才有希望
针对第一点,目前我们的方案是提测前与开发同学确定好自测用例,提测的时候需要通过率 80% 以上(一开始先定 80%),测试同学冒烟测试发现通过率不达标打回重测
正常现象,研发体系都是皇帝不急太监急,既然做了测试,就要学会淡定。
看你描述了一波,大概总结一下你们团队的难处和症结。
1、整个团队乃至公司考核制度不完善(这些问题,与开发负责人、CEO 都有过沟通交流,但最后都仍然没有多大改善),同时领导想看到的是即时效益,可能是你们公司规模和老板思想直接导致;
2、开发人员测试观念薄弱,同时技术能力也一般(开发质量差,提测的功能,冒烟测试通过率通常只有 50% 左右);
3、产品需求设计来回改,产品能力也不强(项目界面、易用性问题比较严重)
提供几点意见给你参考:
1、找 CEO、开发直接 leader、HR 直接沟通考核制度定制改善,你可以提前列出关于团队配合相关的开发测试考核指标,表达自己的意见,当然考核制度并不能很直接的解决问题,可以尝试去推动完成,公司的制度就是在工作中不断完善,作为测试领导这是你能为公司做的一些分外事。
2、作为测试 leader,首先你要分析一波你自己团队成员的能力,哪些测试主导能力强的(测试驱动方面,沟通方面等)、哪些具备测开能力的,这一步很关键。
1)对于测试主导能力强的,让他多执行测试 PM 职责(涉及发布前、发布中、发布后各个节点的职责点,这个作为 leader 你那边可以具体到点列清楚,然后让测试 PM 去执行推动),可以一定程度提高成员的执行力、测试管理能力以及成就感。
2)对于具备测开能力的组员,建议前期直接接入单元测试和接口测试,配合开发完成接口方面测试。另外建议部署一套 mock 接口平台,网上有开源的,这样提前编写 mock 数据(包括正常数据和部分关键异常数据)供前端自测使用。以上两点一定程度可以提高冒烟通过率,更能提升团队技能。
综述,两个点的执行也就是我们测试人员的两个大方向,管理发展方向和技术方向
3、界面问题多:针对过往 bug 分析一下为什么界面问题很多。我大概的提几点常见的,你可以做更详细的分析(开发粗心导致、需求变动频繁导致、需求不明确导致、前端异常情况考虑不充分导致、服务端逻辑缺陷导致等等),
1)我想强调的是开发粗心导致的问题,首先你要和这位开发经常聊聊这方面问题,多发发这些数据,提供一下技能提升的意见,作为朋友的方式沟通,我想想没人不愿意去听。其次,多次沟通无效果的情况,直接和开发 leader 报数据说明开发者能力方面问题,通常情况下开发 leader 也会去找他谈,最终效果还是不明显的情况,就是找 HR 和主要领导沟通这个成员的问题。如果再大家努力下还是没效果,结果自知,为公司筛选员工,你也尽了一份力。
2)另外就是需求的影响导致,前期尽量安排需求测试,这个测试团队最好在需求出来后就去做,另外写用例的时候也去关注。把问题尽量的往前处理。当然这并不是万能的,不可能想的面面俱到。
3)关于服务端逻辑问题和前端页面部分问题,在上面我提到过接口测试和 mock 测试,都是可以提前一定程度发现并解决。
作为 leader 我们需从问题本身分析找出策略去处理这些问题,这也是 leader 应该完成和必须去做的事。
补充两点:
1、需求测试一定要做(需求评审前和测试用例编写过程发现的问题);2、发布前的 checklist 团队成员核对,小会模式完成。
这两点很重要,很大程度避免一些不必要问题发生(环境问题、代码分支问题、数据问题等),如果还是发生落实到个人,多次发生 leader 需发起谈话。
另外以上讲的情况只是针对你所发起的问题给出的相关意见,但不一定就完全可以照搬,需要你根据团队情况逐步实现,或丰富更多手段去实现。总之作为 leader 我们不能只去反应和沟通问题,本质我们要尽量去行动改进问题,这才高层和老板希望看到的,尤其是小公司,你反馈再多基本上效果都是很低的。另外想说的就是很多情况项目是紧急的状态,是不是都必须去做,答案是肯定的,尤其是测试方,除非上面大老板拍板说不用关注质量,我们可以精简一些流程尽量在提供的时间范围内完成必要的工作,这种都会涉及到测试策略的规范等等。
希望有所帮助吧!
另外如果你都做了很多策略和行动,很长时间还是没改变,建议别在这家待着,这公司不值得,这里的同事也不值得。没灵魂!!!
这个话题有点意思,我也来说说我的观点:质量不是测出来的,是设计出来的。
1.既然开发没有这个意识,测试应该参与设计(前提是你作为测试 leader 懂开发设计,你能指出来他们目前架构上、流程以及工作上还需要优化的地方),如果测试不参与设计,那么总是会在整个交付流程最后一环擦屁股,必然会遇到你提到的:开发交付质量差、反复返工问题。
2.系统易用性、体验面的问题较多,那说明开发交付的门禁规则没有定出来,和开发团队沟通,双方达成共识,某些质量不达标直接打回去重新开发。
3.前面 2 个问题如果解决,问题 3 其实不会那么容易显现出来,到时候你还会遇到新的问题,但至少可以解决测试团队目前的痛点。
4.不要总是向领导抛问题,解决方案呢?楼上的哥们已经讲的很透了,你可以试试。
额外说几句:
你这些情况我之前我当年也碰到过,当时有不懂行的领导说:你可以试试自动化测试,应该能解决你的问题。。。。。。我当时心里一万个曹尼玛。
正常, 这个是你统计不到位,开发提测有数据吗?为什么导致呢
“3、基于问题 1、2,测试人员每天花费太多的精力在一些基本功能、界面问题上,而没有较多的精力在测试技术提升、深度问题发掘上,长此以往,会让测试人员有种专业价值没得到体现的感觉,不利于团队的长久发展。”
这个问题其实是双向的,假如一个测试,懂的比较少技术弱,然后功能界面问题很少,那么他很容易没有存在感,或者绩效沟通没有说服力。那么这样问题的关键就会转移到,有了精力之后,到底测试技术能提升多少,能给他带来多少存在感或者安全感。这个是很难体现的。
再思考一下,其实这个问题有一些误区,因为技术提升&深度问题的发掘,靠的是个人的主观能动性,靠的不是公司提供的种种便利(就算大厂背景,也得能有能力进大厂是吧),或者直白一些,安于现状的,更需要的是工作量来实现的职场安全感。
我觉得,这个问题,应该着重于工作分工的科学化,工作协作的安排,让整体的工作节奏是一直处于可控的状态。而 leader 要做的,是发现那么真正主动提升自己能力的同事,然后安排他到适合的岗位上去,帮助他的学习成长。
还有,leader 的技术不能水,尤其是在创业公司。leader 能提出这种问题,本身就必须是一个主动的提升技术的人,要不然真没说服力。
必须说服老板重视。但如何说服呢?
用数字说话,先建立度量系统。让他们知道这样错误的实践是烧公司的钱。站在对方的角度才能说服对方。
相信我,好的度量系统将是你最大,最有效的抓手。