作者 | Test Jack 软件测试启示录

要想彻底搞垮一个测试团队并非易事,需要多角色通力配合、多方联动、综合施策,才能达到目的。
本文从实践经验出发,为大家总结了搞垮测试团队的 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” 看看。

实际上很多时候,用户根本不需要那么高的质量,公司花钱养这么多测试人员是不是浪费?去测试化还是要搞起来的。只不过,“去测试” 不等于 “没测试”,测试活动仍然存在,只不过从测试扔给开发了。各位开发兄弟们,测试的锅已经被砸,你们好自为之,做好自己背锅的准备吧。


↙↙↙阅读原文可查看相关链接,并与作者交流