如何搞垮一个测试团队？

要想彻底搞垮一个测试团队并非易事，需要多角色通力配合、多方联动、综合施策，才能达到目的。

本文从“实践经验”出发，为大家总结了搞垮测试团队的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”看看。

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