制品过程中，测试用例执行失败，那么不一定是发现了问题也有可能是外部因素导致的，这就是缺陷误报；在上线后，用户触发了遗漏缺陷，会引起一系列连锁反应，甚至导致资损，这些遗漏的缺陷是因为漏报导致的。
那么无论是误报，还是漏报都会导致制品团队的返工，也是最大的浪费。
误报的返工
测试过程中我们常常会遇见引起测试用例失效的原因不是被测系统的BUG导致的，而是由于一些测试环境、测试数据、外部依赖等原因导致的，虽然这些并不能定义为BUG，但是同样引起了测试工作的返工因此也需要解决误报。
误报是内部制品过程的浪费。我们在质量保障过程中，从需求阶段的开卡开始，就投入了测试工程师参与其中，针对研发工程师在完成需求过程中需要变更的接口提前准备了接口自动化测试的case，并且在完成验卡后通过流水线触发新增接口的自动化测试完成对应的质量保障活动，这一些的投入都是为了能够提高交付过程的流畅度。如果自动化测试在触发的时候出现了失效，我们更希望于这个失效状态都是被测系统的BUG导致的，但是现实中往往很多时候是由于一些外部系统的依赖、本地测试数据的污染等一些外围原因导致的，而不是被测试系统的BUG，这就是BUG误报，我们简称误报。
虽然不是被测试系统的BUG引起的测试失效，但是误报同样需要重视，因为它导致测试工作的返工。针对误报，可以通过添加技术需求卡的形式进入迭代过程阶段，这样既可以在团队中形成留痕也可以促使该种引起误报的问题不再出现。在添加完卡片后，就有研发工程师自己是情况而定是在本次迭代解决还是在未来某次迭代解决。
漏报的损失
在第一版软件评测师教程中提出的软件测试的原则就明确指出“完全的测试事不可能的，测试需要终止”。这也就导致所有的测试手段都不能穷尽所有变更中包含的BUG，所有的线上系统都是有缺陷的，我们将遗漏到客户的缺陷称作漏报。
漏报的结果就是会造成生产缺陷或者故障，从而引起一定的损失。这也和金融行业的风险与损失的概念一样。风险是损失发生的可能性，或可能发生的损失。损失本质上是一个偏于事后的概念，反映的是风险事件发生后状况，而风险却是一个明确的事前概念，反映的事损失发生前的事物发展状态。虽然说所有的交付系统都有BUG，但是我们还是寄希望于在测试过程中发现全部的BUG，虽然这还是一个不可能完成的事情，一些能被用户主动触发的BUG还是应该在制品过程中被解决。
那么当出现BUG漏报的时候，我们主观对漏报的BUG进行分级处理，针对严重级别高的漏报BUG行复盘，复盘过程是为了找出制品过程中的问题，从而弥补。保障同类问题不再出现，而不是为了追责。推荐复盘记录的一些关键要素：动作和事件时间表主要按照时间线记录发现、处理漏报BUG的动作、时间；漏报BUG的发现现象：这里重点记录是如何发现漏报BUG的，从而找出是否需要建立一些Action弥补对应的问题；级别：漏报BUG的级别，从而可以识别影响范围；后果和决定，也就是后续的需要解决该类问题不再发生的Action。
误报和漏报都是浪费
误报会引起返工，漏报会引起损失，这两种的结果都是制品过程中的浪费，因此我们应该通过各式各样的手段，防止误报的出现，阻止漏报的发生。这里面既有技术方法也有组织约束，但是每一种都是站在制品团队的技术改进之上来完成的，而不是为了寻找“背锅侠”而付出的努力。
