前阵子在做团队沟通时,发现了一件很有意思的事:部分测试人员和开发人员会私下达成一致,对于发现的缺陷,不再直接记录到系统中,以“提升”交付质量。个人把这些缺陷理解为“被消失”的缺陷,因为它并没有真正消失,只是从明面转到暗面。相信很多团队负责人也遇到过这个场景(背景可能各不相同)。
01
杀头的生意有人做,亏本的买卖无人干。这些“被消失”的缺陷为什么会出现呢?大概是有以下几点原因:
短期的“质量改善”:这些“被消失”的缺陷,会暂时减少被发现的问题总数,给相关方一种团队交付质量在慢慢变好的错觉,从而避免麻烦(不靠谱的度量设计要背大部分的锅,不少团队还是以缺陷为唯一指标来评估质量)
减轻短期压力:在项目交付时间紧迫或开发过程中遇到困难时,这种行为可能会让团队成员觉得暂时缓解了压力,避免了因问题过多而产生的焦虑感。毕竟看板上不断上升的缺陷数会给大多数人带来压迫感。
更“和谐”的团队氛围:测试和开发的相处会更和谐,你好我好大家好,毕竟只是一份工作。看起来,好像这种做法也还不错。
02
但是,上面的那些“好处”,都是短期的,让人一时痛快的。没有从根本上解决问题,还带来了更多更大的危害。
危害1:屏蔽风险,影响决策。这些“被消失”的缺陷会让问题被隐藏,导致项目风险激增。因为研发还是需要花时间去处理这些问题,但是团队不会考虑这部分时间的投入。因为明面上是没有这些事的。整体的安排会出现偏差,研发还是私下抱怨时间不够。
同时,无法从这些“被消失”的缺陷中发现团队可能存在的方法或者流程问题,无法有效地改进,让同类型的问题爆发的更多,陷入一个坏的循环中去(发现越多的问题,越不汇报,越不汇报,就无法从根本上解决问题,从而产生更多的问题。)。
当真实的问题暴露出来后,管理层不得不重新评估项目的质量,并采取补救措施。这不仅浪费了时间和资源,还可能影响到公司的其他项目。
危害2:降低项目质量。不真实地记录这些缺陷,意味着无法从流程上正常跟踪这些问题,那么哪些是解决了的,哪些是还没解决?过段时间双方都忘记了怎么办?等到后期重现了,解决问题的成本在增加,对外的影响在增加,只会降低最终的交付质量。不记录!=已解决。
危害3:增加测试的工作量。由于危害2,测试人员就得加大回归的时间,来保证那些“被消失”的缺陷真的被研发私下解决了,而不是忘记了。在后续做质量分析和过程改进时,这些数据没有得到有效的分析,就得不到改进,增加的,还是测试人员自身的工作量。
危害4:破坏团队信任。“被消失”的缺陷本身就是一种违规的操作,如果被上级领导发现,那就会埋下怀疑的种子。这里可以造假,那其他地方呢?是不是还有看不见的地方被埋雷了?个人的职业素养也会被怀疑,从而失去晋升的希望。
03
这些危害并不是危言耸听。但凡管理过过10人的团队,都应该意识到其中的风险。那么,如何避免这种情况的发生呢?个人会采用以下几种方法:
保持测试的独立性:虽然现在不建议过多地区分角色职责,但是测试作为一项独立的研发活动,需要保持一定的独立性。在测试设计和用例编写时,可以与研发做更多的沟通和对齐。但是在测试执行开展时,还是需要保持一定的独立性,对于发现的问题要有自己的判断,而不是与研发单点沟通,言听计从。
强调质量文化:在团队中强调质量文化的重要性,使每个成员都明白质量来源于各个环节的共同努力,“被消失”的缺陷并不能体现交付质量的变好,澄清上面提到的几点危害,让团队共同为质量负责。同时,也提醒管理者,不能只看缺陷指标,否则,你会在这个指标中迷失。
定期审计和审查:定期对项目进行审计和审查,确保所有工作都按照规范进行,及时发现并纠正问题。这类问题其实不难发现。如果你发现不了,是你管理的失职。
“透明”是敏捷管理的三大支柱之一,也是提供决策的基本要素。如果团队的研发数据无法真实反馈当前现状,如果团队的成员不敢于透明研发过程数据,那做改进有什么意义?
测试人员要避免这种现象,管理者更应该警惕这种现象。