如何搞垮一个测试团队?

发表于:2022-10-08 09:52

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Test Jack    来源:知乎

#
qa
分享:
  要想彻底搞垮一个测试团队并非易事,需要多角色通力配合、多方联动、综合施策,才能达到目的。
  本文从实践经验出发,为大家总结了搞垮测试团队的 18 项措施,或许可以给大家带来一些启发。
  QA
  QA 作为质量管理者,在搞垮测试团队的过程中必然责无旁贷、冲锋在前。
  1、所有线上事故测试主责
  任何线上事故,一定要第一时间质问测试 “为什么没测出来”?最好和产品、研发、运维一起追问测试,最后在公司大群里发问(人数越多效果越好),并 @ 测试团队的主管(措辞越激烈效果越好)。
  不要和我讲需求场景未定义,也不要讲开发做了改动没通知——测试就是质量的代言人,必须对质量承担主要责任。
  2、定义尽可能多的度量指标
  德鲁克说:“你如果无法度量它,就无法管理它。” 所以,QA 要编织极为细密的度量之网,监控所有测试细节:
  缺陷打回率,要作为测试团队的考核指标。
  怎么?
  你担心测试不敢提 BUG 了?
  怕什么,有漏测率度量在等着你。
  度量用例发现的 BUG 占比,如果过高需要反思是否用例不够多,如果过低需要反思是否用例质量差(发现不了问题的用例一定不是好用例)。
  不要度量开发人均缺陷数,而要度量测试人均缺陷数,谁让测试是负责提 BUG 的呢?
  如果你能想到更多的度量指标,不用想清楚为什么度量、指标说明了什么,只管先拿来度量,在实践中检验它的作用。
  项目经理
  为了搞垮测试团队,项目经理能做的并不多。但是教员教导我们:“世界上怕就怕认真二字。” 认真专注地做好一件事,功莫大焉。
  3、尽量压缩测试时间
  VUCA 时代的项目经理可不好当,项目计划经常出现延期。开发提测延期了怎么办?作为测试人员,必须要做到结果导向、使命必达!克服困难,加班搞定!
  不就是 3 天的测试时间压缩到 1 天嘛,老板本来希望压缩到半天,还好我多给你们争取了半天时间。这次情况特殊,下不为例(要让这四个字成为测试人员最熟悉的声音)!
  产品经理
  产品经理在搞垮测试团队过程中,起到的作用就比较大了。
  4、需求质量越差越好
  产品经理是坚定的敏捷实践者,敏捷宣言都说了:“只要工作的软件,不要详尽的文档”。所以我们要关注软件是否正常工作,需求文档并不重要,这可是大师们说的撒。
  需求要尽量做到:
  需求描述别太清晰,避免过度定义细节引起的设计浪费;
  需求颗粒度越大越好,所有相关特性尽量一次搞定,符合 “一次把事情做好” 的理念;
  不同产品经理提的需求要有一些逻辑冲突,以此促进产品、开发和测试 “面对面的沟(吵)通(架)”;
  另外,为了提高需求评审(如果有的话)效率,最好不要测试参与,减人增效。
  5、需求变动越多越好
  敏捷的核心,是以更快的速度、更低的成本拥抱变化。所以需求要尽可能频繁变更,保证满足用户和市场的最新需要。
  当然,变更的需求中有些是由于产品经理调研不够、考虑不周导致,不过这些只是少数(只有少数不是)。
  温馨提醒:这项措施在搞垮测试团队时要慎用,因为容易先把开发团队搞垮,违背了精准施策的原则。
  6、千万别做验收
  产品验收本来就是可有可无、走个过场而已,需求文档白纸黑字写得清清楚楚,需要产品经理验收什么!
  既然验收测试也是 “测试”,当然要测试人员保证。如果产品效果和用户预期产生了偏差,那是测试能力不足的表现。
  如果个别产品经理没坚守这条原则,产品上线前才去验收并发现一些问题,一定要投诉并质疑测试的工作能力。
  开发人员
  开发作为测试 “相爱相杀” 的伙伴,在搞垮测试团队的过程中,承担着至关重要的作用。
  7、分支越多越好
  分支管理能力是开发专业能力的体现,要努力做到以下几点:
  坚持 “分支为王” 的原则,能拉分支解决的问题,千万别考虑其他方案;
  缺陷的修复一定要及时合入各分支,每个分支都要求测试验证一遍,这才是工匠精神;
  分支之间的合并,越频繁、越复杂越好,每次合并都要求测试验证一遍;
  测试需要熟悉主分支、功能分支、临时分支的实时情况,如果自己打错了包,不要来找开发。
  8、不要谈可测试性
  今天,一位测试人员找我增加接口、增加日志,他说否则做不了测试。
  兄弟,我是开发,我写代码只考虑功能是否用得了,能否测得了是你们测试的事情啊,为啥来找我呢?
  术业有专攻,开发写代码,测试做验证。分工多明确,世界多美好。
  9、不需要自测
  作为多年经验的程序员,我对自己的代码信心十足。我写完代码,只要本地编译通过,就可以提交了。
  我没做过自测,也没有出过什么大问题啊!反正有测试在后面兜底,有问题测试自然会来找我的。
  开发兄弟们请想想:省下自测的时间,多开发几个功能,多解决几个 BUG,难道不是提高产出的好方法吗?
  10、不要做设计方案评审
  一位新来的测试,今天问我 “什么时候评审设计方案”?能问这样的问题,一看你就是新来的。
  首先,设计方案是给开发看的,你们测试能看懂?其次,测试要以需求为依据,如果以技术方案为依据,我们方案写错了你们是不是也测错了?再次,评审技术方案的前提,得是有技术方案,问题是我们有吗?
  11、不要写缺陷备注
  每次我修复完一个 BUG,直接将 BUG 单状态转为 “待验证” 就万事大吉了。BUG 是测试自己提的,难道还不清楚怎么回归验证?
  有的缺陷管理系统强制要求填写备注,怎么办?这种小伎俩哪能难住我这种资深开发工程师?只需要填写 “已解决” 三个字就可以了。什么,担心被测试投诉?我们这么多开发,大家都这样做,他们能投诉得过来?“法不责众” 你了解吗?
  测试人员
  外因是变化的条件,内因才是变化的依据。要想迅速有效地搞垮测试团队,测试自身必须重点发力、加快进程。
  12、测试就是开发的跟班
  测试就是开发的跟班小弟,是负责给开发 “打下手” 的。具体案例包括:
  开发让我测啥我就测啥、让我怎么测我就怎么测、让我测哪个版本我就测哪个版本;
  性能优化同步给开发做验证,开发改一点、测试验一下,开发再改一点、测试再验一下……“结对编程” 效率高;
  刷机、抓包、导日志、跑数据,测试要像保姆一样贴心,全方位服务开发团队。
  你问为啥刷机这样的事情不写个操作说明给开发?开发说了:这类事情,测试来做更专业(内心想法:我怎么会做这么 low 的事)!
  13、测试不需要了解实现
  测试是代表用户发声的,要完全站在用户角度验证需求。更何况我们做的是黑盒测试,什么是黑盒?就是不管技术实现原理,只看输入输出就行!
  产品需求是定义 “做什么”,开发实现是定义 “怎么做”,测试要验证的应该是 “做什么”、有没有做对。开发的实现逻辑,很容易把测试的思路带偏,甚至把测试带到坑里去。测试同学一定要看需求,不要看实现。
  14、流程规范并不重要
  流程规范虽然有些作用,但是并不那么重要。有的测试部门制定那么多的流程规范:缺陷提交规范、缺陷定级规范、测试用例设计/评审/执行规范……请问会有几个人认真看呢?
  我也算是 “老测试” 了,随手就能列出一堆流程规范的常见问题:
  拍脑袋定义,不符合实际情况;
  描述太空泛,不具备可操作性;
  不够全面,实际经常遇到未定义的情况;
  更新不及时,没有随着业务变化而修改;
  多个流程规范 “打架”,自相矛盾,让人无所适从。
  细节太多,看了根本记不住……
  流程规范有这么多问题,足以证明弊大于利。
  15、自动化测试是核心能力
  不要相信 “测试设计能力才是测试的核心能力” 这种话。你看看身边技术水平高、职位高、薪资高的,不都是自动化测试达人吗?只有代码能力强,你才能站在测试金字塔的塔尖上去。
  开发工程师转岗做测试,人家立即就是资深的测试工程师,毕竟人家自动化能力杠杠的。
  16、不需要读书学习
  专家说过:“工程师的经验 70% 来自工作实践,20% 来自同事经验传递。” 这两项加起来就是 90%!我们来算算这笔账,为了那 10% 的经验,点灯熬夜地去读书学习,是不是得不偿失?
  更何况,大多数人都是读书时激动、读书后感动、读完后不动。读完了也记不住,用的时候还不如搜索引擎来得快(别看广告看功效)。有读书那工夫,刷刷短视频放松一下,劳逸结合,它不香吗?
  组织文化
  17、加班越多越好
  这团队啊,必须要忙起来才行。人一闲下来,就会胡思乱想,搞小动作。刚听说兄弟团队最近两个月比较闲,结果离职了好多人,有一位报了算法学习班在工作期间刷题练手的,还有一位考了教师资格证准备转行的。
  咱们团队要吸取教训,虽然我们没有加班文化,但务必要保证每个人的工作饱和度,每天时间排期要精确到小时。加班强度要作为考核和评优的参考依据,任务排期要把晚上和周六也排上。不多给团队一点压力,怎么能激发大家的潜力?
  组织战略
  18、去测试化
  测试并不直接生产企业的产品,因此常被看做成本中心。你看几年前微软 CEO 的去测试化不是很成功吗?裁减大量测试人员同时保证了质量,不信的话可以某度搜索 “win10 bug” 看看。
  实际上很多时候,用户根本不需要那么高的质量,公司花钱养这么多测试人员是不是浪费?去测试化还是要搞起来的。只不过,“去测试” 不等于 “没测试”,测试活动仍然存在,只不过从测试扔给开发了。各位开发兄弟们,测试的锅已经被砸,你们好自为之,做好自己背锅的准备吧。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
价值398元的测试课程免费赠送,填问卷领取吧!

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计

法律顾问:上海漕溪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2023
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号