要想彻底搞垮一个测试团队并非易事，需要多角色通力配合、多方联动、综合施策，才能达到目的。
本文从实践经验出发，为大家总结了搞垮测试团队的18项措施，或许可以给大家带来一些启发。
— 1 —
QA
QA作为质量管理者，在搞垮测试团队的过程中必然责无旁贷、冲锋在前。
1、所有线上事故测试主责
任何线上事故，一定要第一时间质问测试“为什么没测出来”？最好和产品、研发、运维一起追问测试，最后在公司大群里发问（人数越多效果越好），并@测试团队的主管（措辞越激烈效果越好）。
不要和我讲需求场景未定义，也不要讲开发做了改动没通知——测试就是质量的代言人，必须对质量承担主要责任。
2、定义尽可能多的度量指标
德鲁克说：“你如果无法度量它，就无法管理它。”所以，QA要编织极为细密的度量之网，监控所有测试细节：
- 缺陷打回率，要作为测试团队的考核指标。怎么？你担心测试不敢提BUG了？怕什么，有漏测率度量在等着你。
- 度量用例发现的BUG占比，如果过高需要反思是否用例不够多，如果过低需要反思是否用例质量差（发现不了问题的用例一定不是好用例）。
- 不要度量开发人均缺陷数，而要度量测试人均缺陷数，谁让测试是负责提BUG的呢？
- 如果你能想到更多的度量指标，不用想清楚为什么度量、指标说明了什么，只管先拿来度量，在实践中检验它的作用。
— 2 —
项目经理
为了搞垮测试团队，项目经理能做的并不多。但是教员教导我们：“世界上怕就怕认真二字。”认真专注地做好一件事，功莫大焉。
3、尽量压缩测试时间
VUCA时代的项目经理可不好当，项目计划经常出现延期。开发提测延期了怎么办？作为测试人员，必须要做到结果导向、使命必达！克服困难，加班搞定！
不就是3天的测试时间压缩到1天嘛，老板本来希望压缩到半天，还好我多给你们争取了半天时间。这次情况特殊，下不为例（要让这四个字成为测试人员最熟悉的声音）！
— 3 —
产品经理
产品经理在搞垮测试团队过程中，起到的作用就比较大了。
4、需求质量越差越好
产品经理是坚定的敏捷实践者，敏捷宣言都说了：“只要工作的软件，不要详尽的文档”。所以我们要关注软件是否正常工作，需求文档并不重要，这可是大师们说的撒。
需求要尽量做到：
- 需求描述别太清晰，避免过度定义细节引起的设计浪费；
- 需求颗粒度越大越好，所有相关特性尽量一次搞定，符合“一次把事情做好”的理念；
- 不同产品经理提的需求要有一些逻辑冲突，以此促进产品、开发和测试“面对面的沟（吵）通（架）”；
- 另外，为了提高需求评审（如果有的话）效率，最好不要测试参与，减人增效。
5、需求变动越多越好
敏捷的核心，是以更快的速度、更低的成本拥抱变化。所以需求要尽可能频繁变更，保证满足用户和市场的最新需要。
当然，变更的需求中有些是由于产品经理调研不够、考虑不周导致，不过这些只是少数（只有少数不是）。
温馨提醒：这项措施在搞垮测试团队时要慎用，因为容易先把开发团队搞垮，违背了精准施策的原则。
6、千万别做验收
产品验收本来就是可有可无、走个过场而已，需求文档白纸黑字写得清清楚楚，需要产品经理验收什么！
既然验收测试也是“测试”，当然要测试人员保证。如果产品效果和用户预期产生了偏差，那是测试能力不足的表现。
如果个别产品经理没坚守这条原则，产品上线前才去验收并发现一些问题，一定要投诉并质疑测试的工作能力。
— 4 —
开发人员
开发作为测试“相爱相杀”的伙伴，在搞垮测试团队的过程中，承担着至关重要的作用。
7、分支越多越好
分支管理能力是开发专业能力的体现，要努力做到以下几点：
- 坚持“分支为王”的原则，能拉分支解决的问题，千万别考虑其他方案；
- 缺陷的修复一定要及时合入各分支，每个分支都要求测试验证一遍，这才是工匠精神；
- 分支之间的合并，越频繁、越复杂越好，每次合并都要求测试验证一遍；
- 测试需要熟悉主分支、功能分支、临时分支的实时情况，如果自己打错了包，不要来找开发。
8、不要谈可测试性
今天，一位测试人员找我增加接口、增加日志，他说否则做不了测试。
兄弟，我是开发，我写代码只考虑功能是否用得了，能否测得了是你们测试的事情啊，为啥来找我呢？
术业有专攻，开发写代码，测试做验证。分工多明确，世界多美好。
9、不需要自测
作为多年经验的程序员，我对自己的代码信心十足。我写完代码，只要本地编译通过，就可以提交了。
我没做过自测，也没有出过什么大问题啊！反正有测试在后面兜底，有问题测试自然会来找我的。
开发兄弟们请想想：省下自测的时间，多开发几个功能，多解决几个BUG，难道不是提高产出的好方法吗？
10、不要做设计方案评审
一位新来的测试，今天问我“什么时候评审设计方案”？能问这样的问题，一看你就是新来的。
首先，设计方案是给开发看的，你们测试能看懂？其次，测试要以需求为依据，如果以技术方案为依据，我们方案写错了你们是不是也测错了？再次，评审技术方案的前提，得是有技术方案，问题是我们有吗？
11、不要写缺陷备注
每次我修复完一个BUG，直接将BUG单状态转为“待验证”就万事大吉了。BUG是测试自己提的，难道还不清楚怎么回归验证？