在某人假设一个负面事件会导致一系列负面事件，甚至会引发灾难，但没有证据表明每个事件都将是下一个事件的原因时，就会发生滑坡谬误。

​​

这是一个常见的谬误，当父母不想让他们青春期的孩子做某件事时就会使用。想象一下父亲和女儿之间的情景。“如果我让你去听摇滚音乐会，并且让你在上学的晚上待到凌晨2点，很快你就会每晚都在外面待到凌晨2点。然后你就会累得不能按时起床去上学，这意味着你的成绩会受到影响，然后你就进不了一所好大学。”

这个谬误对于青少年来说是显而易见的：在一个晚上待到凌晨2点并不意味着每天晚上都会这样，因为父母实际上不会让这种情况发生。在这个例子中，父亲使用滑坡谬误作为他不想让女儿去听音乐会的借口。

滑坡谬误在软件测试中也会发生！你可能曾经遇到过一个善意的测试人员，在团队的应用程序中发现了一个小的UI bug。他们记录了这个bug，但不愿将其放入待办事项列表，而是坚持要求立即修复这个bug。他们使用的逻辑大致如下：“如果我们不让开发人员立刻修复这个bug，就意味着他们将来会忽视更大的bug。然后我们就会背上一大堆永远无法摆脱的技术债，我们的应用程序将充满bug。我们的客户会离开我们，然后我们就会倒闭。”

对于那些坚信他们的应用程序应该尽可能接近完美的测试人员来说，这种谬误可能会更难以察觉。但是这里存在一个错误：将一个小的bug放入待办事项列表并不一定会导致团队忽视重大bug。一个运作良好的团队会有一个分类流程，在这个流程中，整个团队可以确定bug对用户的影响，与团队正在进行的其他任务相比，修复漏洞的重要性，以及等待修复bug的潜在成本。

是的，忽略过多的bug可能会引发较多的技术债务，但一个不影响应用程序功能的小UI bug不会对这种债务产生重大影响。重要的是，测试人员要选择他们强烈坚持必须修复的bug，同时愿意放过一些小的bug，因为如果对每一个bug都大声抗议，团队成员将来可能不再认真接受他们的意见。