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