测试管理 那些 “被消失” 的缺陷

CKL的思考 · 2024年11月06日 · 最后由 Vanessa 回复于 2024年11月08日 · 3775 次阅读

前阵子在做团队沟通时,发现了一件很有意思的事:部分测试人员和开发人员会私下达成一致,对于发现的缺陷,不再直接记录到系统中,以 “提升” 交付质量。个人把这些缺陷理解为 “被消失” 的缺陷,因为它并没有真正消失,只是从明面转到暗面。相信很多团队负责人也遇到过这个场景(背景可能各不相同)。

01

杀头的生意有人做,亏本的买卖无人干。

这些 “被消失” 的缺陷为什么会出现呢?大概是有以下几点原因:

短期的 “质量改善”:这些 “被消失” 的缺陷,会暂时减少被发现的问题总数,给相关方一种团队交付质量在慢慢变好的错觉,从而避免麻烦(不靠谱的度量设计要背大部分的锅,不少团队还是以缺陷为唯一指标来评估质量)

减轻短期压力:在项目交付时间紧迫或开发过程中遇到困难时,这种行为可能会让团队成员觉得暂时缓解了压力,避免了因问题过多而产生的焦虑感。毕竟看板上不断上升的缺陷数会给大多数人带来压迫感。

更 “和谐” 的团队氛围:测试和开发的相处会更和谐,你好我好大家好,毕竟只是一份工作。

看起来,好像这种做法也还不错。

02

但是,上面的那些 “好处”,都是短期的,让人一时痛快的。没有从根本上解决问题,还带来了更多更大的危害。

危害 1:屏蔽风险,影响决策。这些 “被消失” 的缺陷会让问题被隐藏,导致项目风险激增。因为研发还是需要花时间去处理这些问题,但是团队不会考虑这部分时间的投入。因为明面上是没有这些事的。整体的安排会出现偏差,研发还是私下抱怨时间不够。

同时,无法从这些 “被消失” 的缺陷中发现团队可能存在的方法或者流程问题,无法有效地改进,让同类型的问题爆发的更多,陷入一个坏的循环中去(发现越多的问题,越不汇报,越不汇报,就无法从根本上解决问题,从而产生更多的问题。)。

当真实的问题暴露出来后,管理层不得不重新评估项目的质量,并采取补救措施。这不仅浪费了时间和资源,还可能影响到公司的其他项目。

危害 2:降低项目质量。不真实地记录这些缺陷,意味着无法从流程上正常跟踪这些问题,那么哪些是解决了的,哪些是还没解决?过段时间双方都忘记了怎么办?等到后期重现了,解决问题的成本在增加,对外的影响在增加,只会降低最终的交付质量。不记录!=已解决。

危害 3:增加测试的工作量。由于危害 2,测试人员就得加大回归的时间,来保证那些 “被消失” 的缺陷真的被研发私下解决了,而不是忘记了。在后续做质量分析和过程改进时,这些数据没有得到有效的分析,就得不到改进,增加的,还是测试人员自身的工作量。

危害 4:破坏团队信任。“被消失” 的缺陷本身就是一种违规的操作,如果被上级领导发现,那就会埋下怀疑的种子。这里可以造假,那其他地方呢?是不是还有看不见的地方被埋雷了?个人的职业素养也会被怀疑,从而失去晋升的希望。

03

这些危害并不是危言耸听。但凡管理过过 10 人的团队,都应该意识到其中的风险。那么,如何避免这种情况的发生呢?个人会采用以下几种方法

保持测试的独立性:虽然现在不建议过多地区分角色职责,但是测试作为一项独立的研发活动,需要保持一定的独立性。在测试设计和用例编写时,可以与研发做更多的沟通和对齐。但是在测试执行开展时,还是需要保持一定的独立性,对于发现的问题要有自己的判断,而不是与研发单点沟通,言听计从。

强调质量文化:在团队中强调质量文化的重要性,使每个成员都明白质量来源于各个环节的共同努力,“被消失” 的缺陷并不能体现交付质量的变好,澄清上面提到的几点危害,让团队共同为质量负责。

同时,也提醒管理者,不能只看缺陷指标,否则,你会在这个指标中迷失。

定期审计和审查:定期对项目进行审计和审查,确保所有工作都按照规范进行,及时发现并纠正问题。这类问题其实不难发现。如果你发现不了,是你管理的失职。

“透明” 是敏捷管理的三大支柱之一,也是提供决策的基本要素。如果团队的研发数据无法真实反馈当前现状,如果团队的成员不敢于透明研发过程数据,那做改进有什么意义?测试人员要避免这种现象,管理者更应该警惕这种现象

共勉。

共收到 6 条回复 时间 点赞

没管理者乱来谁愿意搞这些鬼名堂

哈哈,在微信公众号下面我已经提出疑惑了,这里就不再重复了

面向指标测试

扣绩效扣钱是关键吧

现在我们这就跟绩效挂钩,难受的一批!

你最开始分析 3 点原因就有问题,测试不提这些 bug 就没人能发现了?那这算 bug?还是你的意思是这些 bug 被改掉了只是没记录到什么系统中?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册