3、界面问题修复要有适度的准备时间– 我们修复了一个在屏幕上出现的用户错误消息中的拼写错误。用户并没有察觉到拼写错误但是我们无论如何修复了问题。很快而且简单。触发这个错误消息需要30分钟的准备时间，值得吗？

　　4、直接了当的配置改变– 去年我们产品开始偶尔出现很大的作业不能处理的问题。一个程序员尝试改变通用配置修复问题。但在QA的环境中没有一个简单的方法去创建一个足够大的作业超过这个临界值，很难去测试。我们在产品中修改了配置然后用户很高兴的为我们做了测试。

　　5、技术性的需要非程序员的测试– 测试部分功能时需要实施某种行为而在代码中设置断点来复现竞态条件.有时测试人员与工具和程序员精通产品代码的知识并不匹配。讨论这个测试但是回避它。

　　6、非测试人员借用– 如果团队中一个非测试人员帮忙去做测试工作，或者更重要的，想帮忙测试某一组件，让他去做吧。跟他分享测试的思路并且跟他要测试报告。如果你觉得满意，不需要再去测试它了。

　　7、没有复现步骤- 程序员偶尔会尝试某些东西。经常会出现一些错误报告，但是没有人能对这些错误给出确切的重现步骤。我们也许想对修改的区域做回归测试，但是我们发布的时候不会阻止这种明显的修复，因为我们不知道它管不管用。

　　8、不足的测试数据或硬件– 让我们面对它吧。在我们QA的环境中，根据产品中所需要，大部分情况我们没有足够多负载平衡服务器。当一个有效的测试需要的资源在产品使用环境之外不可用时，我们可能无法对其进行测试。

　　很多人也许尝试想像上面这些如果不去测试会导致的问题。我也会做这些。记住，这些事情也许不值得花费我们的时间去测试。再次权衡你所做的事情，如果在不是很清楚的时候，去问问利益相关者。

　　如果你选择不去测试某些东西，很重要的是，不能被我误导。这是在我的团队中使用到方法。在我们进行组件审查时，我们的（测试人员）说，“我们将不会去测试这些”。如果有人反对，我们会改变我们的想法并且测试它。如果没有人反对，我们就“未经审查即批准（rubber stamping）”。即表明没有被测试就让它通过这样可以让他进入到最终产品。

　　所以下次你发现你自己正在着手做的测试，感觉比其他你应该做的事情更不重要时，你应该需要考虑…不去测试它。逐渐的，你的团队将会尊重你的决定并受益于更少的瓶颈，以及在你实际增加的价值的地方增长的覆盖率。