如何搞垮一个测试团队?

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

本文从实践经验出发,为大家总结了搞垮测试团队的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是测试自己提的,难道还不清楚怎么回归验证?

上一页12下一页


留言